Agile


This is my write up of the session that @pubstrat and I curated at UKGC12. Large apologies for the delay.

@pubstrat and I have been meaning to have coffee and general catchup ever since UKGC11 and I am hugely glad we finally managed it as it set my brain buzzing – will be stalking him for more regular meet-ups as a result.

The conversation built on earlier discussions about how we might apply agile principles outside of software development and into the wider project management process. The reasoning for this is twofold – firstly that coders have developed Agile in response to working in a shifting and boundary-less world which is the situation we are all faced with and secondly because of a need to harmonise project and software management practices if you want technology dependent projects to work. More on this background here.

The UKGC session focused more directly on how we might approach amending project management practice – the subtitle of the session could be ‘plan for the permanent eradication of PRINCE2’.

I’ve broken this post into sequential steps for project management. Apologies for the bullet points – I will expand on anything that doesn’t make sense if you ask…

**Scoping the project**
Scoping the project is about setting up the boundaries and ensuring that you have a clear vision as to what you are trying to achieve. This is even more important with respect to Agile projects in my opinion as they can, if not tightly managed, take off in unexpected directions and you end up with an outward focused spiral rather than a tight development process. The points we discussed with respect to this in the session were:

  • Be less obsessed with edge cases – agile is about focusing on the main body of the work and dealing with exceptions as exceptions rather than core functionality. Its interesting to reflect on exactly how that feels culturally in the public sector.
  • Understand the minimal viable product – This is not a limit on ambition but instead a clear description of what actual achievement that you can build on looks like
  • Don’t run away from it because it’s difficult – run towards it – problems are not reduced by hiding from them
  • Create a lean start up mentality – don’t try and plan for every eventuality instead get the basics in place and build as you need to.

**Creating the team**
Teams are created – they don’t just happen. I think too many project managers ignore this piece of the puzzle and then wonder why the developers seem to be masters of passive resistance. You need to set a context that all participants can work in.

  • Find emotional connection – stop imagining that you can get programmers and non-programmers to speak the same language. Instead focus on the emotional and narrative impacts of the project which is where these different skills and knowledge bases can come together
  • Bringing different cultures together – any large project is about blending internal and external cultures. Do this knowingly and create a new culture for the project.

**Project structure**
Agile relies on working forward in defined ‘sprints’ that move you closer towards your goal. We discussed the resonance that this has with action research or experiment based policy making and the fact that this would involve accepting a greater degree of uncertainty in the project process that a waterfall approach would (falsely) bring:

  • Base your project plan on iterations and experimentation – create iterations that involve testing parts of your core proposition and build in a formal review cycle to capture learning and actively use this to inform the definition of the next iteration
  • Focus on the impact and objective – ensure that you have a clear set of project metrics that will allow you to describe each of these iterations in terms of your overall objective
  • Positive byproducts – look for and design in positive byproducts – in terms of code or learning – that can mitigate the perceived risk from the agile approach

**Communication and Reporting**
A big part of the communication process was seen as both building internal and external confidence at the same time as helping with the ‘cultural integration’ from the first section. One of the ideas that Stefan suggested was getting non-coding participants to actually sit in on a scrum meeting to see how the process works. At Public-i we have a daily scrum for the whole company that works on this principle – though I think the frequency may dilute the impact a bit its really useful. More specifically we talked about:

  • Stronger informal feedback loops – if your process is iterative you want to be communicating more regularly so that the end of iteration review is not a horrible shock to people. You need to use this regular feedback to strengthen shared use of language and understanding and just embed the habit of conversation between different parts of the project team.
  • Making your reporting agile – critical path and milestones are both still important but they need to reflect the project iterations and milestones, the idea of minimum viable release and also be mutable in the future – we don’t write the whole plan in detail at the start – instead we fix on the next critical decision or delivery and sketch it out beyond there. This is very disconcerting for someone used to PRINCE2 but much more honest with respect to how project actually work….
  • Use new forms of feedback – we discussed how to include different feedback mechanisms – for example video or blogs – in order create a more consistent way of communicating

This is a bit barebones I’m afraid but I will follow this up as I am working with our project manager to design a project management template based on these principles which we will share when its done. In the meantime please shout if I have forgotten anything!

Thanks to all who participated.

This is by way of a short Action Research reflection so if you are not interested in that kind of thing then move along! Next post will be the write-up of the Agile session at #UKGC12 and much more practical I promise.

I have been mulling on the tension between co-production and Action Research and the need to separate one’s desire to keep the experiment intact at the same time as being open to other people’s views both with respect to the process but also the content within the process.

Action Research is about designing an experiment or project with sound reasoning as to why you think this is the best way to develop knowledge and improve practice – and then seeing if it does. In the case of ‘We Live Here’ for example we have designed an experiment which maps online and offline networks and then gathered them into a single online space which will be discussed with those networks in an open public meeting. The hypothesis that we are testing is that better networked communities are better able, and more likely, to participate in local decision making. This experiment was designed we a certain set of assumptions that we should probably state more overtly namely:

  1. Good decision making and effective democracy needs to be underpinned by civic conversation and the opportunity for deliberation and debate outside of the decision making process. The absence of this ‘public sphere’ is one of the things that has weakened democratic engagement over time
  2. That one of the reasons that people don’t participate in decision making – or deliberation — is that the process is unwieldy and inappropriate for their needs and needs redesigning to be relevant for modern life.
  3. That there are people that have other, deeper reasons for not participating but that we are not looking to deal with more complex issues of access within this project – our focus is creating an environment which is self maintaining and active that we can then help further people participate in over time.
  4. That the project needs to be digital by default but not solely digital.
  5. That networks – and networks of networks – will need different types of support and we can’t make assumptions about what this support might be.

However we also want to work co-productively both within the project team and also with the participants and we are actively looking for positive by-products – for example increased resilience or service access – within the areas that we are running pilots. One of the effects of this is that we have stakeholders (dreadful word) within the project who are not primarily motivated by the initial experiment design and who were not involved in creating it.

For the research to be useful we need to keep the experiment as intact as possible within each iteration at the same time as being open to challenge both on the nature of the underlying principles and also the design of the experiment itself. We also need to keep careful separation from the design of the process from the content and connections that are created within the bounds of the experiment.

This creates a tension – we are trying to keep the experiment intact at the same time as telling people we want to create the outcome with them.

I have been thinking about how to do this – and also how to separate my own twin desires to both defend the underlying context and assumptions (which is a bit defensive of me) at the same time as defending the need to keep the experiment intact (which is the inner researcher speaking).

The Agile project management approach that we are taking is one way of doing this and communicating these three elements to the project team:

1) Context
2) Experiment
3) Content

So I think this means I need to think about more formal project reporting and to start to structure feedback on it so that we can clearly seeing the different questions that we need to consider. I also need to consider how we are going to communicate the action research approach to a wider and not at all research focused audience – or indeed if this is a good idea.

I’ll be speaking to the rest of the project team on this and might be back with an update.

I’ve been mentally hibernating for the last couple of weeks after some rather robust feedback from my supervisor on the latest draft of my thesis which means that I have some large rewrites to do – this post is an action research note reflecting on some of these rewrites. As I have been thinking about the implications of this work, as often happens, a couple of the things I have been doing this week have come together to help me answer the question. The first of these was taking part on “a curated conversation” organised by Fred Garnett and held at BIS – talking about social innovation and the network society. The second was a research workshop with a group of Inspectors and others at Susssex Police which was intended to help shape the next phase of the virtual policing work which I will write up properly next week (I hope).

With both of these my interest was focused on how you manage the points of tension and connection between new networked and agile behvaiours and traditional hierarchial and more process driven organisations. Within the thesis I have been perhaps too focused on showing that there is no real point of connection between new digital civic spaces and the representative democratic function. My belief in this lack of connection has made me rather didactic on the subject and has stopped me looking at where there is the potential for the blurring and shifting of these boundaries and has also meant that I have not really engaged with the wider debate about some of these issues (am fairly sure my supervisor thinks I write like a rampant egomanic). So humble pie digested and redraft underway but I wanted to capture some of these connections and tensions here as a response to the weeks activity – and yes it is still a bit of a polemic but I promise its cleaned up before it goes in the thesis…..

I have an underlying belief, and often unstated, belief that there is need to look at how we transition large organisations within the public sector towards a more networked state and that this transition does need happen in the form of positive distuption within these organisations as much as in the form of of external pressure to change. This involve compromise and an evolution towards a goal rather than a ‘big bang’ solution.

One of the reasons why I argue for greater use of both Agile and Experimental methods (as discussed by Gerry Stoker) to explore new policies and process as well as to build technology is that these allow us to describe our destination without having to also define the whole journey plan. The Virtual Policing work is a good example of this – we know that we want to see social media embedded in a useful operational role within neighbourhood policing teams but we are open with respect to exactly what ‘useful’ means in this context and it is one of the objectives of the next phase of the project to try and describe this usefulness with respect to the current processes within the teams. These will almost certainly need to evolve these processes to accomodate the effects of wider engagement using the social web but its clearly impossible to consider greater operational use of social media in operational policing without referencing the processes and outcomes that form the core of neighbourhood policing today. We will use disruptive change where necessary but experiment based policy making is also a valid way of moving forward.

The work with the Police, but also the curated conversation at BIS, is partly about trying to address the difficulty of reconciling the idea of hierarchy with the network society. Networks don’t have hierarchies (though they do have power) and the behaviors that are rewarded are different from the behaviours which we currently associate with authority. Leaders in hierarchial organisations are going to hang on to those sources of power and if we want to make systemic change then we perhaps need to start exploring with senior staff how they become more networked themselves in order to help them encourage that behaviour in their own organisations.

Emphasising the role of mavericks and disruptors is useful but only if they can set up a creative rather than distructive tension with the current power structures – because lets face it as this point no government organisations is in a state which means it will be overwhelmed by a networked change – the State is still too rooted in hierarchy and we are not yet in a place of such disatisfaction as a society that we have the will to overwhelm it. However I am consistently and increasingly coming across individuals within the Public Sector who are discovering the power that is latent within their networks and deciding to exploit this rather than relying on the usual decision making process – but we don’t yet know how to make this systemic as opposed to exceptional behaviour.

Part of this discussion is practical – we just don’t understand how we can deliberately create large projects in a networked way – how we both create a singular vision and also deliver this vision in a networked when we know that this vision has been created outside of the network. This links very much to the thoughts on networked leadership and the need for a persistent conversatation around vision that I posted here.

I am a pragmatist and looking at changing the process by which we manage these projects – with adopting agile or experimental approaches – is one way in which we can start to address this need to create and manage more networked projects and learn about creating projects which can flourish within a network without losing their coherence.

We also need to appreciate that there is the difference between the social web and the network society and start to discuss behaviours and not technologies. I am all for trying out Yammer but lets start to examine the friction it creates with traditional structures within a large organisation and start to learn from this.

Much of the difficulty of creating a public service that is fit for purpose in the network society is actually deep rooted in some of the underlying design assumptions that live within public service. Perhaps the most important one of these to address is, in my view, the need to create a default position of ‘open’ within all organisations at the same time as creating an appetitie for evidence based decision making that demands a higher standard of information and scrutiny than is currently the case. How many of us have worked on pilots which become policy just because we need to bank a ‘success’ rather than learn from evidence?

Greater openness and ‘publicness’ is a natural state for the network society which is as Castell’s describes it a ‘space of flows’ where information is the currency that creates and binds networks. Boyd’s depiction of ‘networked publics’ describes an arena of open public discourse. We can expect nothing less I believe from our public services in a networked world than a default state of openness.

However, there is one other area where the need to consider openness and publicity and one other important design assumption for public service. We design our public services to be open and accountable to the democratic process – whether we achieve this is entirely another story but this is the aspiration. This is a different kind of openness.

With respect to the architecture and infrastructure on which the network society is manifest we are currently building our online world on a largely unregulated and propriatory infrastructure – if code is law as Lessig suggests then our current law makers are the mamagement of companies such as Facebook and Google.

If the social web is the manifestation and delivery mechanism for the network society then the fact we are building it on closed systems at the mercy of what is surely a flawed financial system is a disgrace which will continue to stunt the potential of a systemic change away from a failing post-industrial environment.

There is a conflict here with the nature of public service which deserves to be highlighted and discussed and not just swept away with our understandable frustration with the public sectors glacial movement with respect to technological change – this is about principle not just code.

There are good as well as bad reasons as to why there is institutional resistence to using something like Facebook even if this is not well or even accurately articulated and if we are trying to help the State wrestle with this then we have to acknowledge and not rubbish the valid concern.

Social change doesn’t happens instantly – we really do need to address tranisiton as well as dreaming about the future.

I was one of 5 facilitators at the Solace Summit a couple of weeks ago and I have been mulling the experience ever since. The event was unusual in that rather having what has always been a perfectly good but rather traditional conference the Solace team (with some I have to confess provocation from myself and others) decided to try to create a more open process which enabled participating to co-produce a communinique around key issues for Solace to address over the coming months. You can read the output here. My first reflection is one of relief – last year it made me positively twitchy to see a group talented and influential people sit passively in a room instead of actually actively participating. Its so rare that you can convene this kind of group it always struck me as a horrible waste to then keep them quiet for most of the event. Happily the audience were hugely positive about the change in format and I think that we will see more of these kinds of events from Solace. Ultimately this is really good news for those of us who attend event such as LocalGovCamp and the like and who want to see better senior support for this kind of open space event – next time just ask them if they went to Solace this year.

I was responsible for the Economic Growth conversation – which was fascinating as its not my core field and made me learn and think about loads of interesting things which I won’t bore you with here. The question that has stuck with me for the last couple of weeks is what do we mean by a networked leader?

As is usually the case when you start talking with senior managers we all concluded that we needed leadership and not management if we were to see Local Government play a significant role in local economic growth. However the group was also convinced that the leadership for local government in this context was as a convenor and a facilitator and not as the person necessarily delivering the outcomes.

I have been thinking about networked leadership ever since and this post is a first attempt to start to put thoughts in order – next up will be doing some more reading around the subject and so any recommendations would be very welcome. I start from the position that leadership in a networked organisation is going to need very different qualities to those of a hierarchal leader – and that we need to explore these qualities if we want to create more networked organisations.

The first quality I think is the ability to create a vision and narrative of that vision which at the time as being focused enough to give direction is open enough to enable others to contribute to it. The organisational vision needs to be an ongoing – and public – conversation.

However to be credible in setting this vision it is essential that you have knowledge of your own place in the network and the value that you bring – and that this evident to the rest of the network. You cannot, in my view, be a leader in a networked organisation just by dint of job title – you need a strong place to stand and an arena in which you contribute to the overall information and activity exchange of the network. The social web is at heart a meritocracy and I believe that the network society has as similar emphasis on personal contribution and exchange.

At the same time as having a clear view of their own contribution the networked leader also needs to be an effective talent spotter – they need to be able to quickly find and amplify activities which contribute to the vision.

In doing this there is a need to be transparent with respect to decisions and to be able to explain these as being coherent with respect to vision and values.

In terms of activity – a lot of time will be spent giving feedback and amplifying activity from within the network – acting a curator as much as content creator.

But the single aspect that is at the same time a byproduct of the above and perhaps the most immediately realisable aspect of the networked leader within local government is the power that hierarchical based leaders have to convene people and conversations. This was the anchor point for the SOLACE conversation with general agreement that though local government is not necessarily going to lead local economic growth it can and should convene the networks which will make this possible and take a leading role in the curation of the conversation around the local economic narrative.

These are certainly qualities that I aspire to as I try to lead my own organisation – though I am also certain that I don’t consistently achieve them. The bigger question may be however whether or not this style of leadership is possibly in organisations made up of thousands of people in multiple overlapping networks and this is a question not just for organisations but perhaps for political parties – its certainly a question that the Occupy folks are concerning themselves with. I am sure that there is a lot of thinking already out there on this and I will start hunting for it.

Hierarchy is not always bad – I have been thinking about this with respect to the Virtual Policing project we’ve been working on with Sussex Police and frankly I am rather relieved that the Police have a command structure as in some situations you do need clear lines of control. However the question for me is whether you can retain the useful aspects of command and control hierarchy without comprising on the benefits and behaviours of the network society. That is definitely something I want to explore.

PS Please note that this has been filed in the ‘things I want to write about post PHD’ category – we’ll see how far I get in the meantime!!

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

I sometimes use the description of the internet as being very like a teenager, messy, difficult, and creative and with a tremendous energy and excitement that is not always focused constructively.  The shifting cultural norms online feel as if they are driven by that generation and it’s not surprising – anyone born after 1993 has only know a networked world.  The issue for all of us is how we integrate these new behaviours into our organisations and how do we influence them towards more traditional ways of doing things – how do we respond the cultural challenges of a networked society?

You can’t find an answer before you have a really good question and I think we need to ask ourselves what are the unique pressures that we are seeing right now that mean we need to respond with culture and behaviour change rather than process re-engineering and re-structuring?  Personally I think there are three main effects we need to consider:

  • Real time information
  • Transparency
  • Collaboration

Not surprisingly I see all of these as a product of a more networked society and I see the answer as bringing greater agility into our work practices.  ‘Agile’ is a software development approach that has core principles which can be applied to other business processes, it reflects the speed and pragmatism of the web without forgetting the need for control and quality management.

Responding to a changing world

Real time information is something that we increasingly take for granted – I use twitter for this but mainstream news is also moving to real time reporting with eye witness accounts and user generated content.  The question for me is how your organisation becomes part of this information flow without compromising on process and accuracy – fast shouldn’t mean sloppy.  The example that springs to mind was from some officers who are taking part in our Virtual Policing study who had to stand next to journalists who were tweeting inaccurate information because those officers had not had the story officially confirmed to them.  Clearly you can’t have officers making up the official line on a story on the spot – but they do need some real time responses they can use and they do need a closer to real time response from the communications team than having to wait for the Press release.  I am sure that this is a process issue that is echoed in many other organisations – the question is how do you make it more agile?

Our process thinking has been massively influenced by Just In Time production management approaches – we have industrialised production of content and services in the same way as manufacturing modularised and productised its processes of production.

I am suggesting that this is no longer the most efficient way of working and that in a networked and conversational world its no longer the most efficient response to write one really thorough response that may take a while to prepare – you need to communicate a little and often and make it clear what you do and don’t know.

Transparency leads a necessity to be much more clear about knowledge bounds – you can’t claim expertise and authority without being able to back these claims up as people expect to be able to be able to ‘click here to find out more’.  We write ourselves into being online and we do this by transparently showing our views, ideas and feelings.  The consequence of this is that we are pushed towards thinking institutionally in public – which means that we won’t always have the final answer.

Transparency sits very closely with collaboration.  With reducing budgets there is a clear need to consider how to collaborate with partners and with the public more effectively.  You can’t collaborate effectively without trust and transparency is one way of fast tracking establishing that trust – not to mention making working together more effective as you can clearly see what the other people are up to.

I was speaking at conference recently and was asked ‘who is losing power if the people are gaining it?’ – The answer is the state.  More co-productive ways of working mean that the people at the top of a top down structure are losing power and this needs to be faced.  I think this shift is best articulated as the fact that more transparent and collaborative ways of working mean that ‘the people’ collectively gave a greater sense of their own power – you get the confidence to act because you know that other people feel the same way.  The point is that this can be true internally as much as externally – don’t we want our staff to have a sense of what they can achieve and the ability to get on and do it?

This is what brings me back to thinking about culture and behaviour change.  These pressures are opportunities to effect change internally as we respond to externally circumstances – indeed if we don’t transform ourselves then we reduce our ability to deal effectively with that external world.  If the world is changing then we need to change as well.

Organisationally I think agility really comes down to two things – having a shared set of values and a clearly understood vision of what you are trying to achieve – a well-articulated objective.  Is anyone else flashing back to about a dozen leadership books and motivational speakers?

An agile process is slightly more than that – it releases on that vision and values but it then responds to the changing environment.  Agile processes work in short iterative cycles that allow you to act immediately in a controlled way – going back to that Police example the press office could be asked to tweet a holding message – and then short updates that make it clear what is and isn’t know at that point.  The immediate objective here is to reassure the public and to make it clear you have the situation in hand – not actually to pass information so this doesn’t need a lot of thought or a full press release.  Communicate a little and often with a clear view on who is able to do this in real time in a crisis situation.

How do you influence behaviour? 

I am coming from a point of view that says that the developing network society is one of the main pressures here and so my suggestion is the adoption of the tools of the network society is a useful first step to do this.  Use yammer internally, blog your management minutes rather than sticking them in a word document and use tools like basecamp to create collaborative workspaces.  Technology does not change people – but it can change behaviours and it can expose the attitudes and assumptions of the people who are creating it.  The network society is a more conversational, collaborative, transparent and real-time space – use its tools to explore what that means.  It’s also not a change that can happen without some kind of experiential element – you need to find the usefulness within these tools so that they become relevant – otherwise you’ll be asking your staff to join the LOL cat movement.

Build relationships

Its also worth thinking about how you build networks within your organisation – you already have people who are using these tools to talk about their hobbies, manage their photos or keep in touch with family and you want them to transfer these skills internally.  More than that you want to open up the possibilities and creativity that a more networked way of working can facilitate.  This is going to need a different kind of mentoring and support than more traditional structures – you want to break down barriers of hierarchy and also of organisation. Run internal social media surgeries, encourage staff to attend unconferences and city camps in order to connect to the people who are already working in new ways and let these networks grow organically – you can start to think about structure and order when there is actually something there to organise – in the first place you need to find and support the people who can already work in new ways as it can be a lonely business trying to bring about cultural change on your own.

Ultimately its all about making better decisions.

I believe is that you aim here is to be able to pass the decision the place closest to the issue so that you have faster and more effective organisational reactions.  However to do that you need to also get the information and the strategic there so that those decisions are backed up by the right organisational knowledge.  You also need to make sure that staff have an understanding of your organisation that goes beyond being able to recite the strategy – they need to understand your values and your purpose as well.  You need to wrestle brand off the design people and give it some heart.

But we’re not out of control yet

This does not have to mean a loss of control by the organisation it just means that the control moves – an agile process is not undisciplined.  Testing and evaluation is an inherent part of the mind set and you are trying to create new processes that are fast but measured in the way that they work.  In software terms you use unit testing to check each element is working – in policy terms you need to check each deliverable against the actual objective – does it move you forward?  If you bring this unit testing idea to policy making and implementation that you have to push the understanding of the objective out to the whole delivery team so that they can effectively make this judgement as they encounter variations and impacts from the environment.

Where do we go from here?

If you have got this far and appreciate the sense of urgency then you need to think about some tangible actions – you can’t change your organisation without changing your own behaviour

  • Get started – use the tools of the network society, communicate the objective as well as the plan and work both transparently and collaboratively so that it’s easier to learn from your experiences.  The social web tolerates and expects experimentation and you can’t learn from this environment unless you use it – get in the game.  If you are already online then think about how you mainstream your involvement – don’t let it be a side line that you fit in around your day job.
  • Accept complexity and plan for it – Agile assumes that we are not working in a closed system and that the environment effects our outcomes.  We know this is true so it makes sense to have an approach that accommodates changes and complexity rather than futile attempts to manage it out of existence.
  • Establish your relevance and communicate it – in a transparent world you need to understand where you fit and make sure everyone else does as well.  If you are pushing decision making out to the edges of your organisation then you need to give them the framework to work within

We are coming up fast to the point where the majority of people will be online and engaged digitally.  There will always be pockets of people that will be hard to reach but the people working within your organisations will be living networked and digital lives.  It becomes impossible to keep this fact out of your organisational culture – the question is how you change to get the best out of the new skills and opportunities without losing the essence of who you are.


This is a write up of a session that I was part of at UKGovCamp11 – I’ve written it as a separate post as I want to take these ideas forward in some way and need to think about how to do this. A few of us have been speaking about the use of Agile in the Public Sector – most notably Public Strategist and Michelle Ide Smith (who live blogged the session here) so we knew we wanted to have two sessions on this – one to focus on the use of Agile for its originally purpose – software development – and the other to explore the aspects of Agile that might be relevant in a reworked Policy process.

Michelle did an excellent job facilitating the first session and if you are interested in this area you should take a look at her slides (I can’t dig out the link to them so will add them next week). We use Agile over at Public-i and as you can read from Ady’s blog this is really a work in progress for us – we are constantly deepening our use and understanding of the process but we have found it invaluable not only as a way of coding more effectively but also as a way of making sure that the development team are focusing on the things that the business needs most acutely. We have loads of improvements still to make but I am very much convinced that this is the right path.

Why Agile?

We tend to treat Policy as a constant – the point of this post is that it shouldn’t be. The objective of the policy is the constant – the policy itself needs to vary in face of changing context and the delivery plan needs to vary even more and we can deliver better outcomes more effectively if we allow this to happen.

I have written before about the need to move from Waterfall to Agile thinking for Policy delivery and Stefan has also written about this here. As a precurser to the wider reading I want to do to support some of this thinking its really worth having a look at this 1985 paper by Fred Brooks where he really introduces the flaws in waterfall thinking: No Silver Bullet — Essence and Accidents of Software Engineering. I also want to catch up with Fred Garnett who mentioned he has already written some related ideas up and had come from a parallel session on agile for learning – so there is definitely something in the air. Next step will be to see if I can get some proper sit down time with Public Strategist to see where we think this could go. If you have any interest or thoughts then please let me know.

In explaining how Agile approaches could help change the way we create and implement policy its worth reflecting on the why the software industry made the shift to agile type methodologies. Its really about three things:

  • An increased awareness of complexity and the lack of a definitive answer – – and we need to build for complexity. This means we need incremental progress towards an objective rather than thinking we can capture everything at once
  • An awareness of the impossibility of developing anything in isolation – we exist in open not closed systems and no idea exists in isolation – which means we need a process that is not a black box
  • A shift from engineering to systems thinking

And of course the fact that everyone hates writing specifications – not the least because you never get them right. There are other more code related motivations that are the results of developers working further and further away from the machine layer but lets not get into that now.

The important thing for me in exploring the connection between agile for code and agile for policy is the fact that policy delivery is failing for much the same reasons. As the purview of the state has increased it is impossible to implement policy without affecting other areas and there is a realisation that we have to start thinking about people’s lives and communities rather than trying to modularise our existence into tidy manageable chunks.

The aim of the session was to try and explore what elements of an Agile software approach could be applied to the policy process and to this end I sketched this to work from:

Agile Policy Sketch

The sketch seemed to stand up to debate which was good and there was some useful debate. Here’s my take on it:

  • Keep the bigger objective in mind – the plan is not the goal: This is vital as far as I am concerned – in that old army adage no plan survives contact with the enemy and any good project manager is highly resilient and adaptive. You need to focus on the objective and adapt as necessary to achieve it. This means that politicians need to set the goal and trust highly agile teams to get on and deliver it. The plan in not the goal.
  • New attitudes to risk – break it down and make it manageable: Lots of nodding on this – we consensus was that its better to fail fast and fail early and as Dennis North said – fail cheaply. There are no end of examples where this advice should have been heeded. However we have a political and media culture where failure is not tolerated – which is an impossible position which leads us to either hide or spin all outcomes into something positive and then further fuel the idea that everything succeeds. Tolerating failure is not weakness and we need to find a way to have a more mature debate about this – not only to support wider innovation but more importantly to stop failure on any large project.
  • Small incremental improvements rather the big bang: Big switch on implementations are like launching the Titanic and they are a hangover from an engineering mindset which is supported by a media who pander to an attention deficit public (I know that sentence sounds cross – turns out I am cross about this). We can and should be able to see what happens when things are released in manageable stages which we can learn from as we go along. We do not need to crack a bottle of champagne and create a mythical onswitch for a new policy – we need to show constant incremental improvements with no big failures.
  • Test as you go along – build evidence rather than theories: Harry Harold quizzed us on the value of testing in the policy process and questioned if the fact that many things just can’t be tested meant that the agile metaphor breaks down here – which was a good point to explore. My view – which seemed to be accepted was that testing is as much about reducing risk as about meeting acceptance criteria. Testing of policy has less effect on risk than testing code as there are fewer things that can be tested but instead I suggest that you take an action research approach and layer and build evidence as the work proceeds. How you do this will depend on the area in which you are working but the idea is to move from the anecdotal and theoretical point at which so many programmes start towards an increasingly robust evidence base.
  • Adjust in the face of new evidence: This idea of making evidence gathering part of the ongoing process also supports one of the other principles – that you need to adjust your plan in the face of new evidence. Good ideas can turn out to be the wrong solution and serendipity can happen.
  • Everyone is responsible for making it work: As I said at the start – one of the things I appreciate about agile in our business is the fact that it can help communicate strategy to the development team. Agile is essentially a very flat and very teamed based approach which values everyones skills – and as a results increases accountablity.
  • Use the users: Agile constantly refers back to the user stories and to the client. We need to keep real people at the heart of the policy process rather than design for a Westminster or even Town Hall bubble.
  • Communicate All The Time. Agile relies on a team being kept up to date on progress in all areas every day – because things change everyday. And make sure you communicate failure as a saving.

Some observations

I am not suggesting that we have a scrum master in Downing Street – or that we Kanban road mending in councils (though that might work ?!). I am talking about adapting principles at the moment but process and tools could follow and they probably won’t look like the tools that developers use – as Loulouk pointed out you can’t just knock walls and create whiteboard space in Council buildings – you need to adapt to the environment. You also need to accept that this would by no means the only shift that you need to make – we briefly discussed the need to work more co-productively in order to be able to really ‘use the users’.

There is no point in downplaying how difficult it will be to wean government off big programme thinking – much of the state machine is architected to put large programmes together than then deliver them – its how the funding and structures work at a very detailed level. There is also the need to bundle things up into tidy packages for the press and to link statement A with funding B and result C in a way that does not allow for tactics to change when you learn more. There is a need to allow for the idea that the plan will change and that this isn’t of itself a failure – its a reasonable adjustment to changing context. To allow this we need to allow politicians to be able to be seen to change their minds rather than having a knee jerk accusation of ‘u-turn’ leveled at them.

We probably need to remove artificial uses of time as a constraint – its almost impossible if you are talking social change and instead start to measure progress against our wider objective.

All this looks for a more mature politics than we currently have and a lot more trust and cooperation between politicians than I often observe. However if we are going to work more co-productively because we can’t afford to do anything else then these relationships will of necessity change.

However the fact is that the pressure to change is being created by the social change brought about by the deep embedding of technology in our day to day lives – by the network society. If nothing else the transparency that the social web embodies and that government says it wants to deliver with #opendata means that we will no longer be able to hide our policy programmes in big black boxes that we only open up on launch day. We will be scrutinising not just results but also processes and progress – which means these processes need to be robust and defensible. Armchair auditors will not stop at the results – they will track failure and problems back to the delivery process if they are any good and that puts the way in which we make policy as much in the frame as the outcomes of those policies. This means we need processes which will stand up for a network society.

I will be musing more on this and bothering other people to discuss it. If you came to the session would also be keen to hear whether or not you are happy with this overview. Thank you.


Next Page »

Follow

Get every new post delivered to your Inbox.