Once the mainstay of software development, the project manager faces risk, if not extinction, on some Agile Teams. This tip explains what a person in this situation can do to reinvigorate his role and the productivity of the team. To start, let's take a real example from my own experience.
The project to pilot Agile development was hand-picked, managers, team leads and executives all working with speed and fury. In the middle of the room sat Darrell, the project manager, looking dejected. If you asked Darrell what was wrong, he would point to the Scrum board and say, "If you want status, just look at the board. I don't know what I am doing here."
Darrell's concern was that in this Agile world, he could not add value. Many of his traditional tasks -- like estimating, assigning tasks and communicating -- the team had consumed. The two most popular methods for Agile software, Scrum and Extreme Programming, both leave out the project management role entirely.
Darrell's concerns were reasonable. Unless he changed something, his role was in jeopardy. Darrell has skills that could be valuable; all he had to do is adapt. Let's talk about how.
What Scrum includes ... and leaves out
The basic roles in Scrum are technical staff, product owner and Scrum Master. The technical staff builds the product, the product owner tells what the product will be and provides priority and the Scrum Master makes sure that everyone sticks to the rules and helps eliminate obstacles. If these three roles are done well, then planning, estimating and status communication all sort of fall together naturally.
Notice what Scrum does not include: long range planning, dealing with excess work in progress or communicating across teams and to upper management. Portfolio management, contract management, staffing. In the Scrum world, the team is magically born into the world and never changes.
Every difference between the real world and the Scrum world is an opportunity for a project manager to add value.
The Agile project manager in action
It's Monday morning back at the office, and Darrell the project manager is looking for work. What could he be working on?
- Communication and coordination across teams. Larger companies have other technical teams that make assumptions about what the software should do, who will do it, who needs to regression test and so on. Project managers can get out in front of these requests, negotiate them and get them on the team's radar.
- Coordinating out-of-band work. Personal development, goals, conference attendance, corporate training -- all these things take time and effort but may not be captured on the Scrum board. If no one is watching out for these, either the team will fail in its commitments, because the absence wasn't taken into account, or people will feel pressure and just not do the out-of-band work. Most likely, you'll have both. Project managers can manage a whiteboard for time off and make sure out-of-band work is tracked and accounted for in order to relieve the team of paperwork, not inflict it.
- Communicating with upper management. Having every executive attend every stand-up meeting may tell them what is going on in the moment (the "scoreboard"), but doesn't provide any sense of higher-level progress, like a seasonal win/loss average. Because there is no standard way to present these higher-level reports, executives often feel at a loss on the status of the portfolio.
Project managers can create these communication tools while sharing and standardizing them across multiple projects. The project manager provides the interface; this allows the teams to self-organize and change the way they do work without worrying about how it is communicated.
- Dealing with excess work in progress. Darrell could look at the board and "watched the flow" -- excess work on any one tab means a bottleneck that is slowing the team down. He could work to improve the process, to move away from iterations and toward one-piece flow.
- Recruiting. Most companies still have HR departments with gatekeepers, a hiring website and an interface. Someone needs to understand the general skill sets that make the team run, select candidates, talk to HR, set up initial phone interviews and bring people in. This work "keeps the engine" of the Scrum team running, a recurring theme in the evolving project manager's role.
- Contract management. Like recruiting, contract management is work that has to be done but nobody wants to do. It also takes away from the traditional, technical team work, and has nothing to do with product vision. It falls through the cracks and involves the kind of specific, precise language that project managers tend to be experts at.
- Metrics and measurement. Points per week, standard deviation in points per week as a percentage, cycle time, points remaining and a burn-up chart are all ways to measure and predict work, and it is the type of work for which project managers are often well-suited and qualified. Project managers who take on this responsibility will be doing so as team members -- not team masters -- as the team owns the metrics. The PM can add value by collecting the metrics, synthesizing them with measurements on other teams and communicating them to management in a way the team can agree on and support. (These should be team numbers, not individual performance metrics.)
- The Scrum Master role. I've left this one last because it so easy for project managers to fall into, and I am reluctant. Traditional project managers who get shoehorned into Scrum Master roles often try to control information flow, creating summaries with bullet points, instead of facilitating a conversation. Likewise, while the Scrum Master needs to remove impediments, this is very different from keeping an issues list that a more traditional PM might.
- Application lifecycle management. Agile teams tend to focus on the now, or current project, and may have issues planning for the new project or juggling priorities. Or the teams might fail to support old projects that have support or maintenance issues. Project managers who can see these holes and help the team plan for them can help the organization steer the ship.
Where the Project manager is traditionally the boss of the team, the Scrum Master is a servant. It might be more fair to think of the Scrum Master as a sort of process improvement consultant, who gets the team moving, but, after six to twelve months, isn't really needed any more.
Putting it all together
When I look at the "Agile Pilot" project Darrell was working, it is the "pilot" part that strikes me. The project involved no dependent teams, no vendors or subcontractors and had no external deadlines to drive to. This meant that Darrell could not add value with the techniques above.
Real projects have these sorts of problems. When they come up, if project managers step up and say, "Let me handle that," they can keep the engine of the team running for years to come.
This new role will be negotiated, and change will come one step at a time. The trick is to start where you are, see the work that is not being done and offer to do it with a smile.
If you can do that, then the real challenge of project management in the 21st century will not be one of relevance. It will be finding the first things, the most important things, the valuable things to spend our time on.
Find those valuable things and help the team accomplish them, and you'll never worry about work again.