Agile. Necessary but not Sufficient.
[From the Archive: Originally posted at Amplify.com Sep 8, 2010]
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.