It is well known that elephants cannot dance. It is less well known why that is. Helpfully, this year’s Royal Institution Christmas Lectures have thrown some light on the subject. Essentially, elephants have big fat legs because as size doubles, mass cubes, so proportionately fatter legs are needed.
Mark Miodownik, the lecturer, demonstrated the effect of this by putting on some sandbagged trousers and attempting to dance. It was not a pretty sight.
It is not just elephants (or elephant wannabees) which have this problem. Organisations, or projects within organisations, are increasingly attempting to be agile – or rather Agile. The more elephantine among them may find that quite hard, and even those which succeed may not look terribly elegant in the attempt. It is a common observation that small agile companies lose agility very quickly as they grow and probably a still more common conception that public sector organisations never have any agility to start with. Three years ago, when I wondered why change is slow, I thought that differences were far more a function of size and longevity than they were of sector, and I have seen no reason since to think that that is wrong.
The problem is that knowing that doesn’t necessarily help. Beginning your project by making your organisation smaller or younger isn’t normally an option. Having made that realisation, there is probably not much in the way of sensible generic solutions: navigating each particular organisation’s culture and ways of getting things done will resist generalisation.
But there are some points worth a bit of reflection.
The first is that faster moving parts running up against slower moving parts will generate heat and friction. That can’t be avoided, because in an organisation of any size, being agile has to start somewhere, but can’t and shouldn’t start everywhere. So getting a small, committed group of people together to identify and implement a solution is is essential, but is a long way from being enough. The point of a skunkworks (though I am with Steph Gray on the use of that much overburdened word) is to deliver more effectively for the organisation of which it is a part, it is not to be wholly separate. That has implications not just for managing expectations and communications but also for governance processes designed around an assumed way things are done. The essential point is that if heat and friction are unavoidable, coolants and lubrication are vital to the smooth running of the machine.
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The second is that agile approaches move organisational power – and that this is a good thing. Decisions being taken in the moment are decisions not being taken by a hierarchy of ever more important committees. If the committees are still going to be there, and it feels a fairly safe bet that in most organisations they won’t self destruct at the first whiff of agile, they will need to be helped to resist any temptation to fill an apparent vacuum. Conversely, those unused to being trusted with authority will need to learn to take it – and as importantly, to know when the issue is such that they should hold back from taking it.
The third is that the process gives early and persistent voice to the users of the service. If it doesn’t work the way they need it to, it doesn’t work. That’s not to say that it necessarily works the way they want it to, that’s another matter for another time. But it does mean that user testing as a discrete activity, and even more as a final stage activity, is out of place. Users may, of course, have some uncomfortable messages – in fact any appearance of there being no uncomfortable messages should probably itself be interpreted as an uncomfortable message. The question is how to deal with them in a way which is constructive in relation to all the interests involved. That is a particularly acute issue for a new or significantly changing service, where even customers cannot be expert on service experiences they have never had. Facebook notoriously rolls out changes to the user experience in the teeth of vociferous customer opposition, banking on the fact that six months later the derided change will have become the new standard. That may or may not be seen as an example to emulate.
The fourth is that all of this gets more complicated in a political environment. Political change is in many ways even more closely aligned with the waterfall method than conventional IT development. In central government the traditional sequence runs from think tank to manifesto to green paper to white paper to primary legislation to secondary legislation – and user involvement in design (as opposed to citizen consultation) comes only very late in the process. What happens, though, if the agile design process identifies ways of delivering the service which deliver the policy objective and efficiently meet user needs, but which are different from those envisaged in the process of developing the policy?
And finally, there is an elephant in the room, and it’s not necessarily the one which is trying to dance. Why, in this context, are we talking about agile at all? The Agile Manifesto is very explicitly about software development. I have heard agile described as applying the principles of lean to IT change. What, though, if we are not interested in IT except as a means to the end of some broader change process? The mantra that there is no such thing as an IT project has become a commonplace (in words, if not always in deeds), and it surely cannot be helpful to go back to IT-led change. Michele Ide-Smith has recently reflected on this point and points out that just changing ‘software’ to ‘systems’ in the Manifesto completely changes the scope of its application.
I have no problem with the idea that agile has outgrown its roots in IT. On the contrary, I very much welcome it: in many ways, agile is an encapsulation of many of the ideas this blog has been going on about for years. If we can bring together the technical and non-technical aspects of service design and implementation in a way which can make change happen more quickly and more effectively, that can only be a good thing. Whether it actually has outgrown its roots in this way is a question it will be interesting to explore.