ETYMOLOGY: 16c: from Latin agilis, from agere to do.
When you think of a public sector organisation, is the word agile up there? Responsive? Dynamic? Able to react immediately to changes in external forces/factors/politics/leadership?
Or, do you think of a cruise liner akin to the Titanic, with a Captain at the helm, reading from maps with nautical tools, who, on seeing the icebergs in the distance can do nothing but try and avert disaster, hauling frantically on the wheel, deep down knowing that the iceberg is going to hit, but desperately trying anyway?
3 months ago, I think, I saw a conversation on my stream between @rikbarker and someone else. A female programmer as it happens, now a PM, but I'll not embarrass her. She is not above the parapet and wouldn't appreciate being hauled there. Anyway, they were discussing the agile software development approach. I've no idea why it pinged, only that it did and I followed the conversation with interest. By the end of it, I tweeted something along the lines of 'I wonder if we could implement agile dev strat in local gov'. And there it ended. And idle musing commenced.
Fast forward a month and it came up in a discussion with someone else, but in my organisation. There was interest, but my thoughts on the subject were nowhere near cohesive enough to pitch it to someone who could, and I think would, run with it.
Fast forward again, to Tuesday. A social visit to a friend, @rikbarker, turned into a long conversation about agile approaches, local government, social media, doing more with less and about the most amazing business approach I've heard since seeing Futuregov in action - Technophobia. I seriously can't enthuse enough, I sat and listened to a friend tell me all the things I wanted to happen when we do web and digital were possible, could be possible, that magic could happen, that sanity could be retained, that money could be spent wisely. I'm not easily swayed. Man talked about the best kind of sense. But agile came up again. And again. Totally pure application in this case, in a developing environment, but again I thought 'why don't we do this?'
So today I asked on Twitter again, how do we do this, and the floodgates opened. People involved in the rolling discussion to this point: many - people utterly confused about where I am coming from and what relevance a programming approach has to public sector: many. Except one person, @pubstrat, who I think is in exactly the same place I am at the moment, but it is nice to know I am not chasing rainbows, nevertheless.
You see, it's nothing to do with IT. Nothing. At all. Wipe those two letters entirely from your mind. Instead, think of agility and what it means. As public sector employees, we are told we should be pro-active because that is where best value lies. I want to argue with that, if only because I don't believe you can be pro-active in an environment where your stakeholders are entirely out of your control. And lets be brutally honest about this, in the public sector, they are. Leaders are politicians, Councillors are politically aligned, our citizens too, the ones who care and actually show up to meetings. Central government control our spends and those are being cut but those cuts could also be reversed in a moment, should something unlikely but possible happen. So we are beholden to central party politics, local party politics, and local mood. These things can spin on a penny, elections being the most obvious flare point.
These are not in our control. So instead of planning around the way things are expected to be, how about we acknowlege a lack of control and plan for it? Yes, plan projects. Create project queues. Have processes for incoming job requests. But set a priority and revisit it. Frequently. In the process of gathering requirements, an often long and arduous task, review every few weeks with a quick phone call to the source of the requirements and check that things are still the same. If they are, all well and good, 3 minutes on the phone. If they're not, react and reassign, and then realign the project. If you don't check, what then? It might mean you procure an item based on a false set of requirements which are no longer valid.
This is agility. Quick moving responses to every changing influences. It's not a strategy. It's not a tick list. It's a culture and an ethos. Accept that technology is moving faster than we can keep up with and check in with people that what they wanted a month ago is still what they want. It doesn't have to involve scrum meetings or frequent breakouts. It does if you're in IT but that's not an issue I am addressing here, it's been addressed far better than I ever could over there. Instead, I'm simply musing on a concept which says:
- discuss requirements
- agree objectives
- prioritise objectives
- agree first challenge
- agree first review point
- implement first challenge
- review appropriateness/effectiveness of solution to first challenge
- adjust everything else around whether first solution met initial requirements
- discuss if initial requirements have changed
- if changed, respond appropriately, acknowledging you've only wasted 2 days, 2 weeks, 2 months and not 2 years
- agree next challenge
- implement next challenge
- rinse and repeat
As an addendum to this, our whiteboard has our work queues on it in our team. My bit is tagged with progress post it notes. I didn't think about what I was doing when I did it, only that I did it. And I did it because I wanted to change states in an instant, if I needed to. I did it because they're progress bars. And I did it because priorities, for me, in a job description which spans insane amounts of information and stakeholders, be able to respond in an instant. Small beginnings. I don't know if they can replicated upwards, but I do know this blog is for dreaming in and this is my dream.