Where Does a Project Manager Fit in Agile?
When I talk with teams adopting agile, there are two groups that seem to have a bit more consternation adopting the new method -- project managers and business analysts. Perhaps I notice it because those are the two roles I usually fill. More likely it's because those roles are specialized for phase-based project approaches, and their applicability in agile projects is not as obvious.
To understand where project managers fit in an agile project, it helps to know what roles exist in agile. The different agile approaches have different titles for various roles (because the agile community apparently likes to make up new words for stuff). I chose to use the labels created by Scrum because they tend to be the most commonly known in the project management community.
- Scrum Master
- Product Owner
The Scrum Master acts as a facilitator and guide, helping the team with the agile techniques they choose to adopt and with good software development practices in general. They facilitate key team discussions, and help the team figure out how to apply techniques and continuously improve their approaches. The Scrum Master also clears obstacles that prevent the team from being as effective as possible.
The founders of Scrum picked the unfortunate title of Scrum Master for this role to indicate the difference from traditional roles on project teams, and to indicate that the person filling this role needs to be well versed in the principles and practices of agile techniques. I prefer the term Coach, but it has developed its own separate definition with the rise of the agile coach -- meaning an advisor that specifically helps the team with agile practices, but may not be considered a part of the team.
A Product Owner is someone with a need that the team is trying to satisfy. In an agile project, the Product Owner makes decisions about what features the product should have and the priority of those features. This role represents the perspective of the business, so you want to have close communication between the person or people who have a need and the team trying to satisfy that need. In some cases the people with the need are not readily accessible, either because of their position in the organization, or because the product is intended for sale to the broader market. In either of these cases, you need someone who has a good sense for what the needs are and can make decisions in their stead. You can think of this person as a client proxy, and they may have to become very good at balancing the needs of several users, customers, and stakeholders. The idea behind this role is to provide a readily available source for information about the product and priority decisions about features.
The Team is the group of people who deliver a product that satisfies the needs of the client. It includes all the people with the skill sets necessary to deliver the product, usually people with analysis, user experience, design, development, and testing skills as well as others. The lack of distinct role definition among team members is intentional. It reinforces the idea of a cross-functional team that focuses on having all the necessary skills as opposed to a collection of roles. The team determines how much they work on in an iteration, who is going to work on what, and how they approach the work. The assumption is that the people doing the work are the ones who know best how to do the work.
A Stakeholder is anyone who impacts or is impacted by the project. In effect, this label could apply to all the roles, but for our purposes here, stakeholders are identified as everyone who doesn't fall into one of the other three roles but still has some interest in the project. Of particular interest in this group are the actual users of the result of the project (I'll refer to that as the product for simplicity's sake), the people who buy the product, if the team does not have direct contact with them (think "customer"), and people in the organization who play a cursory role in developing the product and supporting it once in production.
So where do project managers fit? It depends on the nature of the individual and the nature of the project.
If you find that your project management style is to work closely with a team or could be described as "servant leadership" -- teaching more than telling, facilitating more than directing -- you may find that you can slide into a coach role very easily. You may need to increase your understanding of agile values, principles, and techniques first, but having the coach mindset will help.
If you find that you spend most of your time as a project manager focusing on what the project is trying to accomplish, worrying about product scope, and figuring out the business implications, you may be able to act as a product owner, especially in those situations where the actual sponsor or clients are not easily accessible. You actually would be more of a client proxy, which has become more common as the adoption of agile has spread. Brush up on your analysis skills before tackling this role, because these are critical to success as a product owner. If you're one of the former business analysts who only switched to project management because it seemed like the next best step on the career ladder, you may find yourself sliding into this role.
Perhaps you have a background in development or testing, and got into project management because it looked like a good career move at the time. Now that you are there, you may realize it's not quite right for you. Agile provides a great opportunity to move back into development and testing and while applying the project management skills you learned. You can become a member of the team doing development work, but also helping the other team members with estimating, and figuring out how to get some of the work done. In this case you may need to brush up a bit on your technical skills.
Finally, if you were born to be a project manager and like to coordinate the activities of others, there is still a need for this role, especially on more complex projects. You may have to revise your leadership style, especially if you tend to act with a command and control mind set. You will find that trying to dictate modes of operating to a set of self-organizing teams will cause a great deal of tension in the project team and will greatly reduce the overall effectiveness of the team.
So how do you know which projects require that type of coordination?
The Context Leadership Model is a handy model for determining how the nature of the project drives the need for project management. This model was created by Todd Little at Landmark Graphics. He took a look at his project portfolio and examined the projects on the basis of two primary sources of risk -- uncertainty and complexity. Understanding how uncertain and complex a project is helps you to determine an appropriate approach, and as a result the appropriate style of leadership needed for the project. The four project types are:
Sheepdogs (low uncertainty/low complexity): These projects have clearly defined scope and are ones the organization does quite frequently. These projects require a minimum core set of practices and little to no process ceremony. Basically you want to leave the team alone to deliver.
Colts (high uncertainty/low complexity): These are projects that introduce a new product, service, or process or are adopting new technology. These projects require a small team working close together in frequent iterations to get continual and rapid feedback. They also require a leader who has a good understanding of the source of the uncertainty (whether it is business, technology, or both).
Cows (low uncertainty/high complexity): These projects usually involve mature systems that are core to the organization's operations and therefore have several interfaces with other systems. These projects usually have large project teams (or preferably several small teams) which increases the need for coordination and published interfaces.
Bulls (high uncertainty/high complexity): These projects usually involve new products, processes or services that require the core systems of the organization. An appropriate approach to dealing with these types of projects is to split the effort up into a focus on the uncertainty and a focus on the complexity. As a result these projects require coordination, strong communication, and an understanding of the sources of uncertainty.
Projects with high complexity (those classified as Cows or Bulls) generally require someone with traditional project management skill sets to coordinate the several moving parts that these projects usually contain. Those moving parts may be the multiple cross-functional teams created to scale the project, or the multiple other teams impacted by the project. When you fill this role remember that you are coordinating the work of a set of self-organizing teams, so you should plan on spending more time facilitating discussions and gauging whether you should stand back or step up in your interactions with the teams.
So when you get an opportunity to work on an agile project, think about the type of work you like to do and how you like to approach project management work. You may find that you can fill one of the roles usually associated with agile projects, you may find that the project is complex enough that it needs coordination, or you may find that you are not a good fit for that project. Going through that thought process before you start on the project will save a lot of frustration and wasted time in the long run.