Educating and selling Agile in government

Vicky Teinaki -

Last Saturday, I attended the Localgovcamp unconference in Birmingham.

Unconferences are about the participants providing the sessions. Because of this, at the start of the day people line up to ‘pitch’ their idea for a session. The more applause there is for the idea, the bigger the room the session is scheduled in.

About halfway through the pitch session, one of the few women to pitch an idea then implored more women to contribute. Duly motivated (and a bit chastened), I got up with one I’ve been considering for some time – agile and government.

It got a fair bit of applause – and a lot of people showed up!

In the time between then and now there’s already been a great write up of the session (props to whoever came up with the title ‘Agile is not a noun, it’s actually scheduled maintenance’). I highly recommend reading it as it covers some points that I only brush over in more detail. There are also notes in the collaborative document from the day … that I would have added to if I’d known it was there….

Agile is not a noun

The session kicked off with a discussion about whether people even knew what agile was. There was a concern of agile being misrepresented: “agility is not a noun – it’s an adjective”.

There’s also a lot of fear from teams about agile being forced on to them: ‘I’ve had people say “we’ve been agiled”’.

One of the key suggestions was to get away from the word ‘agile’ if it caused problems. This could mean talking about ‘iterative delivery’, changing the story from being about projects to services, or looking for small but key changes that can get buy in. And if you can’t even do agile – “if it happens via waterfall, that’s OK, as long as you move the dial”. One participant quoted Dan North‘s definition of the role of software delivery as “sustainably reducing lead time to maximise impact”.

The best story of the session came from a local council. They first did small but flashy changes to get people engaged, and then added other features not as agile but ‘scheduled maintenance’! Another Trojan horse-like story entailed hiding the agile work in boring looking gannt charts…

Managing engagement

There was a discussion about managing stakeholders. One person commented that we should eat our own dog food, and remember that we must look after all our users … who include stakeholders.

Above all, kick offs and check ins came out as a recurring strategy. Do a kick off at the start where everyone important is brought together in one location, and then repeat this every six months. And remember to facilitate rather than lead – let them figure out the key areas and continue from that. (Even if you prepare what you think the key areas are to help feed the discussion!)

There was a heated discussion about having to go present at board meetings. At the suggestion that it was a waste of time, one participant countered that it’s about ‘being good citizens in the cultural hierarchy’ and that it’s easier for us to go to boards than for them to come to us. He suggested that these are opportunities to share knowledge and above all constantly provide reassurance. What’s more, there are other ways to do this, such as creating monthly blog posts that are used at the meetings.

Other suggestions were doing group reports rather than delegating it to one person, using show and tells, and more generally having information radiators such as drawings, diagrams, and things on the walls. (Going back to understanding agile, Pauline Rosche cited the power of diagrams with a nice example of how to explain Agile.)

I also liked a tip given to get a board to think about future needs rather than just reviewing the backlog. He created a three question survey he sent to members beforehand and then reported back on:

  1. Confidence at meeting the current sprint;
  2. What they considered the biggest issue;
  3. How they thought they should deal with it

A final sage tip was to keep watching the metrics, even when no one else is watching. One member mentioned that you’ll always get a call out of the blue asking about the numbers for something.

Don’t fail – but some examples of ‘failures’ would be good too

The group noted that one of the biggest hurdles is framing the idea of success and failure, namely the notion that it’s OK to fail on a small project. Going back to language, it was pointed out that no one wants to fail or be told they don’t know – far better to talk about value and money saved rather and reshape the conversation in different ways.

While ‘celebrating failure’ and ‘failing fast’ sound great in theory but don’t work in reality, more examples of these types of pivots or ‘war stories’ outside of startups could be useful. (Victor Lombardi has a book about failure and design – but that’s just good old failure.) An example was given of a project by Department of Work and Pensions in discovery stage providing sufficient evidence that the digital product wasn’t needed and therefore stopping the project – but I can’t find any documentation of this. EDIT: it turns out this is online – it was the Funeral Payments Service which is documented the DWP blog. Thanks Aaron Jaffrey for pointing me to the link.

While the GDS service manual was suggested as an example of how to do agile, making actual examples more visible would help pave the way for other local and central government organisations to have these discussions.