Breaking the Iron Triangle: Project Manager v Scrum Master

As a PM my general approach to initiating projects has been to build a Project Initiation Document (PID – Prince). A PID details the project objectives, initial scope, organisational structure, roles & responsibilities, deliverables, project processes (lines of communications, risk management, issue management, change control), plans, costs and timelines.

And starting an agile project I would still identify most of the above and ensure it is clearly communicated to all stakeholders.

But… I have learnt that adopting a scrum approach changes two fundamental things for a project manager:
· The Iron Triangle
· The Role of Project Manager

The iron triangle of cost, time and scope (or quality) is typically the responsibility of the project manager to manage. Hopefully tolerance levels have been set for each element of the triangle, and if the tolerance level is about to be breached or is broken, the project manager escalates their issues to the project board or steering group.

Previously on traditional projects I owned and was responsible for this triangle and reported to the project board if any risks or issues were likely to break the tolerance levels.

In a traditional project a deliverable-focused approach to planning is used (Prince = configuration plan), whereby all the intermediate work products and “pieces” of the solution are identified and a plan drawn up to show the route to delivery usually utilising a gantt chart or network diagram. From which timelines, resources, and costs can be identified and critical path analysis and risk management conducted.

Now scrum doesn’t throw this all away… rather we open out the Iron Triangle and share responsibility across the team, and recognise that no matter how well we plan the project, things will change, and problems will occur.

So… lets make time and cost fixed for a set period, say 4 weeks.

So the resources I’ve identify for the project will work for 4 weeks together which will cost a fixed price…

Now, let’s not set the scope as fixed, but accept that scope is variable within this part of the project.

The amount of work and quality of deliverables achieved within the fixed cost/time axis will depend on people… it will depend on the team’s productivity and practices. Let’s remove focus from the iron triangle established at the beginning of the project, and instead focus on making the team as efficient and productive as possible.

So the role of the Scrum Master is one of maximising the productivity of the team by removing obstacles, inspiring, motivating, and ensuring the scrum methodology is followed.

The responsibility for what is built (the scope) is then given to the business. Scrum identifies a Product Owner, a business stakeholder who has a list of the requirements for the project prioritised by business value.

Maintaining quality levels can be aided through the use of agile development practices such as automated tested, continuous integration and refactoring. http://www.martinfowler.com/articles/continuousIntegration.html

The project team select the highest priority requirements (as specified by the product owner) they think they can build in 4 weeks. So time is fixed, cost is fixed, the highest priority business needs are defined, and how much is achieved (scope) is based on the team’s productivity level.

So whereas PMs own the Iron triangle and spend their time, directing, planning, mitigating, and monitoring progress, Scrum Masters give the responsibility for the scope of the project to the business, set time and cost as fixed, and focus their efforts on the productivity of the team.

The team is responsible for delivery, the business defines the direction or scope, the scrum master helps the team meet its objective for the 4 weeks.

The role change from PM to Scrum Master is not easy… releasing control and sharing the responsibility with others can be a little disconcerting. However, I’ve seen at first hand that the productivity gains in adopting this approach are impressive.

The business sees its highest priority requirements built and delivered every 4 weeks. The team continually improves and increases its productivity levels, and every 4 weeks everyone knows exactly how far the team has progressed because the software is there for everyone to see, test and review.