I’ve been working with a number of larger, older organisations recently and it has really brought home to me the difference between the promise of a nimble, responsive teams and the reality of a sluggish, bureaucratic behemoth. Then, looking back over years of writings, posts, promises and dreams I see frequent repetitions of the phrase “Agile says that …” What? What exactly does agile ‘say’?
I’m not going to invoke the manifesto. It’s there if anyone wants to look at it and it is a valuable historical document. Its contents are as relevant today as they were when they were written (tinkering aside), but it is declarative not imperative. It is aspirational not procedural. We can’t ‘implement’ it or ‘transition’ to it.
Instead we have the plethora of methods that existed at the time of its original drafting and a few more besides. Many of them include recipes, processes, state diagrams – but they don’t seem to reliably help organisations improve their ability to deliver. These organisations need to change, but not according to some checklist brought down from the agile mountain chiselled in stone. The agile values and principles help us suggest ways of change, but that’s as far from a recipe as the contents of a box of oatcakes are from the serving suggestion in the picture.
There are plenty of winds in the world. There are the four winds. There are the trade winds. There are the winds of change. And there is… how shall I put this delicately?… bottom wind.
One of the definitions of flatulent is “generating excessive gas in the alimentary canal”, but it’s not that relevant to what we’re discussing. A more appropriate definition for my purposes is:
I’ve heard it said that team-scale agile is a solved problem. Tractable certainly. Solved? I’m not so sure.
What I am sure of is that most of my clients have more than one team; that the business people do not sit with the teams; that the budgeting process is project oriented. Agile-at-scale, for all the loud trumpeting of processes and successes, is much more like an unflushed toilet than it is a delightful plate of food at your favourite restaurant.
I wrote a number of posts a while ago arguing that the “Death of agile” was exaggerated and I still believe that to be the case. We will never cease to seek out ways to deliver what our customers want and working closely with them, using tight feedback loops, evolving the solution will continue to be the most appropriate approach in many contexts.
However, we need to watch our language and curb our promises. Management of expectation has been handled very poorly – and such actual data that there is has been overstated and wilfully misinterpreted. Nobody benefits from this in the long run (although, in the short run some people have made a fair amount of cash 😉
I’ve heard it said “better out than in” in response to the flatulence of the first definition above. It’s time we applied that adage to the second definition too:
- out with unsupported claims
- out with inflated and empty promises
- out with pomposity
- out with turgid templates and processes
Instead, we should caution our customers not to expect too much. We should tell them about the failures as well as the successes. They have to realise that daily stand-ups, a handful of CSMs and a CI server will not, on their own, transform the organisation. Anything else is just flatulence.
PS – have you seen any fine examples of agile flatulence? Please tweet them with the hashtag #FlatulentAgile