Managing Agile Projects

Like Kevin Schlabach, I keep hearing that Scrum removes the need for Project Management or that Agile teams don’t need management. Really? REALLY? Whenever I hear this I tend to splutter and all the things I want to say try and come out at once so I end up looking and sounding like a gormless idiot (what’s new…). So here’s an attempt at getting some of those things out one at a time.

First off, a caveat: I’m no project manager; I realised this about myself about 15 years ago. However I do believe I recognise a good manager when I see one and I believe I understand the value a good PM brings to a project. This wasn’t always the case but I had the good fortune to work with James Spalding for a number of years and learned a number of extremely valuable lessons.

Lesson #1: Product Management ≠ Project Management. This misunderstanding possibly has a lot to do with the title of Ken Schwaber’s Agile Project Management with Scrum, an extraordinarily mis-named book given that Scrum is neither an Agile method nor a project management method. A project is an activity undertaken by a team of people to deliver something of value over a period of time and to a budget. Product management methods such as Scrum deal with the ‘something of value’ but but not the team, time or budget bits.

Lesson #2: Self-organizing teams need management. Whoa there Dyson, have you gone completely mad? Self-organizing teams organize themselves. Yup, but organizing is not the same as managing. Unlike many managers I had met before, James understood that management is nothing to do with telling people what to do and how to do it. Good managers set the constraints that define the boundaries within which the team organizes itself. Some examples of these constraints:

  • The size and constituency of the team. Neither the Scrum Master nor the team themselves can simply decide to hire a new team member or exclude someone from the team, there are factors to consider such as employment law, budgets, HR processes, company career structures, and so on. The team may play a big part in influencing such constraints but it should be the PM who sets them.
  • The roles needed in the team. Like it or not, the answer to “who is responsible for XYZ?” cannot always be “the team collectively”. The project needs to send someone to take part in the ‘enterprise architecture meeting’ where each system’s role in the enterprise is discussed along with potential approaches to integration. Who do you send: the whole team, someone chosen at random, the ScrumMaster? Even Agile teams need people who will take responsibility for particular aspects of the system based on their skills and experience and the PM is often the best placed to determine which roles the team needs to organize around.
  • The nature of the project. The product owner takes responsibility for the product and there may be cases where the only concern of a project is the product. There will also be many cases where the project has other goals to meet, perhaps specific deadlines or standards, that are at odds with what the product owner wants and the PM needs to ensure these needs are balanced.
  • Rewards. Many agile team members will have their job definition and career structure defined along traditional lines of skills + experience + individual excellence = pay grade and job title, and there’s often not a lot they can do about it other than leave the company and start their own. This formulation can actively work against the ‘whole team’ nature of an Agile project and its up to the PM to set the constraints of how team members behave in order to achieve individual recognition in a process that encourages anything but.

Lesson #3: Projects go way beyond the delivery team. Who communicates to the wider organization about the purpose, progress, nature and experiences of a project? In large organizations in particular this is a vital part of any project’s success and can be close to a full-time job. In theory anyone on the delivery team could do it but they should be busy delivering. In practice, these types of interaction typically require specialist knowledge and skills that, with the best will in the world, many delivery people lack. A good PM brings political awareness, great interpersonal skills and a decent appreciation of the appropriate level of detail for the audience to the mix.

Lesson #4 Backlogs define products; milestones, deadlines and budgets define projects. If I had a pound for every CEO, CIO or business customer that said to me “Agile teams can tell me what they can deliver in 3-6 weeks but not what they can deliver in 6 months or a year, or what it will cost. This is no good to me” I’d have, well, about £10. But it would the hardest and saddest £10 I ever earned. Agile teams absolutely can deliver to milestones, deadlines and budgets but not through the application of Scrum, the employment of a coach/ScrumMaster, or by simply by being self organizing. ‘Traditional’ project management techniques, such as those promoted by Prince 2, have to be adapted to an Agile environment and who better to guide that than a good, experienced PM. Some of the mechanisms have to be ditched and replaced with something more appropriate (think broad release planning vs. detailed Gantt charting, burn-rate management rather than traditional resource dependencies, etc.), and most practices need to be tuned to concentrate on real, rather than derived value, but they are still necessary. And do you know what? Forget projects, most businesses are run according to milestones, deadlines and budgets, not backlogs. How can you claim to be delivering ‘business value’ if you can’t work within the basic framework of business?

Lesson #5 Scrum Masters remove impediments, PMs prevent them occurring. Things move fast in an Agile team and it is easy for the Scrum Master to get wholly involved in the day-by-day, hour-by-hour, minute-by-minute execution of the process. That’s fine, that’s their job. Who thinks about ordering new hardware because there are two new starters next month, organizing an education session on a new set of standards that need to be met, ensuring that the overly-enthusiastic new IT director is introduced to the team without totally disrupting the project? A good PM can ensure that the impediments the Scrum Master deals with are all the usual delivery issues, not issues introduced by a lack of basic management.

There are more but I’m running out of steam … perhaps another day. My point is that most projects I’ve seen or been involved with benefit from having a good, skilled, experienced, full time project manager in addition to the Scrum Master/coach role. These two form a pair who take care of the running of the project that enables the delivery team to build a great product; the Scrum Master tends to be focussed on the project team and the near-term, the PM on the wider organization (including the project team) and the mid- to long-term. Without this role (or even with the Scrum Master trying to play both roles) you’re facing a situation where the delivery team might be great at delivering the product but the project will be deemed a failure.


5 thoughts on “Managing Agile Projects

  1. Martin Proulx

    Good post overall but it seems you may be making a few assumptions that I don’t fully agree with. Who said the role of the Scrum Master cannot exceed that of the team coordination. In many organizations, the Scrum Master reports back to management committees and takes part of enterprise wide discussions. You may have heard about a Scrum of Scrums where the SMs from each team get together to address broader issues.

    In my opinion, the point is not to see the role of the PM and SM as totally opposed but as complementary. A good project manager who would be a certified Scrum Master would certainly help move the project forward.

    1. pauldyson Post author

      Yes, to a certain extent I do assume the SM focuses on team co-ordination. Of course the SM can report back to management committees and take part in enterprise architecture discussions. They can possibly also deal with all HR issues, manage budgets, construct mid-/long-term plans, fix a few bugs and make the tea. But just because they can doesn’t necessarily mean they should; as you say the PM and SM are complementary and I believe in the value of pairing these roles rather than giving them to one, extremely overworked person who becomes a single point of failure on the project.

  2. Thushara

    Nice posts.. lots of good points.. But some of them I dont fully agree with. Actualy I think most the points discussed here really depend on the context of the project and work env,

  3. Pingback: Shearing Layers in Software Delivery Part 2: A Reasonable Model « Paul Dyson’s Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s