What a Traditional PM Should Unlearn to Play a ScrumMaster Role

Key changes to be effective

26 May 2014


Often organizations take a simplistic view toward the transition of projects from traditional methods to Agile when it comes to roles. IT leadership tends to believe that, with some training in Agile methods, a traditional project manager (PM) would naturally transition into a ScrumMaster. This is not always true.

Training would help in understanding Agile concepts and appreciating how the Agile method differs from traditional ones. However, the transition of people from traditional methods to Agile calls for a change in mind-set. This change is essential as the ScrumMaster has the responsibility of implementing new concepts and maintaining Agile values within the team.

It is but natural that the IT leadership would decide to identify internal candidates and invest in training and coaching traditional PMs to take up the ScrumMaster role. The PMs, for their part, should fasten their belts to groom themselves for suitability for the role.

This article discusses the key things a traditional PM has to unlearn in order to play the ScrumMaster role effectively.

Give up command

Traditional command and control models leave little flexibility. The PM almost completely owns the planning and monitoring of the project right from the initial stages. And usually the PM has the authority to take control and call the shots in operational matters. In contrast, when the PM becomes a ScrumMaster, he should give up command and play the servant-leader role. As a ScrumMaster, he should front-end his team and create a participative culture in which the entire team is responsible for taking the project to completion.

The PM should realize that one of the fundamentals for a ScrumMaster is to articulate the shared vision for the team and enable the team to achieve the common objectives. Taking command over the team would not help the culture of self-managed teams.

Get away from the Gantt!

Gantt charts serve a great deal for planning and monitoring a project. A traditional PM looks for all the details to the nth level when commencing the project. She uses the Gantt chart to accurately map the activities against timelines and identifies the milestones. However, in an Agile project where change is welcome and adaptability is key, the ScrumMaster cannot wait to start the project until all the details are made available upfront.

The PM, when transitioning herself into a ScrumMaster, should learn to start off with the available details. She should appreciate the power of the sprint backlog and daily stand-ups to get a handle on the project and take the necessary steps to keep it moving as per the planned sprints. In close collaboration with the business, she should be able to align the sprint deliverables with the milestones.

Get directly involved

In an IT organization following traditional methods to manage a project, there will be clearly defined hierarchical structures. The PM and the teams have to navigate through these structures to get decisions made. The PM usually relies to a great extent on the immediate next level -- the project lead -- to get the project status and measures. This could result in delays, loss of communication, and inaccurate status if not managed with rigor.

The potential ScrumMaster should get involved directly with the team and understand from the members their work, progress, and challenges. He would not have a second-in-command to feed him the project details. The daily stand-up is a powerful tool for the ScrumMaster to use to get an up-to-date status of the project and project reports to the stakeholders. Further, the sprint retrospective helps the ScrumMaster understand the root causes of any issues and take corrective action for the subsequent sprints.

Let the team estimate and accomplish

The aspiring ScrumMaster should resist effort estimation based on her own expertise, past experience, or any predetermined organization-level baselines. Estimation in an Agile project is a different ball game. Here "games" are played for arriving at estimates! The team decides the best estimates based on consensus. The ScrumMaster should facilitate the team's arriving at this estimate, rather than forcing her own ideas.

Once the estimates are finalized, the ScrumMaster should let the team pick the stories and work through them. She should not allocate tasks to the team and monitor them but let the team self-manage and accomplish the sprint goals. Micromanagement and detailed status meetings are a no-no for the ScrumMaster.

More measures, more effective? Nay!

The traditional PM should come to terms with a simpler set of measures that would serve the purpose in an Agile project. Measures such as team velocity and number of stories completed versus planned in a sprint do help the team understand their progress and make improvements. He should not attempt to track every possible measure and load the team and the leadership with charts and reports that result in excess information.

Involve the business continuously

Agile is about close collaboration with the business. The traditional PM should move away from the model of involving the business stakeholders just twice in the life cycle -- at requirements definition and acceptance testing. When taking over the role of a ScrumMaster, she should learn to involve the business on a continuous basis, sprint after sprint. Though the product owner is the customer of the development team, the ScrumMaster should develop a partnership with the business through close engagement with the product owner.

While working with the business, the ScrumMaster should also sensitize the stakeholders to learn that completely detailed and signed-off requirements are not a must for starting an Agile sprint. She should help make the stakeholders confident that the Agile model is flexible enough to allow changes, and through planning and prioritization all business requirements and changes will be addressed to deliver the solution that best meets the business objectives.

Finally: Appreciate the SDLC in the Agile world

The aspiring ScrumMaster should appreciate the interpretation of the solution development life cycle (SDLC) in the Agile parlance. There are no "phases" in the life cycle. Hence he should not expect that implementation of every requirement necessarily follows the phases, such as design, development, testing, and integration. He should understand that all these happen in every sprint, executed by a cross-skilled team.

What is acceptance testing? Is it absolutely essential? The aspiring ScrumMaster should understand that every sprint review demonstrates the completed deliverables to the product owner and in a way that is acceptance testing. Supported by a clearly articulated Definition of Done, the objective of acceptance testing could well be achieved through regular product demos. However, the ScrumMaster should also be open to plan an exclusive "acceptance testing sprint" if the project context calls for it.

And there are more!

The PM, while transitioning into a ScrumMaster role, should resist the following as well:
  • Suggesting release plans only after detailed analysis and design
  • Committing to a scope and handing it over to the team for implementation
  • Expecting sign-off from different stakeholders at every stage of the project, resulting in delays (the ScrumMaster should get the stakeholders to agree upfront on the engagement and review model)
  • Standing in for the product owner and providing clarification to the team on business requirements
Thus, transition from a traditional role to ScrumMaster is a challenging shift that requires conscious effort to move from the "command and control" attitude to the "first servant" mind-set. This is not a switch but a journey that involves learning, introspection, and experimentation.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.8 (5 ratings)

Comments

Krishna Kumar C, CSM, 5/26/2014 2:06:52 AM
good one
Gurpreet Singh, CSP,CSM, 5/27/2014 8:05:59 AM
truly agree :)
Tim Baffa, CSM, 5/27/2014 4:40:22 PM
Very good article. The Agile journey is a never-ending process.

Being a former traditional waterfall PM, my experience in learning to become a better Scrum Master has involved avoiding most situations where I can be inserted as an additional layer between the team and the business/stakeholders. At every opportunity, the SM should encourage direct communication between the team and the PO/business, and learn to refrain from becoming an information radiator to either party.
Ravishankar N, CSM, 5/29/2014 12:45:33 AM
Thanks Krishna Kumar and Gurpreet Singh
Ravishankar N, CSM, 5/29/2014 12:47:59 AM
Thanks Tim Baffa. Glad that you have successsfully navigated through your situations to trasition into an effective Scrum Master !
Neeraj Malkoti, CSM, 5/29/2014 3:17:56 AM
Good article.
Thanks for sharing, Guys.

- Additionally, a Scrum Master needs to read a lot! Learning needs to be a core focus area for a Scrum Master. Be it an amateur or an experienced SM- all need to invest significantly in Learning & CI!

- Remember, success belongs to the team.
SM is *not* a value worker, simply a support system. He takes no credit if team hits sprint goals (unlike football coach!).

So be humble & keep serving! :- )

Cheers
Malkoti
Karthik Kumar Kasaraneni, CSM, 5/29/2014 4:47:45 AM
Very good tips for upcoming CSMs :) I believe this unlearning is very crucial and important to become a successful CSM. Thanks for sharing.
Gene Gendel, CSP,CSM, 5/31/2014 9:41:07 AM
Good topic Ravishankar and Alka. May I also add this to the subject? : …what do organizations need to unlearn about Traditional PM role? Is every traditional PM of yesterday - a good candidate for becoming an effective SM of tomorrow? When feature teams are formed, is it really PM that should step into SM’s shoes? Are not there better choices?
For organizations that transform to agile the biggest dilemma is cultural shift and organizational restructuring, specifically organizational flattening, restructuring of personal assessments, appraisals and compensation schema, etc. This drives many other things: personal career decisions, news skills learned. Transforming organizations start trimming waste, remove redundancy and, potentially, roles that are not as important any longer in self-organized culture. True, there is still a lot of traditional/conventional PM work that needs to be done. But lots of it should be shifted to the business side. The overall amount of traditional PMs that are still required becomes smaller as organizations flatten, cultures change and feature teams get formed. You are listing well some of the personal adjustments that conventional PMs need to make in order to remain in demand. I would also add that PMs need pick up some useful functional skills that would make them more useful for product development ( I am stressing the word “product” here as agile is focused more on on product development, not so much project management). I think your article is a good synopsis of what a good SM needs to do and anyone who wants to take on SM’s role should keep this in mind, regardless of their past :).
Ravishankar N, CSM, 6/3/2014 4:45:36 AM
Good point Neeraj. The SM doesn't take sole credit for the team's success - true !
Ravishankar N, CSM, 6/3/2014 4:47:56 AM
Gene Gendel, you are right - the organization should also understand the special nature of the SM's role and should not push every single PM to take on the SM's role.
Gayathri Narayanan, CSM, 6/6/2014 8:29:33 AM
Thanks for this good article, guys
Ravishankar N, CSM, 6/24/2014 2:59:56 AM
Thanks Gayathri for the comment. Glad you find it good.
Leonel Zapien Lopez, CSM, 6/27/2014 4:29:00 PM
Excellent article, you summarized in a very clear and accurate way the considerations for moving from PM to a SM role. Also, I agree totally with Gene Gendel and his comment: It is really important to think about the considerations from the point of view of the organization, and it could be one of the biggest constraints. An organizational culture change is needed, other way the transition to Scrum couldn't be achieved.

Congratulations, good job!
Ravishankar N, CSM, 6/30/2014 1:53:57 AM
Thanks Leonel ! Agree with the point that the organization should also need to understand the role of the SM and facilitate developing the appropriate culture for transitioning into the new roles and new ways of working.

You must Login or Signup to comment.