Monday, 21 September 2009

Becoming Agile? But How Do I Stop Being Non-Agile?

Books on Lean and Agile are stuffed with examples of companies that are and companies that aren't. There seems to be plenty of advice about the core values of Lean/Agile and even some advice on how to cultivate them, but there is very little advice about how to "stop being Non-Agile".

How on earth do you go from every developer 110% loaded, 3 or 4 projects each and each person wearing analyst, architect, developer, test writer and project leader hats to the 20% slack, 1 project each and proper role allocation when management are tearing down the door with the next Big Thing that's going to make the company money every other day?

Now I realise that an answer many practitioners would give would be:
"Get management buy-in"
Great, that seems like good advice, but those of us that aren't on a beautifully functioning Agile team know that when we suggest a change in working practices that the answer's going to be:
"Fine, we can do that when we've finished project X"
Of course, project Y comes along long before X is finished. X 1.0 is rubbish anyway and needs an X 1.0.1 service release, backwards compatibility of X with W rears its ugly head, project Z is already in the marketing pipe (and if you're unlucky, it's already been sold).

It seems that there are quite a few things that may have to happen that are - in the short to medium term at least - extremely incompatible with business needs:
  1. New projects cannot be started. This is terrible news for a company that is scraping by: new products and new releases of existing products are needed to continue to drive sales and a gap in product production means depriving the sales team of oxygen.
  2. Fewer projects can be executed. See 1, the sales team turns blue.
  3. More people are needed. Team members wearing multiple hats is not good, so more roles need to be created if the project workload is to remain high.
  4. Project management has to be improved. Money has to be spent on training and/or coaching.
  5. Development teams need to be shielded from sales and management pressures. This is a perceived problem when management feels the need to control development excessively in order to get anything out of them (and lets face it, they will view a development team operating in a manner as described above as extremely under-productive).
  6. People have to change. The most important thing about being Lean/Agile is its culture, without which a conducive environment can never be created, only simulated in short bursts as the business can afford the spare time, resources and money to do so.
Are there any answers? Perhaps one option is to transition one team. This is probably attractive to management, as it is only a toe in the water and they can pull the plug and go back to the old methods should it fail. The challenge here is likely to be providing the right leadership such that the team is properly shielded from existing external pressures. Additionally, if everyone's working on multiple projects, you can't do this overnight: you probably have to live with people being on many teams to start with and that slowly coming right over time.

What answers do we have to curry favour with management? Of course, we can promise them more productivity in future, but maybe we have to stick our necks out and offer them more productivity right now. If we can start showing management a clear advantage in Lean/Agile practices such as visual control, a clear value stream, better schedule estimation and so on, perhaps this would be sufficient to show greater productivity long before a project is finished.

All of this is of course dependent on changing that key person's mind. Depending on who they are (and who you are), this can be extremely challenging. They have to trust you, so that when you say you can improve things, they'll be confident enough to let you go against history and try it. How can you gain this trust in your abilities to pull off something as managerially and technically challenging as Lean or Agile? Maybe you have to go ahead and do Just Do It(TM) (see Fearless Change) and prove that you can with evidence that you just did.

2 comments:

  1. Hi,

    Most of my agile experience has been in the space you are discussing. The teams I worked with could not drop all of their existing processes and become agile overnight. The management groups I have worked with needed time to buy into an agile approach.
    Based on my experiences I co-wrote a book called "Becoming Agile in an Imperfect World". In this book my co-author and I discuss an iterative approach to agile. The approach involves the existing project team in the agile adoption process, so they can get any concerns they have on the table before agile is even piloted. We also discuss ways to assess risks for your move to agile, so you can share and address the risks with management in advance of a pilot.
    I think the book can help you a lot. I have asked my publisher to contact you to see if we can get a copy to you.
    I can also provide advice via email or a phone if you would like.
    Thanks and good luck!
    Greg Smith greg@gssolutionsgroup.com

    ReplyDelete
  2. Hello Iain,

    Todd Green here with Manning Publications, publisher of Greg's book "Becoming Agile in an Imperfect World." Please drop me a note at togr@manning.com and I'll set up a copy for you. More details on the book at manning.com/smith

    Best,

    Todd Green
    Manning Publications Co.

    ReplyDelete