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.