So – this is the write up from the agile session I led at #localgovcamp. Much of the preamble I started off with can be found in other blog posts but the core of the session was trying to move the conversation that was had at UKGovCamp in January on a bit further – so am going to assume that you know a bit about the context and not cover earlier stuff again here. In terms of direction of travel I was particularly trying to focus not just on barriers but on the actual shape of a more agile organisation.
@LoulouK has written a really good response to the session which looks at this from the point of view of someone who is trying to be more innovative within her organisation so you should have a look at that as well. Not come across any other write ups – but please shout if you have.
I should say here – I think there is some crossover in terminology and often when I am talking about agile I could be talking about any kind of innovative structure – and I felt the group also moved between definitions. However there are two main reasons why I tend towards using agile as a personal shorthand for a more innovative and future proofed organisation approach:
- the challenges that caused the software engineers to move towards agile style methods are similar to those faced by whole organisations now; absence of fixed context, speed of change, challenge from the environment to list a few
- Many of our organisational structures are going to be technology faced – it helps to share thinking with the developers of these solutions
However as the session concluded (with some good thoughts from @harryharold on this) its important to accept the limits of the metaphor. Perhaps most specifically there is a limit around testing. Unit testing is a bug element of the software approach which is perhaps not replicable in an organisational context.
We also discussed another potential limitation which is the difficulty of operating in this way in a political context where the leadership have their eyes simultaneously on the next election and the next headline. We concluded that you would need strong alignment between political and officer leadership in order to deliver innovation on this kind of scale.
Its a guerilla war
In an agile organisation you should be able to push decision making out as close the project delivery frontier as possible – once again its about trust. We felt this implies an organisational structure which relies on small teams which are formed around the project requirement and then are dissolved back into a talent pool when the project is completed. These teams need to be trusted empowered and informed.
There are some ramifications to this statement:
- You need to focus on people’s skills as much if not more than their experience or their grade
- You need to spend time developing team working skills to give people the tools they need to be effective in this environment.
More than that you need to both recruit and performance manage to support these kinds of skills – this is potentially a long term change. The question is how you get it started – but imagine if you started creating these agile teams via 3 month secondments within your organisation.
There is also the question as to how you integrate innovation back into the organisation – this secondment idea could address this.
Our most important conclusion around how you create an agile organisation was the belief that we need leaders not managers – there is a big difference.
Failure – how interesting…..
We spent a while talking about failure. The mantra of agile software development is fail fast, fail cheaply. The fast project cycles mean you try things and rapidly discard them if they don’t work. We agreed this was one of the most difficult ‘values’ to put into place in the rest of the organisation with failure being seen as something with politically and organisationally difficult to accept.
There is no quick answer to this but we discussed a couple of useful tactics:
- Take risk management seriously – have a proper conversation about what the level of acceptable risk is and stay within those boundaries. Over time you should be able to change this.
- Create a body of evidence – we have a responsibility to show this approach works rather than expecting people to take it on blind faith but instead be open and honest about evaluation
- More challengingly – don’t pretend everything is a success – but communicate failure as progress – because it is
- Innovate at the edges – do the duller less risky stuff first. It may not be the most exciting stuff but it makes a big difference and it allows you to learn and build evidence in parts of the organisation where the issue of failure is less acute
We also talked about collective and individual responsibility – an reflected on the fact that a lot of lone innovators end up accepting organisational risks. We also talked about the more negative coping tactic of ‘consultant scapegoating’ where you get external contractors to do your failing, or innovation, for you. The issue here is a need for organisations to take responsibility for innovation but in the context of agile we are back at the question of trust – are you trusted to innovate?
Trust me – I’m an innovator
As ever with an open ended session we are left with questions:
- Do we have enough trust in the people within our organisations?
- How do we need to change not just the organisations but also the people within them to create a culture of innovation?
- Do innovators do enough to earn trust?
- Can we change attitudes around failure to embrace more learning and more innovation?
These are not unusual questions – the additional question is whether the agile metaphor is still useful in exploring and addressing them. My view of the session is that the answer is yes. We need to keep in mind the limitations that I stated at the beginning of this piece but I still think this is worth pursuing.
As ever – please let me know if you don’t think this reflects the session or if you have comments – thank you