#localgovcamp – Agile session


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

One comment
  1. LouLouK

    June 22, 2011 at 12:50 pm

    Hi Catherine, I just wanted to say, the permission to fail aspect was not the only learning I took away from your session – the other was an understanding of the traits of innovative teams (small, fleet of foot, fail fast, recover faster etc) and working to peoples skills and not grades. It was helpful because I now understand something which has been puzzling me for a long time about how I’ve ended up quite where I am doing quite what I am doing.

    The answer, of course, is that in the public sector things are skewed. Or rather, that in a private company, if you had a ‘cell’ of agile innovators, then you would pay them all the same and assume that even if one person had nothing to contribute to project a online right now, that they would have maximum contribution in project b coming online in Autumn and so would earn their money across the year, as would everyone else.

    The problem with this approach in the public sector is that it breeds resentment sometimes (I am not saying always) and it’s something that does need flagging if this is going to move forward. Firstly, it can ruffle the feathers of the ‘I’ve been here longer than you therefore even though you are the same grade as me I can talk down to you and make you feel like you’re an inch high’ brigade. Secondly, there’s something really wrong when the disparity of pay is stretching into the thousands between the team members all being expected to operate on skills not grades. Thirdly, trying to move to this model while retaining traditional public sector hierarchies ends with a situation where manages can feel cut out of the loop if people don’t understand what is happening – and even if they do in some cases as resentment builds as to why one persons skills means they get all the fun stuff and another means they get all the day to day drudgery.

    I think what I’m trying to say is, allocation of tasks cannot only take into consideration skill sets in the public sector, there must also be team politics and hierarchies considered as well. Other wise it can get very messy and very upsetting evry quickly indeed.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *