Share this
by Brendon Livingstone on 28 March 2018
Agile projects can often be like a first dance lesson where everyone is treading on each other's toes. We often are asked at Equinox IT about the roles of Project Manager and Scrum Master for Agile projects. Are they both needed? What are the boundaries? Should they be combined?
So, over the last month we have had Equinox IT Principal Consultant Carl Weller deliver the 'Agile leadership roles - let's clear up the confusion between PM & Scrum Master' presentation to IT executives, project managers, development managers and Agile coaches. Carl has delivered this presentation on both 28 February and 26 March 2018 at Equinox IT hosted events (hence why Carl appears in photos in the post wearing two different shirt colours).
Carl has a traditional Project Manager background, is PMI and PRINCE2 certified, has run Project Management Offices, and has managed numerous plan-based IT projects. Carl is also a Certified ScrumMaster and Agile Leader. He leads Agile projects and advises clients on Agile adoption and Agile leadership. Given his diverse experience he is ideally placed to present on this topic.
In this post I summarise some of Carl's points from his two deliveries of this presentation.
Setting the context for Agile leadership roles
Size DOES matter when it comes to projects
While Carl is reluctant to present the often quoted Standish Group Chaos Report statistics, the information does highlight one important fact. While Agile projects are somewhat more likely to be successful than waterfall projects, what is really clear is that small projects are far more likely to be successful than large projects, regardless of whether they use an Agile or waterfall approach.
Agile is a radical virus that gets rejected by the host
Agile introduces many benefits, including minimising risk early in the project by getting feedback from customers from the start in quick cycles. But, despite these benefits, Agile is often seen as a radical virus and it gets rejected by many organisations. This trend is only getting worse. The VersionOne "State of Agile" report shows that the main challenge with Agile is 'company philosophy or culture is at odds with core agile values', and this issue has risen from 42% of responses in 2015 to 63% of responses in 2017.
PM construction metaphor vs Agile potter metaphor
Historically, traditional project management is often compared to construction. This is a mechanistic or reductionist approach. In this mindset it is considered that uncertainty can be analysed, planned for and controlled. The Project Manager "plans the work and works the plan". Once the foundation and structure are built, it is very difficult and costly to change.
Carl's metaphor for Agile is a potter working with clay. This is an artisanal or responsive approach. The potter has an idea of what they will create, but they also respond to circumstances and can accommodate change more easily.
Defined process control vs empirical process control
In the early days of Scrum Ken Schwaber worked with Babatunde Ogunnaike to understand an appropriate process for software development projects. Waterfall and traditional project management follow a Defined Process Control approach adopted from manufacturing. In manufacturing a failure rate of 1% is considered unacceptably high, and they are able to achieve very low failure rates by investing in highly repeatable and defined processes.
Software projects on the other hand have about a 30% failure rate, in part because software requirements are different each time and there is the need to accommodate change. Babatunde suggested an Empirical Process Control approach where software is built knowing it is going to change. Scrum accommodates this by having sprints where very little change occurs during the sprint - so the team has stability to deliver, but a lot of flexibility to accommodate change going into each next sprint.
Handling triple constraints
Often time, scope and cost become fixed on many projects and the Project Manager has no possible trade-offs apart from quality, which may suffer when the project runs out of time or budget. On Agile projects time and cost are often fixed and scope is variable with a focus on delivering the highest business value first within the fixed time and cost parameters. Quality can be 'flexed', but only in consultation with the Product Owner.
Project Managers have similarities to Product Owners
While we often compare Project Managers with Scrum Masters, they are in fact closer in role to Product Owners. The Project Manager role is responsible for managing the delivery team and also managing stakeholders outside of the project. The Product Owner also has this two-way facing role - facing toward the Scrum Master and the development team and also toward the stakeholders and customers / users. As such, Project Managers often are used as de facto Product Owners.
Care does need to be taken to ensure that the business and the investor's needs are accurately represented by the Project Manager, given we'd normally expect the Product Owner to come from the business and implicitly represent the business's needs. The danger with this approach is not to be under-estimated. In assigning a Project Manager (or any other role) as stand-in Product Owner you are breaking the direct connection between the team and the investor, which weakens the control framework of Scrum, and heightens the risk of churn and re-work if the Project Manager is not well-aligned with the Product Owner.
Agile minimum viable product
While this may come as a shock to Project Managers, Carl advocates that for software projects we should be doing the minimum possible to deliver what the business needs, then shut the project down and use the remaining money for something else. This modifies how we should run Agile projects. So in the photo below if we are focusing on building a 'mode of transport', in the top option we cannot complete the project until the car in complete. But in the bottom option, following a minimum viable product approach, we start with a simple mode of transport and progressively developing more advanced modes. We can stop the project and the financial investment as soon as we have delivered the simplest option that satisfies the business's needs.
Correlating Agile with Project Management approaches
PRINCE2 Agile offers an approach for running Agile delivery within the PRINCE2 method. Effectively Agile is used for the workflow management process in PRINCE2. However, Project Managers do need to take care not to 'rob the team' of their Agility using this approach.
Carl's view is that Agile has practices that allow it to replace many more parts of PRINCE2 than simply workflow management. Carl also looks at PMBOK and shows the areas that Agile has equivalent practices and the areas where Agile has not coverage (such as resource planning, communications management, and budgeting). Agile is often considered to be unplanned, but Carl's view is that Agile has a lot of planning.
Project Manager and Scrum Master roles
The Project Manager and Scrum Master roles come from two different paradigms, trying to do a number of the same things, and so often the people fulfilling these roles don't get along.
But there is a role for Project Manager skills on Agile projects. Project Managers are often well placed to help with areas not covered by Agile or not delivered well by Agile teams. For example, the Project Manager can play a role in sheltering the Agile team from the parts of the organisation that may be trying to reject it as a virus. They can act as a translation layer between the Agile team and an organisation that may operate in a more traditional fashion.
Given the similarities to the Product Owner role Project Managers can also play an important role in supporting the Product Owner. Finally, Agile does not cover the resourcing side of projects and so the Project Manager can help with people onboarding and other people considerations that fall outside of Agile delivery.
Many thanks to Carl for this excellent presentation. It was great to see that the presentation was well received by our clients, to the extent that we had demand for a second delivery of the presentation.