Monday, June 17, 2013

A role for project managers and business analysts in Agile?

I was in Krakow last week at the PAM Summit of the Project Management Institute (PMI) and International Institute of Business Analysts (IIBA). I delivered a presentation entitled “Is there a role for Project Managers and Business Analysts in Agile?” - now online via SlideShare. Those of you in the London area can go even better, I’ll be repeating the presentation at Skills Matter next week. (Its free, its 6.30pm on the 24 June, sign-up on the Skills Matter website.)

For those who can’t I’ll talk through the question a little...

It is helpful to reference the “Iron Triangle” or “Triangle of Constraints” or “Project Constraints Triangle” - call it what you will, here it is again:

Many reader may have seen a slightly different version before. My version has neither cost or quality because I don’t believe these represent trade-offs:
  • Cost for a software development team are overwhelmingly wages, the more people you have, the longer you have them for the more money you spend. So Cost= People x Time. And people and time are both on this triangle so you can calculate cost, or vice versa.
So my preferred version looks like this:

Which leaves Features/Functionality/“the what” as the only place where we negotiate.

Which makes answering the original question very easy for BAs. Business Analysts have skills around exactly this question. There are a number of ways a BA can help: perhaps as a proxy customer, perhaps as a Tactical Product Owner, perhaps as a detail guy, or perhaps working with testers. Every team should have one (almost).

For project managers things are decidedly more complex. Much of their traditional work around “when” is redundant, since we are aiming for stable teams and sizing work to the time work around “who” is also gone. I can imagine, indeed I have seen, small teams dispense with project managers entirely. You can be successful without a project manager.

However for larger teams there is probably a role that needs filling. At a very basic level there is administration and reporting, there might be co-ordination tasks too, they might work with the BA/Product Owner around stakeholders, and when there is a client/supplier relationship both sides will probably want some managers “managing” the relationship.

But while there is management work to do I do not see a role for “projects.”

Successful software lives, it changes, if requires enhancements, adaptations. Only dead - unused - software doesn’t change. Developing a software product is like building a company: if people stop asking for things you are out of business.

Which conflicts with the PRINCE-2 definition of a project: “A temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources.”

Successful software does not have a pre-specified end date, indeed it can be incredibly hard to determine when many projects actually began!

Successful software isn’t temporary and the organizations which support/service it shouldn’t be. They may grown or shrink with time but we should aim for stability.

And since Agile embraces change the outcome isn’t pre-defined either. Indeed since all successful software changes in ways which are difficult for the originators to see there are only short term outcomes.

To me it is obvious that software development does not, and never really has, conformed to the project metaphor. Indeed I think using the project metaphor seriously damages software:
  • It leads to endless, pointless, discussions about “when will it be done”
  • It leads to governance processes that attempt to finish things which are not finished
  • It leads to short term thinking over things like quality
  • It leads companies to disband successful, performing teams - a condition I have termed Corporate Psychopahy.
BAU - business as usual - isn’t a dirty word, it is the normal. Supporting software, adding feature, fixing bugs, enhancing products is Business As Usual, we should be proud of that.

Then if we specifically look at Agile ways of working many of the traditional assumptions of project management are invalidated:

  • Teams are encouraged to self-manage: determine the details of the work to be done and decide how best to tackle it themselves
  • Agile teams are inclusive and non-hierarchical
  • Agile teams communicate peer-to-peer rather through some centralised communications hub (i.e. a manager)
In short Agile assume a “Theory Y” way of working not the “Theory X” which is implicit in too many project management texts.

And if you think I am radical then let me tell you I am a moderate, there are those who will go further. Look at my Scrum-Scrum-Scrum post last year and the discussion which followed, or watch Christin Gorman’s video “Adding a project manager to a Scrum team is like making cake with mayonnaise.”

The net upshot of all this is simple: Project Managers need to reinvent their role. And the reinvented role probably doesn’t include the word “project”.

For any software development team - especially one that wishes to be considered agile - the default choice is probably: no project manager. The onus is on the role holder to demonstrate how they add value to the team and to the wider organisation.


  1. Project Management played the most vital role in business. It helps to allocate and manage project resources, roles, and responsibilities and limit the rights to access projects to required persons only. With the proper management of project the business grow up more.Keep sharing such knowledgeable post. Thanks.

  2. Gracie, I've approved your comment but I must say it has the ring of spam about it. I'll give you the benefit of the doubt today!

    While I understand where your comment is coming from I think it demonstrates a somewhat dates attitude to project management.

  3. I repeated this presentation (with a few additions) at Skills Matter last night, the video is available here:

    Bruce Melendy on Twitter ( pass on this article from Marc Lanchorst which also argues against project thinking:

    I agree with all of Marc's points although I may not have explored them in my presentation some of them were definitely in my mind.

    On Twitter the hashtag #NoProjects is occasionally associated with this topic.

  4. Your post is really amazing. The video of your presentation is quite eye-catching. I appreciate your work. And the post has many new things for the readers to learn about.

  5. Allan, I agree with all of the above. I would actually split this article into two:

    1) BA and PM role in agile
    2) No Projects

    Your thinking on #NoProjects is invaluable as ever.


    1. teve, yes, I think that will happen. The next revision of the presentation is going to the BCS PROMS-G (Project Management Group) next year

      allan :)

  6. The Project Manager makes final decisions on trade-off studies, and task changes within the contract statement of work. The Project Manager is responsible for daily communications and formal project reviews with both the customer and his/her senior management. The Project Manager shall provide written direction to the various functional organizations on their individual contribution. As a project manager it is important to be able to give and receive feedback effectively. Feedback is best given on a one to one basis soon after the event that triggers its need. Here are some tips that can help.

  7. I found these iron triangle diagrams to be particularly helpful. My team always has an issue with quality IT, since we are a small business and are only just 3 years old. We've recently adopted new shipping software solutions that have proved we can handle maintaining quality connections with our customer-base.


Note: only a member of this blog may post a comment.