13 May 2013

Help! They're running an Agile project, how do I know when to worry?

The parents of teenagers and new-to agile project managers seem to have rather a lot in common. There are a few similarities that spring to mind immediately, such as; grey hair and  large mobile phone bills. They are also likely to be experiencing an underlying sense of uneasiness, coupled with cautious optimism and occasionally sheer panic. I have teenagers and am working with a new-to-agile project manager, so I feel qualified to comment.

Neither teenager(s) or Agile projects do well under helicopter style management, but the parent, or PM's urge to operate this way is very hard to resist. It's tough when you find that your customary approach to feeling in control of a situation no longer works and it's very hard to resist worrying all the time, about whether you should be worried or not, especially when the subject of your worry is adamant that its "all good".

In a plan-driven software development project, the number of requirements completed versus the planned requirements completed over time appears to provide meaningful information about a projects status, any deviation from the plan is seen as a red flag. When there are a lot of these, you know exactly when to worry.  In the context of an Agile project, things are not so clear cut, the team may be delivering done requirements on a regular basis, but the extent to which these represent business value is the key indicator. There are obviously challenges in quantifying something as subjective as business value, but this represents the only the tip of this particular iceberg. Both Agile approaches and plan driven approaches have the same goal, which is to improve the outcomes of the software development process but they approach this goal from fundamentally different philosophical perspectives. This philosophical divide becomes very evident when an organisation tries to introduce Agile methods at the team level, but fails to do so at the project governance level.  

When I needed to select a research topic as part of my ongoing studies, I decided that it would be interesting and possibly useful to investigate this. I was particularly interested in finding out how this issue is solved by organisations who's governance and reporting infrastructure is designed to use data from plan driven projects, but which develop software using Agile approaches. This research will take several months to complete and as always step one is a search and review of the academic literature in order to understand current thinking and knowledge.

Whilst there is a lot of fantastic and relevant material in the professional literature (everything which doesn't count for the purposes of ERA) my review includes only the academic literature which presents empirical research and has been published by ERA ranked journals and conferences. Doing this review was an interesting exercise I learned a great deal but the output does not constitute light reading, so for fun, I've winnowed  12 years of literature and the 6000 words I wrote down into 3 paragraphs.

I found that between 2002 and 2006, a lot of research was conducted which looked at Agile transitions in general, while there was some discussion of project governance and reporting most focused on the implementation of Agile methods and the experiences of those at the team level. Where governance and reporting was covered it was identified as an emergent problem. Between 2006 and 2008, a number of case studies were published which did focus on this issue, my personal favourite being a detailed study of the Agile transformation undertaken by an American energy company DTE Energy where the introduction of Agile methods and the focus on delivering business value at the project level is credited with being a key factor in the organisations achievement of CMMI accreditation.

Post 2008 the topic seems to vanish from the academic literature, there are a few papers which discuss very specific ideas such as using earned value analysis (EVA) to report on Agile projects. There are also a number of studies which report on organisations where a move to an Agile approach was  undertaken at the whole enterprise level and where working with stage-gate governance approaches is simply not a factor. In some cases Agile methodologies were seen as the only way to manage the complexity and variability of a specific project, in other cases, such as at Cisco Systems, the use of Agile approaches as best practice was taken so seriously that the organisation invested in an Agile office as an adjunct to the Project Management Office (PMO) in order to ensure that everyone was on the same page. I suspect organisations which take this kind of approach are unusual and that 3 or 4 years ago it was still the case that the adoption of Agile methods was most often driven by software development practitioners rather than from the C suite.

Whilst the academic literature didn't provide any clear answers, of the 20 - 30 papers I reviewed a number of strong consistencies did emerge and included the following, all of which, I think most practitioners would consider to be in the "duh" category

  • Stage-gate approaches to project governance are potentially very compatible with Agile methods.
  • The key success factor for organisations considering Agile implementations is the incorporation of Agile values across the enterprise including at the leadership level.
  • The key failure factor for organisations considering Agile implementation is an inability or unwillingness to engage with Agile values at the leadership level. 
  • All Agile adoptions, are in fact Agile adaptations there is no "one right way" and that a pattern based approach rather than a prescriptive rule set is needed.
  • That Agile coaching is almost more necessary at the C level than at the software team level, since software teams don't seem to have any difficulties seeing the benefits.
There you go, validation if you needed it!

From a practitioner perspective things seem to have changed a bit over the last year or so; entering Agile as a keyword in a job search returns as many results for project manager roles and business analyst roles as it does developer roles.  A quick search of the professional literature suggests that within the project and program management community reporting on your Agile project and the challenges this presents has been a key topic for quite some time now, but is still been driven by practitioner community. This looks a lot like the early majority, perhaps the C'suite will be the late majority, hopefully not the laggards.

At the very least figuring out what is going on here, will very likely keep me out of trouble and distract me from worrying about my teenagers for the rest of the year. 

If anyone would like the full list of refereed papers and articles, please let me know and I will be happy to provide it. 






























        







4 comments:

  1. Kelsey, interesting set of observations.

    I suspect that the Lack of enthusiasm for helicopter style control is not unique to Agile. No one likes to be micro-managed - so this is a universal issue. As a PM you need to exercise discretion and common sense and allow people do what they do best, i.e. do their job. For whatever reason Agile teams seem to complain about this more then others as they see this as an unnecessary and redundant interference. This is unfortunate and, at least in my mind, is an indication of an immature attitude to delivering a service that ultimately costs someone money. The perception that agile teams will deliver the best value money can buy if we just leave them alone and let them manage their own affairs is just a perception. Your teenage analogy is therefore fantastic. Teenage kids think they are mature and knowledgeable enough to make decisions on their own - and indeed in some cases they certainly can. But this is a rule that certainly calls for exceptions as although we want to train them and provide them with the opportunities to exercise their decision making process we are still allowed (and indeed required) to occasionally override their decision as it is plainly wrong. Similar to teenagers, members to agile teams need to grow up and accept the fact that they are not operating in a vacuum and that their performance and attitude are subject to critique - like everybody else.

    Cheers, Shim

    ReplyDelete
  2. Shim, interesting points.

    Regarding your call out about who is best equipped to make good decisions, I agree that often teams are too locally focused to see the big picture. (I assume you are inferring that.)

    I'd reckon most managers fall into exactly the same issue. the key thing is to get close to the customer so you best understand them.

    ReplyDelete
  3. Very good point Shim, I agree with you that we just can't assume that every agile team is equipped and mature to be able to work with full autonomy but at the same time, we shouldn't assume otherwise.
    In my experience, every team should start with some sort of guidance and boundaries with an eye on future for them to be autonomy. The example I always like to use is the sand example - If you have to pick some sand in your fist, the harder you'll squeeze, the little will left in you hand but at the same time, if you don't apply enough grip, all sand will slip by.
    The key is to find the balance.
    Anyway, that's my 2 cents worth :)

    Vinay Tripathi

    ReplyDelete
  4. Very good point Shim, I agree with you that we just can't assume that every agile team is equipped and mature to be able to work with full autonomy but at the same time, we shouldn't assume otherwise.
    In my experience, every team should start with some sort of guidance and boundaries with an eye on future for them to be autonomy. The example I always like to use is the sand example - If you have to pick some sand in your fist, the harder you'll squeeze, the little will left in you hand but at the same time, if you don't apply enough grip, all sand will slip by.
    The key is to find the balance.
    Anyway, that's my 2 cents worth :)

    Vinay Tripathi

    ReplyDelete

Search This Blog