Agile. Necessary but not Sufficient.
Agile. Necessary but not Sufficient.
[From the Archive: Originally posted at Amplify.com Sep 8, 2010]
For want of a nail...
On Twitter recently I wrote,
“How about taking the whole #agile debate to a different place: The role of Product Development in (technology) businesses…?”
Some folks seemed to express an interest in this idea, so I’ve penned this post to draw together some threads appearing on Twitter and various blogs over the past few weeks and months. I claim no originality in these ideas, but maybe the weaving-together may offer some new perspective.
Am I anti-Agile? That’s as maybe. For my part, I have been evolving my take on the world of work, and in particular the world of work in technology-related businesses – from banks through electronic product companies to software houses, etc. – for over twenty years now. Over that time, I have seen the interest in “Agile” grow steadily, mainly amongst developers wanting to do a better job (and cut out some of the crap from their working practices), and more recently amongst some folks outside of software development, too.
My recent concerns over Agile, similar to those voiced by Al Shalloway and a few others, stem from the observation that many folks – developers and non-developers alike – seem to be expecting too much from “adopting Agile” within their organisations. Yes adopting Agile will often make developers’ experience of work more pleasant. And yes, adopting Agile can often double software developer productivity in the medium term.
But simply applying Agile principles (and practices) within development project teams will typically buy organisations, at best, no more than single-digit improvements in their overall PRODUCT development endeavours (i.e. improvements to the bottom-line). This degree of improvement, even when realised, can often be lost in the general noise of the business, or attributed to many other factors aside from Agile adoption per se.
This marginal value is often further eroded by the increased disruption along the Product Development pipeline, most obviously at the interfaces between the development team and the other folks / departments involved in the wider Product Development effort. In many cases, this disruption, coupled with marginal (apparent) bottom-line contribution, can persuade senior management that the whole Agile escapade has not been worth the candle, with consequent dilution of support. Under these circumstances, Agile sinks back into being – at best – something for the software developers alone.
So to the title of this post. Unwittingly, in most instances, Agile adoption is the vanguard of a shift in mindset within adopting organisations. Agile only really takes hold and delivers productivity benefits with the adoption of new ways of looking at and relating to the world of work (self-organising teams, reduction or elimination of specialisms, new roles for middle-management, intrinsic over extrinsic motivation, etc., etc.).
I believe Agile (or similar) has a necessary role to play in introducing this shift in mindset into development teams. But in no way is this sufficient for the shift in mindset to take root in the rest of the organisation.
In fact, starting in Development – already often seen by the rest of an organisation as a bunch of strange people doing inexplicable things and costing unfathomable amounts of money – would not be my choice of the best place to start a movement towards a new world-view for the organisation.
And without winning the confidence and participation of the rest of the organisation in the ongoing shift in mind-set, Agile builds its own Ghetto.
In summary, the benefits of a shift in mindset throughout the Product Development pipeline can bring compelling, triple-digit percentage improvement to a business’s bottom line. It is necessary for development teams to be part of this shift in mindset, and Agile is ready-made for this role. However, limiting such a shift to development teams alone is in no way sufficient to achieve the compelling benefits of a wider shift in mindset.
– Bob
Think Different
To get the most out of Agile everyone in the company has to buy into it. In a large company there are typically many employees who don’t fully understand at least some aspects of it. Offering full training to every employee is very expensive, and it rarely happens because large companies generally want to start with a small scale experiment to see if it can work in their company.
Often organisations have very established design to schedule practices and not everybody’s mindset is going to change. So you sometimes get Agile practice’s operating within the boundaries of a process that is essentially a design to schedule process. For example the thinking “Yes Agile is going to save our bacon. Use whatever Agile practice’s work, but this project MUST be delivered by year end and MUST have everything.” is one of several anti-patterns in organisations.
In my experience, Agile only has a realistic prospect of working if management endorses and promotes it. In many companies that do not have much legacy code, developers can make small scale improvements by practicing TDD and Continuous Integration irrespective of what life cycle model the company is officially using. But the overall management of large projects typically scuppers efforts to make bigger improvements if the upper management is not sold on the idea of Agile.
Even if both upper management and the delivery teams are sold on Agile, you will sometimes see a frozen middle of middle management who are bemused by the whole “Agile craze”. This will certainly hamper improvement initiatives.
Pingback: The Cold Wet Nose Of Reality | HiveMindNetwork.com