Recently, I went to an “Agile Edge” conference at Valtech to hear Greg Hutchings talk on “Introducing Agile”. Here is what I learned.
You must know WHY you want to “do Agile” The normal reasons people state for wanting agile are to: – reduce time to market – be more flexible – be more efficient (less cost) – increase quality. All very laudable and valid reasons but Greg said there was one, less quoted, which he believed had the greatest leverage – to increase customer intimacy. By working with customers, you build up a lasting relationship which can survive many of the knocks of corporate life. Business is, at heart, about people working with people. Efficiency is not generally a compelling case for Agile; flexibility and time to market are usually better. If you launch your services early, then your benefits flow earlier, often dwarfing the cost aspects (although costs centre accountants might not look at it that way!).
One thing Greg warned of was not to aim for all those benefits; you’ll just fail. His advice was to choose just one, then aim and focus on it; keep an eye on the others, but don’t let them drive you. He also warned that some things may get worse, but I am sure you “change-savvy” readers know all about that.
Who wants it anyway?
Greg’s key message was, if there is no-one in the Executive (top) level of the company who wants Agile, don’t waste your time. Successful implementations should initially come top down, with the senior leadership team signed up and then management trained on what it’s all about. You can then come bottom up with the training of the practitioners. Why? Agile relies on the right behaviours which, in some organisations, can look very strange or even appear subversive! (See case study 2, later.) You also need to make sure your sales force and customer services people are trained, so they can explain effectively to customers what Agile is all about. Finally, traditional contracts may no longer be appropriate as they tend to build in rigidity which works against the flexibility of Agile. Naturally, the customers also have to be involved; if they aren’t, you have no “customer intimacy” and Agile becomes futile!
Big bang or incremental adoption? Incremental every time! In this way you have the space to “inspect and adapt” your approaches to suit your organisation. Greg did come across a company where they successfully implemented a pilot in three months and the senior leadership team was so impressed, the rest of the company was instructed to roll it out in the next three months. The manager commented that he did it . . . . but it was nowhere near as well done as the first tranche, as he was pushed to hit schedule deadlines rather than make sure it was right. It seems his leadership team had the view that new methods can be turned on and off like a switch. Will we ever learn?
There is no substitute for face to face working One question from the floor concerned the trend for distributed, remote and home working. Greg was very clear that despite having wikis, teleconferencing, and all that stuff, there is no substitute for face to face work for critical activities. The hidden cost to an organisation of not letting people truly work together can be vast.
Case study 1 – FAILURE
Agile was implemented bottom up on an incremental basis. There was no top-down support. The consultants were removed from the company as what was exposed during the implementation work was too embarrassing for the incumbent Vice President. The implementation had no top down sponsorship nor effective governance. Most of the staff involved were fired. Six months later the Vice President in charge of the area lost his job for covering up some critical business issues. That company now has new leadership and is getting on much better . . . and adopting Agile.
Case study 2 – you’ll die waiting
The second case study is a large, global industrial company. They had executive sponsorship, a core team to implement it but very few people engaged in the outer global reaches of the company. After four years, they decided that Agile was a valid approach to IT development and may be used!
Case study 3 – A large telco – SUCCESS!
This organisation had executive sponsorship, a core team to lead and manage the implementation and good geographic representation. They focussed on product development but were careful to choose which developments in their portfolio would benefit most. They discounted the products at the end of their life-cycle, the cash cows and the highly innovative. They focussed on the others.
…and then Greg ran out of time.
Summing it up My own view is that I can’t see many customers wanting a fixed timescale and price for a variable output from their contractors. So, going in with the approach with an unconvinced customer may be dodgy. Often, however, a company will have many long term contracts which include “future services” clauses to cover stuff the customer wants but hasn’t a clue as to what the real requirements will be. Surely this is the opportunity space for using Agile?
__________________________________________________________________________________________________
This week’s guest blog is kindly provided by Robert Buttrick of http://projectworkout.wordpress.com/
Robert Buttrick is the author of the Project Workout. He has been providing advice and guidance since the publication of the first edition of his best-selling “flagship” book, the Project Workout in 1997 and now its 4th edition. The principles laid out in the publications, take a holistic view, ensuring that culture, systems, processes and accountabilities are mutually compatible. The book has been translated into French, Korean, Chinese, Russian and Romanian
__________________________________________________________________________________________________
Find out more about our AgilePM course and how to embed a culture of innovation in your organisation by learning how to foster collaboration, manage risks and uncertainty, and deliver on time to add value to the business when they need it.
