The Agile Project Manager – Does it exist

Recently I attended a seminar on “Agile” software development. One of the statements made by the presenter was to the effect that once agile is implemented properly an organisation will quickly realise that they don’t need project managers. The reason… the close, frequent interaction between the business and developers means that the management of a project is handled almost as a by product.

I’m not convinced by this thinking, unless it is restricted to the simple case of a small project with a fully committed and engaged product owner. In more complex situations (e.g. Multiple agile development teams working on a project in parallel) someone is needed to keep everything lines up and remains on track. Sounds like a project manager (PM) to me…

So in this situation, what makes a Project Manager an Agile one? How can you recognise one? First and foremost an agile project manager will be able to facilitate two competing needs

  1. help the project accept and adapt to change
  2. prevent change impacting the project delivery

This is the challenge in agile, where it is possible to do everything the client asks but not everything they ask for should be done. If you only have a product owner and the scrum master then in complex environments the former is likely and without the checks and balances that a disciplined project manager brings to the table then projects will fail.

I do believe the nature of project management will change. With more and more projects being delivered using agile or lean methodologies it has to. The focus for a project manager will become ensuring the delivery of the right thing at the right time whether that is requirements, designs, code or a functioning product. This is essential when the paradigm is iterative.

Project managers will live and breathe the mantra “if you don’t need it now… it can wait” and every will focus on Just In Time delivery. Or it will once vendors and customers figure out how to work effectively together using agile…

Lessons Learned – not a one off activity

So many times I have been involved in projects where once the solution has been delivered a project manager, sponsor or vendor will say “now we need to review the project and record the lessons learned”. The idea being that the lessons can then be used to ensure those mistakes aren’t repeated, or that things that really worked well can be replicated on subsequent projects.

Sounds good, right? Wrong! Why should the next project be the beneficiary of your hard won lessons? A lessons learned log should be maintained throughout the life of a project. The log should be reviewed and discussed within the team regularly and include stakeholders or their representatives from the business. That way you can:

  1. prevent poor behaviour recurring
  2. identify good behaviour and encourage it to be repeated
  3. capture key business drivers that have been highlighted by any issues that have arisen
  4. highlight areas of conflict between business areas (e.g. Sales v marketing) and the best mechanism(s) for resolving the conflict.

By doing this throughout the life of a project, the project becomes self correcting as those individual experiences are shared with the team. This reenforces behaviours, establishes trust within the team and with the business and ultimately helps improve the chances for the successful delivery of the project. At the end of the day delivery is what it’s all about.