A Decade in Agile: 1. Breaking the Iron Triangle–Project Manager v Scrum Master

 

This blog is part of the Blog Series: A Decade in Agile and was first published in February 2005. My retrospective comments are in blue italics.

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.

The key difference in approach is the way it is done, not the artefacts themselves. These pieces of information are more likely to form part of a kick-off workshop with the team defining their roles & responsibilities, the Product Owners defining the Vision and Minimum Marketable Features (MMFs), the team identifying risks and then rather than logging them, creating stories that investigate the risk to minimize or remove it. I think the key shift underlying this paragraph is the removal of the “I create” to “we collectively created…”. In Agile, the Scrum Master is not the leading voice, not the commander leading the troops. The Scrum Master is the facilitator, obstacle remover, a servant of the team.

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.

I have a wry grin on my face as I read this… I have recently seen a few Scrum Master role profiles describing the need for Scrum Masters to manage the project to time, scope and budget. At least when you read the job spec, you gain an indication of the level of agile adoption. 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. 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.
This is the key statement within the entire blog. Rather than trying to plan up front how long everything will take and then spend all your time trying to make sure the plan is followed… why not understand what the customer wants, how long we’ve got and then spend all your time helping the team achieve this by removing obstacles, inspiring them, giving them autonomy and ownership. 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 testing, continuous integration and refactoring.http://www.martinfowler.com/articles/continuousIntegration.html

A common pattern for defining and maintaining quality in modern Scrum teams is through the “Definition of Done” (DoD) and the Extreme Programming practices mentioned above. The team defines its quality criteria for each software feature created collectively and hold each other accountable for that quality. The DoD is often printed out and placed somewhere very visible for all team members, so that everyone can be challenged on the quality of product features being created.

Obviously, many teams are not developing in isolation and therefore standards from the wider organisation, or across multiple teams of developers will naturally be included in the DoD.

Some typical problems I’ve witnessed in adopting a Definition of Done:

Aspirational: The Definition of Done should be the quality criteria by which every software feature is completed. Every team member should understand the DoD and be adhering to it every day. One of the problems that re-occurs regularly is that someone has written a beautiful DoD (back to the old PM style – commander in chief) which bears no relationship to what the team can or will achieve. I’ve regularly seen this solved by pulling the team together (usually at a retrospective) and walking through each line of the DoD asking the question “do you do this right now for all features?”

The result is a much smaller DoD, of maybe 4 or 5 lines that everything will meet and everyone can adhere to. You then encourage the team to build it up again with the rules that it is not an aspirational list, it is an operational list.

Evidence / Metrics: I’ve now grown accustomed to seeing one particular line in a Definition of Done: Adheres to coding standards [What does that mean?]

When I see this line item, I usually to ask to see a copy of the coding standards… Responses vary. Assuming that we have some standards to reference, I’ll then ask “to what level are you all following these standards?” And finally, “As a team, how do you know you’re all following the standards and none of you are creating poor code that will impede the team at a later date?”

In 2013, there is little excuse for any team not to be using static analysis tools. These tools can be configured to match your coding standards if required. Your automated builds can treat any violations of coding standards as errors to ensure no poor code is allowed in the source code repository, and beyond that, code productivity tools such as ReSharper help developers identify problems with their code as its written so it can be resolved before going into the build.

So for every part of the DoD (not just coding), we should look for ways to automatically measure adherence to the DoD. The advances in Application Lifecycle Management (ALM) such as automated builds, automated testing, automated deployments, and automated virtual environment provision & configuration, means that teams can much more easily measure the quality of what they are producing… And if you can measure it, you can improve it!

Pressure to Deliver: This problem exists in both the traditional and agile worlds, that of sacrificing quality for a short-term delivery that creates technical debt and will slow you down in the future. Often the person applying the pressure that leads to the short-cutting is unaware of the long-term issues being created, and in less mature agile teams, developers are often not in a position to directly influence the decision. Short-termism is becoming an increasingly common problem which I will cover along with technical debt in a future blog. 
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.

I cannot under-emphasize the fundamental mind-set shift a traditional PM will need to undergo/experience in order to become an effective Scrum Master. Many of us became strong PM’s through taking control of the situation, understanding every facet of a project, exuding assertiveness, confidence, and strong leadership and epitomising dogged determination. As a Scrum Master you have to release control, or as in my case, realise there was no control in the first place, only the perception of control.

Scrum Mastering requires a completely different style. Putting the team as the focus of attention and sinking into the background to quietly remove impediments, coach, motivate and ask questions is not for everyone. It’s the team’s responsibility to deliver the software, it’s the Product Owner’s responsibility to define scope, the Scrum Master helps the team follow the process, and removes impediments.

This can prove even more troublesome in some organisations where promotion, reward and recognition systems  have not moved with the adoption of agile methods. Companies that do not embrace wholesale change will still reward heroics, hitting a plan and getting it done OVER resolving root cause problems, innovation and sustainable growth. Promotion through how many people report to you OVER Promotion through providing business value or profitability. 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