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.


  1. Wow. I get the feeling this post is an outcome of much thinking.
    Picking up the first point about friction and heat. I definitely agree with this. People working differently causes consternation not only among those doing the differently, but also those surrounding them who must interact with them. I don’t think that working in silos is going to be possible, should sectors move this way, because no one team can act in complete isolation. Every team, in theory, is a customer of someone else, or a deliverer to someone else. So, in the process of changing working practices, there will by necessity be a knock on effect onto other areas, and the requirement to explain why your team is working that way, what benefits there are, and what expectations there are of stakeholders.

    This means that acknowledging differeing team cultures even within a wider organisation is necessary. Dynamic people, I think, tend to gather in the same place, or rather, certain disciplines require certain personality traits for you to be good at your job in that service area. For example, GIS teams need have an attention to detail and not be intimidated by large amounts of data. But, following process flow from a to b right the way through to z is also part of the necessary skillset in order to succeed in that area. How will people respond within these teams to being told b no longer follows a, but that there will be a.1, a.2 and so on and actually, you may never get to b, but jump straigh to e.

    Perhaps, where I’m going with this, is that perhaps agile is not appropriate for all areas of an organisation, even if they’re involved with project management.

  2. I came up with a hypothesis a few years ago, when pondering the question: why is government so poor at delivering technology?

    I’d looked through a few Gateway reviews and they hadn’t given me the answers, so I thought about the issue of tempo.

    The political tempo is quite rapid, really. On something like a four-year cycle we have rises and falls, twists and turns of policy. Programmes starting, stopping, mutating – sometimes with quite rapid dislocations.

    The tempo of civil service administration is not so rapid. It was once said in jest that a good unit of measurement for the time required to achieve change in the civil service would be the geological epoch. In reality, it may be more like a twenty-year change cycle for anything substantive.

    My theory is that we’ve evolved a long cycle civil service to counterbalance what would otherwise be a highly volatile and unstable government running on a short cycle.

    And because the cycle required to do technology sensible (both in terms of technology change and requirements) is far, far shorter than this long cycle, things keep going wrong.

    Could be utter rubbish, mind you.

    1. I think it may be less geological than astronomical. Some kinds of change require the right conjunction of the heavenly bodies. It is not that change cycles are inherently long, it is that the optimum conjunctions are relatively infrequent – “Sometimes rare opportunities arise such as when Voyager 2 took advantage of 175 year planetary alignment (launch window) to visit Jupiter, Saturn, Uranus and Neptune”. The trick is to spot them coming and, as far as possible, be ready to take advantage of them.

  3. To pursue the analogy, I suspect elephants may dance when bitten by millions of gnats.

    What I mean is that the latent energy to make large organisations move faster has to be drawn from how customers behave, especially now we can harness their feedback and collective spending power.

    Empowered individuals with tools for self-organisation and budgets….can give energy, direction and resource. I think the Guardian’s new model of engagement gives a hint of what is to come….

  4. An interesting post, and a common issue I hear from fellow Civil Servants. Within the public sector body I work for, and in particular the department I work within, we have become masters at agile working, not only in the context of project work, but within our whole working practice.

    This doesn’t mean we are blasé, we’ve just removed unnecessary over-cautious ‘flab’ from the way in which we work. In the current climate it’s essential that the public sector learns quickly to work in this way. There is a glorious opportunity for the public sector in this period of transition to throw off the shackles, and to learn to think quicker, work smarter and really do ‘more for less’.

    To be truly agile and innovative, which many of us are damn good at already, we need to collaborate more closely at a national and local level and those who already do ‘agile’ need to evangelise and share it with colleagues.

  5. 1 In some circumstances, government is perfectly able to achieve astonishing agility…in the midst of appalling floods in Australia right now, I can assure you that many government agencies are working with exemplary speed, responsiveness and flexibility. The fact that they can do this in a crisis (the “blitz” phenomenon)does raise the question, of course, why the same agility seems to be so elusive when the crisis recedes.
    2 Again in the Australian context, I think of the almost ridiculous speed with which our national welfare and social payments agency, Centrelink, has to move to turn policy and benefits changes, usually announced in the Federal Budget, into instructions to the payments “machine” to make sure the new amounts are factored into the next round of payments. Believe me, this is agility on steroids. There would be plenty of other agencies I’m sure who could provide similar examples.
    3 Sometimes good government means exactly NOT being agile. Aren’t there times when we want governments to be ‘slow’ – that is, deliberative, time for judgment, perhaps time to be more inclusive in thier search for input, ideas and inspiration?
    4 But finally, I’m firmly with those who I think rightly sense that, too often, there are cultures and processes and conventions in government get badly in the way of the kind of legitimate agility that, in a networked world especially. There are lots of ways that government does need to smarten up in the agility stakes…and there are plenty of good examples in government’s own most agile moments to draw on as pointers to what is required.

  6. Very thought provoking.

    First let me caveat my response. My job is in a private sector web development agency that delivers system solutions to the public sector (among others), so my take on this is perhaps bounded differently as I’m approaching this from the outside in.

    While I’m extremely interested to see how the public sector can seek to adopt agile principles in areas other than software, my main interest relates more to trying to better understand how to get public sector organisations to see the advantage – and control – that can be gained from adopting agile methods in its software solutions (particularly crucial now that channel switch has become a key strategy to so many public sector organisations).

    Your comment about key factors in the speed of change being size and longevity, rather than sector is one I’m not sure I entirely agree with. I’ve been involved in delivering agile software projects to organisations across multiple sectors; my experience has been that the number of stakeholders ‘with skin in the game’ in a public sector project is exponentially higher than in any other sector. Each one of those stakeholders requires some degree of convincing of some variation of the same point: That agile does not equal risk.

    Once engaged, the process wins converts extremely quickly and – to pick up your analogy – the friction is reduced, the cogs turn and the elephant sprints. But the journey of getting to that point is a very rocky road to navigate – especially on an elephant.

Comments are closed.