Agile Forest

Last week I revealed a little game/exercise that I have been running to demonstrate the difference between activities and behaviours in a non Agile environment versus an Agile environment and how the activities and behaviours shift to the team and the Scrum Master/Iteration Manager. I would like to now share the results of the game. I have run it twice, one with a strong group of Agilistas (Scrum Masters and Agile coaches) and a second time with a group of Project Managers. What surprised me is that despite the differences in the audience the result was pretty much the same. Maybe it was luck, but I am keen to hear of others running the exercise and if they get the same results (a few people have already shared with me that they have subsequently run it and got a similar outcome). The group of Project Managers that I did the activity with had a really good smattering of Agile practitioners in it which I believe helped to get a similar outcome. In this respect, I am concerned what the outcome would be like with a pure audience of Prince 2, never done Agile, Project Managers.

So what were the results for round 1?

When round 1 is conducted, almost all cards are voted to be best aligned with the role of the Project Manager. The following were the behaviours/activities there were not voted to be a Project Manager’s:

• Deliver the work right
• Deliver value
• Quality focused
• Is 100% allocated full time
• Delivers the right work
• Challenges the norm
• Encourages learning culture
• Mentors team

Which left the Project Manager with the following behaviours/activities:

• Facilitates meetings
• Primary stakeholder is Sponsor
• Primary stakeholder is the team
• Primary stakeholder is customer
• Sustainable pace focussed
• Coaches issues
• Manages ability to deliver outcomes
• Removes roadblocks
• Trains approach
• Resolves issues
• Enables rather than controls
• Makes decisions
• Handles people issues
• Directive, provides answers now
• Has budgetary control
• Ensures benefits realisation
• Delivery focused
• Supports approach

My thoughts on the round 1 results

The following were my thoughts on the results for round 1:

• I thought it was interesting that it was the team and not the PM that was perceived to challenge the norm. Is this an admonition from PMs that they don’t push back on unrealistic timeframes or goals?
• The PM’s primary stakeholder is considered the team, the customer and the sponsor… all at the same time. This question was deliberately worded to force a ‘x over y’ response and yet there was a strong drive for all three roles to be the primary focus for the PM. The conflict between these roles is inevitable and in my belief this is the key weakness of the non Agile environment model – one of these roles will win out over the other two and in my experience, it is unfortunately not the team nor the customer that wins.
• I was somewhat surprised that PM’s felt that facilitating meetings was a core behaviour/activity. I normally would have thought this would have gone to the Business Analyst role but it could depend on how you interpret the question and what facilitation means.
• I was very surprised on the sustainable pace response. I believe there is a gap here of what PMs believe to be true versus reality. When push comes to shove, most PMs I know would push the team to work extra hours/weekends to get a project over the line. I know that there are many of you who are good PMs that don’t do this, but the majority would.
• Additionally I was very surprised that a PM would be coaching issues. Again this may come down to an interpretation of the term “coach” but I am using it in the purest sense that of ‘not providing answers, but instead asking questions to the team so that they themselves reflect to reach enlightenment on the issue’. I’m sorry, but I actually don’t think I have ever seen a PM do this.
• Likewise I’ve never seen a PM train anyone.
• Enables benefits realisation is a tricky one. I do believe that PM’s care for and look out for benefits realisation, certainly very much at the start of a project, but as the project progresses and trade offs begin to be made it is the better of the PMs out there that deliberately report and get validation to the trade off of benefits against time. That said, few PMs stick around long enough to see the actual benefits realised which I believe is sub-optimal as they are not receiving feedback on how well or not they hit the mark on delivery (to me delivery is more than just dates, cost and scope).

What were the results for round 2?

When round 2 was completed, the Scrum Master was given:

• Facilitates meetings
• Coaches issues
• Enables rather than controls
• Primary stakeholder is the team
• Removes roadblocks
• Mentors team

The team were given:

• Delivery focused
• Sustainable pace focused
• Deliver the right work
• Deliver the work right
• Is 100% allocated full-time
• Delivers value
• Quality focused
• Supports approach
• Challenges the norm

Split very evenly between both the Scrum Master and the team were:

• Manages ability to deliver outcomes
• Resolves issues
• Trains approach
• Makes decisions
• Encourages learning culture

The Product Owner was given:

• Primary stakeholder is customer
• Ensure benefits realisation
• Directive, provides answers now

The following were put into the category of “Other”:

• Handles people issues

And lastly, the Project Manager had:

• Has budgetary control

The following was questionable as to where it belonged (if anywhere):

• Primary stakeholder is Sponsor

My thoughts on the round 2 results

The following were my thoughts on the results for round 2:

• What is most clear in this transition are two things, firstly the Project Manager is left with only one responsibility and the rest have been quite evenly spread between three roles – the Scrum Master, the team and to a lesser extent the Product Owner.
• Secondly, there is the separation of primary stakeholders against role. The Scrum Master has the team, the team has the Customer and no one is left looking after the Sponsor. I don’t think this is necessarily correct and would imagine that the Product Owner has the Sponsor’s back, but this would likely also have a conflict against the Customer’s needs. What do you think – in an Agile world, who has the Sponsor (the supplier of money) as their primary stakeholder? In an Agile world should a “Sponsor” exist and if not where does the money come from?
• I love that in an Agile world it becomes everyone’s responsibility to guide others (trains approach), encourage learning, resolve issues and make decisions. Some may argue ‘what if the team disagrees between themselves on an approach’? This doesn’t mean that it goes to a vote for the decision, it means that the team works through the pro’s and con’s and becomes more aware of the depth and breadth of the issue. A leader will always step up for the decision, but it is only done after a more collective understanding is reached.
• Sustainable pace is probably the hardest issue to balance in an Agile environment. There will always be a push from the Product Owner and management to go faster and harder, especially if there is the ‘frozen middle’, a layer of management that does not understanding the essence of Agile. Dates are commonly still unrealistic for many teams and this leads to the inevitable push to work longer hours. Now with the Scrum Master accountable to the team they will likely be the first to push back against this, but the pressure can be immense. For my two cents I have sometimes given in on having a short burst of extra hours, never longer than a month. But let me be clear, I do not believe it helps the team in the long run, nor do I believe it is a good idea due to the impact it has on the quality of the product. This has been proven many times in studies and I have seen the results of even a month of bursting and what it does. Just don’t do it.
• It is interesting that the Product Owner is seen to be directive and provide answers now, but if you think about it, to some extent that is what we are asking them to do. We want them to give us a quick resolution on a question so that we can meet our goals.
• Handles people issues was shifted out as it was now likely being handled by a Team Leader.
• And lastly, the budget problem. If a PM is only left with handling the budget then is it really a role? There is a huge shift towards “Feature teams” – teams that do not form and disintegrate on a project by project basis. In essence work is broken to fit into them rather than teams being formed to fit the work. This results in teams that only go through the Forming-Norming-Storming phase once at their initial creation or subtle dynamic change. The individuals in the team know each others strengths and weaknesses and most importantly they have a fixed team cost. If all work in the organisation is broken down to features that are implementable by the product feature teams then the problem of funding for software development really just boils down to one fundamental question – “What is the most highest value work that this product feature team can be working on?” Then it becomes a somewhat simplified matter of watching the cycle time for the product backlog and seeing the lead time for features to determine if more feature teams are required for that product, or less. In essence, it takes the problem from being a project issue to being a operational issue.

Final thoughts

For those Project Managers out there that are believers in “Theory Y” there is unlikely to be much of a negative impact on you when you shift into an Agile environment. You are already a supporter of empowered teams and consequently this transition should feel very natural and in a lot of respects will result in a better work life balance for yourself as your old duties get spread more when you take on either the Scrum Master or Product Owner role.

But for those Project Managers who align more strongly with “Theory X” then there are some tough choices for you ahead in your future. You can choose to find work in an alternative organisation that isn’t about to go down the Agile path anytime soon. There are still plenty such organisations out there, but be aware that over the next ten years the number of these will likely shrink.  You may not be able to run forever. You can try to hide. You may be lucky and not have a good number of Agile Coaches in the organisation who will spot you and elevate your “Theory X” ways to management. PMOs are great hiding grounds, until they are wiped clean.

Or you can change. It won’t be easy, in fact, it will be months and months of hard work, but you may find an enjoyment and peace that you never experienced before when you make this leap of faith.

For the “Theory X” managers, let me leave you with this parting quote and good luck on your journey.

It is difficult to get a man to understand something when his salary depends upon his not understanding it. Upton Sinclair’s Dictum