Wagile and agile-ish
Why flexible and collaborative work ails on our public service foundations
I have previously ranted about the vapidity of operating models, at least in the way that I’ve seen them practiced here over and over again. Today I want to speak to an example that might help illustrate one of the ails in how our public sector works – or better, the way in which work happens here.
Some public servants might roll their eyes at the mere mention of this godforsaken word creation: wagile – a portmanteau of waterfall and agile, both I’ll take as known methodologies to organise work.
Though I have found that the word “agile” has become a four-letter-word to some. People who never worked in agile teams sometimes treat it as an empty buzzword that borders on a passing fad,
The handlebar mustache equivalent of the working environment.
I can somewhat relate, being a constant grump about jargon and abstracted “Business” speak, which agile methodology is truly chock-full of. Thing is though, there's a reason we have jargon in the first place: as specialist language that communicates clearly defined terms between people in the know. And it’s needed in the case of agile, though it forms a moat around its practice.
But I won't lecture on agile here, I want to talk about its smooshed-up cousin “wagile”, or sometimes referred to as “agile-ish”.
I had worked in a few pretty decent agile teams before I came across one that attempted the dreaded crossover to waterfall-style project management, likely out of necessity rather than enthusiastic conviction. First, let me illustrate what I observed of the way that this team had attempted to make this work(-ish) for themselves. I’m not claiming that this is a fair representation of how wagile is done everywhere, but this is what happened there and then:
A digital team in a large public institution established a bunch of Product Managers and Product Owners, each responsible for different technologies needed in the delivery pf a public service. In my experience,
in an agile setting they would each get their own budgets and be responsible for developing the short- and long-term roadmaps for their products and oversee any work on improvements, carried out in scrum teams.
Trouble is, that’s not how financial planning, strategy or governance in public sector works – the only language we speak is “business case”.
Plus, there were no scrum teams in this institution as most of the actual development was carried out by suppliers (sound familiar?). The digital team was more of a strategy- and oversight-shop, generously speaking.
Instead, there were teams of specialists, project managers, BA’s, Service Designers (like yours truly) and a few technical SME’s.
So in effect, the Product Managers- and Owners only way to carry out work was through developing a multitude of business cases, which – if approved by the Senior Manager and a host of other stakeholders – would be handed to classic Prince2 Project Managers, who then assembled the typical project teams and worked in an A-B waterfall fashion. Wagile!
Not only does this approach lose the dynamic continuous development and built-in involvement of specialists and users that agile normally has,
it necessitates an additional layer of coordination that comes at a massive cost to both the agile- and the waterfall-side.
We endlessly watched the Product Managers, Owners and Project Managers stumbling over each other, having off-sites to come up with strategies and agreements, return more confused than before, and ultimately falling prey to jealousy and backhanded deals that ruined the last specks of trust between them.
This may very well fall into the category of “too many managers” – as some voices have been alluding to in the last few weeks.
I don’t think there are “too many” people at work in the public sector per se, but there may very well be too many people forced to spend their time coordinating, re-negotiating and fixing issues that arise because the cogs of their organisation don’t interlink the way they’re supposed to.
THAT was wagile to me. It seemed like the worst of both worlds, agile owners with one arm tied behind their back, and project managers who constantly had their workflow bowled over. I expect there are pockets out there where some people have managed to strike some kind of balance, but I’d wager that still comes at a decent cost.
So why would that happen?
I don't think it's necessarily the idea of agile and waterfall coexisting and coordinating in a working environment that’s off. In fact, that should be the reality in most organisations. You’ll be hard-pressed to find an institution as complex as public service ones that can works entirely in one way of working over another.
The issue is that agile does not flourish on the foundational building blocks that currently support our public service. Our values fiscal responsibility, transparency and accountability shape how money can be spent in the public sector, how work can be planned, and how we expect to keep track of what is happening.
There’s nothing wrong with those values. But the mechanisms by which they is carried out were developed at a time when nigh every piece of work that wasn’t operational came in the shape of a project.
This is one reason why I believe it’s fair to say that our public service is fundamentally projectified (a big topic for another day, but here’s some reading for the curious): The only corridor to funding is through business cases, the only way to plan and manage work is linearly, the only way we interpret progress is through stage gates and red/amber/green status, the only way to govern decisions is through steering committes with more seats than a “Traitors” round table.
Agile doesn’t stand a chance in this ecosystem. To be effective, it needs to be planned, monitored and governed through the tested and tried means that suit the method – the old chestnut of judging a fish by its ability to climb a tree comes to mind.
Consequentially, “wagile” is currently a way to wear the costumes of more flexible and adaptive ways of working, performing an innovation circus that slowly drives its performers mad.
And THAT is what needs out attention now. Rather than trying to mash up methodologies that stem from very specific working environments, expecting them to somehow survive on a foundation that’s tailored for only one of them, we need to find a way to build a foundation on which the inherent multi-modality of administrative work can exist: where agile spaces and be flexible and inclusive, and projects can plan and deliver as they know best.
I’ll write more on the multi-modality of the public sector another time. But with all this in mind, I remain at the edge of my seat to see what Brian Roche’s observations will lead to. My hope is that many of us, workers and leaders alike, know that there’s something at the core of all this that we need to get to – but will we (be allowed to) get there together? Ish.