Archive for the ‘Agile Project Management’ Category

How are agile projects managed?

Scrum is the agile process with the most to say about the management of a project, so let’s use it as our model process for answering this question. On a Scrum project, there are three roles: product owner, ScrumMaster, and team.

The product owner is responsible for the business aspects of the project, including ensuring the right product is being built and in the right order. A good product owner can balance competing priorities, is available to the team, and is empowered to make decisions about the product.

The ScrumMaster serves as the team’s coach, helping team members work together in the most effective manner possible. A good ScrumMaster views the role as one of providing a service to the team, removing impediments to progress, facilitating meetings and discussions, and performing typical project management duties such tracking progress and issues.

The team itself assumes the responsibility for determining how to best achieve the product goals (as established by the product owner). Team members will collaboratively decide which person should work on which tasks, which technical practices are necessary to achieve stated quality goals, and so on.

From looking at these three roles we can see that management responsibility is divided among a project’s product owner, ScrumMaster, and team.

Is the ScrumMaster considered the agile project manager?

Not really, but perhaps the world may come to view the ScrumMaster as a 21st century version of the project manager. Unlike a traditional project manager, the ScrumMaster is not viewed as the person to credit (or blame) for the success (or failure) of the project. The ScrumMaster’s authority extends only to the process. The ScrumMaster is an expert on the process and on using it to get a team to perform to its highest level. But, a ScrumMaster does not have many of the traditional responsibilities—scope, cost, personnel, risk management among them—that a project manager does.

 

Who handles traditional project management responsibilities?

Traditional project managers take on a great deal of responsibility. They are responsible for managing scope, cost, quality, personnel, communication, risk, procurement, and more. This has often put the traditional project manager in a difficult position—told, for example, to make scope/schedule tradeoff decisions but knowing that a product manager or customer might second-guess those decisions if the project went poorly.

Agile processes acknowledge this difficult position and distribute the traditional project manager’s responsibilities. Many of these duties, such as task assignment and day-to-day project decisions, revert back to the team, where they rightfully belong. Responsibility for scope/schedule tradeoffs goes to the product owner. Quality management becomes a responsibility shared among the team, product owner, and ScrumMaster. Other traditional project management responsibilities are similarly given to one or more of these agile roles.

 

Does this scale?

Agile processes like Scrum are definitely scalable. While the typical agile project has between five and twenty people across one to three teams, successful agile implementations have also been used on projects with 200-500, even 1,000 people. As you might expect, projects of that size must introduce more points of coordination and project management than small-scale implementations.

To coordinate the work of their many teams, larger projects sometimes include a role called project manager. While involving someone on the project with this title or background can be very helpful, we need to be careful of the baggage associated with the title “project manager.” Even on a very large agile project, much of the project management will still be done by teams—for example, teams will decide how to allocate tasks, not a project manager—so the project manager role becomes more one of project coordinator. Duties would include allocating and tracking the budget; communicating with outside stakeholders, contractors, and others; maintaining the risk census with guidance from the teams, ScrumMasters, and product owners; and so on.