Home » Agile » A role for project managers and business analysts in Agile?

About Allan Kelly

Allan Kelly
Allan Kelly has held just about every job in IT, these days he provides training and consulting in development management, processes & products, especially around Agile. He specializes in working with software product companies, aligning company strategy with products and processes. More about Allan at http://www.softwarestrategy.co.uk/allankelly

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.
 

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

 

One comment

  1. Thank you! And I’ve been thinking I’m an extremist thinking this way… now I see arguments. Thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *

*


four × = 20

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Do you want to know how to develop your skillset and become a ...

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!
Get ready to Rock!
To download the books, please verify your email address by following the instructions found on the email we just sent you.

THANK YOU!

Close