Why is so hard to educate a waterfall project manager to take a role in a Scrum Team?

(Cabanas Beach, Portugal) A lot was written already in this blog about why we have more advantages adopting Agile methods. The truth is, once an organization decides for an Agile Transformation, adopting Agile methods and, particularly Scrum practice, to train and educate resources can be a terrifying challenge. Even with training, the roles will change. The background experience required for a Scrum Master or Product Owner role, for instance, is very different from what normally it comes with an experienced resource acting as project manager in waterfall methods since many years.

The normal background and experience of a waterfall project manager

In waterfall, the main objective of a project manager is to deliver the agreed project in time, budget and quality. Pursuing a sequential V process from requirements, development, testing, training, deployment, support and maintenance. The project manager plays like an enabler for required resources, conditions and materials. He orchestrates all, respecting the upfront agreed Roadmap, steering stakeholders, mitigating risks if necessary, developing contingency plans.
He feels more committed with the “make it happen” than with “what is delivered”.
I heard already in my career proud waterfall project managers saying “I did an SAP project without never had tried SAP”. For me this is completely inconceivable…
A waterfall project manager has a temporary engagement perspective: he will be there until the project roll-out, after leaves to other project.
This is the project approach and not the product approach. In the product approach we have a long-term commitment and a complete engagement with the value to deliver.
The waterfall project manager has all his focus to maintain project sponsors an stakeholders satisfied: delivering in time, scope, budget and quality. We can’t see here an important role for users and customers. Users and customers are taken in consideration in 2 different project moments:

  • 1st moment: requirements phase.
  • 2nd moment: testing, project validation and acceptance, training and support.
  • In this second moment, users or customers are exposed to a complete product version, with a set of features. The collected feedback is accumulated and not so detailed feature by feature.
  • Have in mind, in waterfall, the presence of the project manager in those interactions is not mandatory. Those tasks are often delegated to experts without any contribution from project manager side.
  • Other tasks normally not considered: retrospective and seeking permanent improvement. The waterfall project manager normally doesn’t retrospective meetings with the development team, he is not feeling as his responsibility items like team satisfaction, team capacity and velocity, so he is not taking as part of his role a permanent attitude of seeking improvement wherever it can come.

Why this experience is not bringing so much value into the Agile practice

So let’s see which type of skills and experiences develops a waterfall project manager:

  • He Identifies expert resources required to execute project tasks;
  • He guards and updates budget and road map;
  • Regularly he requires updates, risks and dependencies from implementation team and summarize them in steering meetings to board of sponsors and stakeholders;
  • Organizes escalation if necessary;
  • Communication and negotiation skills are very important for this role.
  • Meetings organization and moderation across different hierarchical levels: bottom level with experts, top-level for executive update and problem escalation.

Those type of skills are appreciated in any project but in Agile we are organized in a different way and part of the tasks described above are distributed among different roles.
An Agile Team is self-organized, each team member knows his area of expertise and takes stories or tasks for his own implementation. With the time spent, the team often selects “naturally” who is the test expert, the architect, the back-end developer, etc.
Story assignment is done by the Scrum Master or by each team member, acknowledging their individual areas of expertise, taking over spontaneously their own responsibility.
Escalation, risk mitigation and unblock dependencies is a Scrum Master task. But it’s also a permanent sense of performance improvement, team motivation and satisfaction, what we never observe in a waterfall project manager.
The Product Owner brings product vision, features, the customer voice. Essentially requirements, engagement to build the best product, consolidating strategy into customer value… but this is also not a task of the project manager.
This permanent need to develop skills oriented to bring and consolidate value to the customer is essentially a mindset challenge for a waterfall project manager.

(adsbygoogle = window.adsbygoogle || []).push({});

Advanced, SM

Leave a Reply