Agile for Local Government

So before you read the second paragraph, let me make it clear that I've been advocating since the early 2000s for Building our Things according to iterative feedback-loop-driven methodologies since what is now called Agile was called Evolutionary Delivery. And I'm still advocating for that.

The other day, my young child, referring to being about to play one of his current favourite PS4 games, said 'Daddy, I need to spend a bit of time attending to my cult'. My immediate response was to say 'Oh, have you got a Retrospective and a Sprint Planning session to plan?'. The way many of us are doing Agile in Local Government I think not only isn't working to its best potential, but I fear it's also giving the concept of Agile a bad name. There's a high risk that the way we're doing it is going to result in some kind of catastrophic failure in the future, which may result in us as a sector throwing the baby out with the bathwater. I fear some of how we're doing Agile in Local Government, an outside casual observer could be forgiven for thinking we're members of a cult.

Many councils which are trying to do Agile are sort-of following, to greater and lesser degrees, the framework known as SCRUM. In the interest more of brevity than strict accuracy, in a nutshell a SCRUM process involves a team of specialists in their disciplines (service designers, user researchers, developers, product owners, delivery managers, etc) and representation from the client and the client's users coming together as a multidisciplinary team to focus on the task at hand, breaking down the delivery of a product into smaller units to be worked on in short sprints - usually lasting a week, though some organisations pragmatically recognise that two week sprints are more productive than one week sprints.

And there are meetings.

Lots of meetings.

Now again, don't get me wrong - I'm one of the few people in the Universe who believes in the power of a good meeting to Get Stuff Done. Part of the underlying philosophy of the meeting structure in SCRUM is that although the individual members of the team have their own particular fields of expertise, any member of the team can have useful insight to share with the rest of the team to help other members of the team make progress. This is a good thing.

The problem

A typical working week of a member of a multidisciplinary team member involved in an Agile project, as regards the meetings and ceremonies which are a core part of how SCRUM is designed to work might look like this:

(An Anchor Day is when teams composed of distributed workers agree on a day when they'll all physically come together in the same place to facilitate rapid sharing and discussion)

Predicated on an assumption that most if not all of the team are singularly focussed on the project at hand, you can see there's plenty of space in the day outside the production meetings to get on with individual work and activity towards the team's shared goal.

But in Local Government, there are few councils where the members of the team have the luxury of being allocated to just one project at a time:

Ah.

Of course, it would be lovely to be involved in as few as two projects simultaneously…

As you can see, we're not leaving ourselves much time for doing the work, are we?

And that's just the project meetings. I'm probably unusual in my own personal situation as a Single Point of Failure on the platform we use in that I spend about 50% of my time simply handling support queries because there's nobody else to handle them, and I'm probably unusual in that I also spend a lot of time doing development work which in another organisation would probably be handled by one of the junior members of the team, as well as spending a lot of time on activity which is completely outside my notional job role and grade simply because I know the answers to the questions people are asking. But much as I'd like to think I'm special, I can't be that special; in the world of Local Government many - perhaps most - people are working under similar conditions.

Even if we extend our sprint times from one week to two weeks as many teams have done, the more projects the individual team members are involved in, the more meetings - or ceremonies, in the lingo - they're participating in. Even if we say not everybody has to attend every meeting, there are still a lot of meetings, and more to the point, how does any given team member know whether or not their presence will be superfluous to any specific meeting? Putting it bluntly, if a meeting is such that attendance can be considered routinely optional for team members to attend, then serious questions must be asked about whether the meeting is necessary at all.

Towards a solution

Most of my articles about my ideas I write here, I have reasonable confidence that I fully know what I am talking about; I consider myself to be an Authority in my field. I'll freely admit I'm not an expert in Agile Project Management, or indeed any other forms of project management; I'm straying from my lane in appearing to hold forth on this topic. More to the point, nobody's going to design a project management methodology in a single blog post!

I don't think I'm completely out of whack, though; I'm confident enough that having documented a problem many of us have discussed in hushed tones in out of the way corridors, that making a couple of suggestions might prompt further discussion within the wider community to collectively design a new framework. This is hopefully the start of a conversation.

One of the most important things about Agile to remember is, well, the clue's in the name. It's supposed to be, erm, agile - ie, you're supposed to be able to adapt it and whichever particular framework or methodology you're using to make it more fitting to your specific local conditions.

Some of this may look a bit like 'well that's how we used to do things'. This is not necessarily a Bad Thing; whilst the definition of innovation naturally assumes newness, it's possible to suggest that it can be innovative to do something old in an old way but underpinned by new thinking to deliver improved outcomes. After all, if one is standing on a cliff edge, two steps backwards are always better than one step forwards.

Sprints

The first thing - perhaps the easiest thing - we need to do is be realistic about the length of a Sprint cycle. In many cases we've already informally accepted that a week isn't long enough to get any real work done; even in 2000 when I worked in a team for a company which was formed literally to deliver one single website we ended up agreeing that a week for an Evolutionary Delivery cycle wasn't long enough. It's time we formally accepted that, making the shortest Sprint cycle length two weeks.

Coincidentally, during the period of time I've been spending writing this I happened to see a post on the unofficial GDS blog suggesting they're experimenting with moving away from two week sprints to three week sprints, and if I'm interpreting it correctly it looks like part of the experiment involves adding another week to the cycle called Reflection Week - where the Show and Tell activity, Retrospective, and the planning for the next cycle take place in their own time rather than being bundled in as part of the cycle itself.

The Projects and Teams

The second most important thing we need to do is be realistic about the fact that most of the team members are working on more than one thing at once; some team members will be involved with other projects with the same team members, some team members will be fortunate enough to be able to concentrate on delivering just one thing at this point in time. I think in most councils, though, certainly on the project delivery side most of the team members will be sharing their time in many of the current active projects - our teams simply aren't that big.

Resource Planning

The art of Resource Planning should be given higher regard than it seems to currently be given; perhaps because the tools we're using - Trello, Jira, M365 Planner, etc - as online representations of kanban boards, naturally restricted by screen size, unlike a physical kanban board in an office, don't lend themselves to showing much more than the Backlog, In Progress, Out For Testing, and Done columns of task cards. The UI design focuses more on trying to show skeuomorph representations of the cards which are stuck to the boards in a factory than showing as much information on screen as possible. It's possible there are views of the tools which I've not had access to which better represent the activities being done by the individuals.

When I've been in charge of planning the work for a team on projects delivered in iterative cycles, it was before we had modern tools, so my tool of choice was a simple Excel document. The columns across the document were the weeks of the year, the rows listed the deliverables in the order we expected to deliver them, and the blocks were labelled and colour coded according to which member of the team was committed to that activity, thus it was possible to see at a glance who was committed to doing what and when, and thus it was easy to see how realistic it may have been to assign another deliverable to any given team member for any given week.

Sprint planning

In the GDS blog post, one of the rationales given for extending the length of the sprint cycle is in order to create an intention that the end of each cycle should always result in something shippable or showable. I think this is a key point; one of the frustrations I've been experiencing in local government projects which are aspirationally being run along agile lines with one week sprints is going from week to week without actually feeling like anything has been achieved; from meeting to meeting we go where everything is in progress and only occasionally is anything announced as having been completed - something which may or may not actually count as a discrete deliverable anyway. In this context often we're not actually doing Sprints in a meaningful way anyway, we're just carrying on our work in an ordinary linear manner and rather than calling any given week Week x we're calling it Sprint X.

If a sprint doesn't have meaningful deliverables attached to it, it's not a sprint, it's just a period of time.

Therefore sprint planning should be clear about what the expected deliverables at the end of the sprint are expected to be, and the expected deliverables should be something meaningful - something which represents a component of the wider project which could potentially be put into production for the client's users to start using, or a component which could be handed over to the client for testing. Or at the very least, the completion of the gathering of some tangible knowledge as part of Discovery which can help inform the planning for the next sprint.

And because we're accepting we're all working on multiple projects simultaneously, it's fine to plan for some of the deliverables to be worked on over multiple sprints whilst other deliverables being worked on at the same time will only take one sprint. And, indeed, since we're making up a new framework here which is turning on its head the way things have been traditionally done, who says every sprint cycle has to last a fixed length anyway? What's to stop us as part of our planning exercise as we map out the deliverables and predict how long any given piece of work should take in the context of everything else which is going on from saying Sprints 1 and 2 will be one week, Sprints 3 to 6 will be two weeks, Sprint 7 will be three weeks, Sprints 8 and 9 will be two weeks, and Sprints 10 and 11 will be one week?

I feel I oughtn't need to say this, but I'm going to say it 'just in case' anyway - clearly, our planning is not going to be perfect; clearly things will take longer or shorter than they were originally anticipated for any number of reasons. That's fine, we're doing Agile, we're allowed to re-plan to account for the rapidly changing fast moving environment we're working in today; that's the point of having a planning session for every sprint.

Meetings and Ceremonies

On the basis of all this, it seems to me to make sense to structure our meetings and ceremonies not around the individual projects but around the whole delivery team (that is to say, the developers, the designers, the analysts, the researchers, etc), looking at their overall capacity holistically. We shouldn't have a discrete cycle of meetings just to talk about the new pothole reporting system project, and a separate cycle of meetings just to talk about the changes which need to be made to the ULEZ systems; the regular cyclical ceremonial meetings such as the daily standups, the planning sessions, the shows and tell, and the retrospectives should encompass everything that's being worked on by the whole delivery team, with one daily standup per day, and one planning and retro per cycle, with project-specific meetings taking place separately as the demands of the project dictate.

Clearly, the implication of that is that meeting discipline should be much more rigorously adhered to than it should be anyway; daily standups really should only be the go-round of plans for the day and irritations experienced yesterday which may need resolution today. It should not be an arms race where team members compete to declare who's busier than other team members - the chair and managers present should not be expecting an arms race and they should bring out the guillotine when it looks like that's happening. It should also not turn into a problem-solving meeting when somebody expresses an irritation - if another team member can offer insight on how to solve an irritation, they should say so, but they should also then schedule a separate meeting which can be attended by anybody else who thinks they might be able to contribute to the solution, too.

The other meetings beyond the daily standup should also have clear published agendas so that team members can tell in advance if the topic for that meeting is going to be of interest to them and thus whether there's value in their attendance; again, we're doing Agile here so it's fine for a controlled drift of topic to occur in a well chaired meeting, and for it to be realised that it'd be good to bring Susanna in at this point; if the meetings are in people's calendars marked as tentative then if Susanna decided not to attend that meeting and get on with some analysis work in that time instead, nobody else should have bagsied here for another meeting about something else. Susanna will of course be irritated about being interrupted whilst doing that analysis, but not half as irritated as sitting through a meeting thinking she could have been doing something else, or not attending the meeting to be told afterwards that something else came up which could have really helped her at that point.

Early conclusions

This feels like a good moment to stop typing down what is admittedly a bit of a stream of consciousness, to allow for further thinking time and to see what you, my peers in the LocalGovDigital world think about this.

It's possible some of this in practice might end up being contradictory. It's possible some of it might look a bit like trying to do Agile in a Waterfall manner, or trying to do Waterfall in an Agile manner, or something. I'd be - obviously - inclined to disagree with such a characterisation, because fundamentally I'm still advocating for doing our work in a manner which is in keeping with the Agile principles of flexibility, of breaking down the project into smaller components, of accepting uncertainty and change as we move through the project and gain new information, of working according to iterative cycles of delivery and feedback, and of involving the client as closely as possible in the process rather than keeping them in the dark for six months and then giving them something which is no longer relevant for their needs.

It's possible some people might be reading this and go 'aha, that's actually exactly how we work in our council, and it works really well', or alternatively go 'unfortunately that's how we have been working in our council and it's been a disaster so we've gone back to standard Scrum / Waterfall'. Hopefully if you're reading it, you're more of an expert in project management methodologies and tools than I am, and you're interested in helping to develop it further from a simple blog post into a properly worked up new dedicated framework which we can get invited to conferences with nice pastries served at to talk about.

Regardless, I'm keen to hear from you what you think, in order to iterate this thinking further. If I get enough additional comment I'll write up a Part Two of the post, otherwise I'll update this post to account for what other people are telling me.