No team is an island — co-existing with waterfall during an agile transformation
One of my beloved Accenture Agile Geeks community, Leonardo Fraga, recently asked an excellent question:
I know it is a kind of heresy, but do you know any fresh points of view on how to accommodate traditional (waterfall) delivery and agile during the transition of models? I could only find old multi-speed / bimodal references
My colleagues Matt Phillips and Andrea Rizzo gave some great prompts to consider the agendashift.com and the Kanban Maturity Model, and I’ve previously explored why we should Stop saying “Hybrid Agile” and start saying “compromised”, but this felt like a topic which deserved a longer write up. After all, for most organisations this is reality right?
When colleagues talk about a persistent ‘hybrid’ model my answer is always the same - don’t use terminology to dress up a sub-optimal arrangement, and lull the organisation into a sense they’re getting the best of both. But how can you create the ‘least worst’ interim situation when the target is agile throughout an organisation, but your starting position is the normal mish mash of conventional ways of working (and probably some good old-fashion chaos)?
…and so follows an expanded version of my comments to Leonardo!
1. Set the expectation it will be messy
Anyone who swans in with a bunch of brightly coloured hexagons and value trees in slideware is lying — there’s no single neat way to top-down plan a transformation. Preparing for surprises, and being ready to pivot (i.e. being agile 😉) is the name of the game. Build in an expectation that this doesn’t mean your transformation is failing — uncovering challenges is a sign that people are engaging with the process.
For those who haven’t been part of an agile transformation before, I always recommend the excellent Unicorn Project as a way to get a feel for being ‘inside’ teams as they go through the experience — I particularly like the seeding in of key good practices like “Blameless retrospectives” and as someone who struggles to consume business text books the novel format really helped me.
2. Independence Day
As I, slightly, unfairly highlight out with my much used tortoise-manacled-to-hare cartoon, teams will always be held to the slowest pace of change of any area they have dependencies on. When trying to structure an agile transformation, a key consideration must therefore be trying to carve off teams and areas who can ‘declare independence’ fastest. This might not (and probably won’t be) the same as where the highest business value or priority is — your big CRM programme might be what the execs want to make their flagship agile example, but if the big ol’ legacy database team can work independently and fast, they should be your trail blazers. Those teams who transform soonest will provide some incremental success in their own right, but they’ll also perform the unenviable job of being a battering ram for unblocking the routes to agility and DevOps maturity in your organisation.
The plan for your transformation should be based on reducing dependencies sequentially, carving out each new wave of agile teams to try and minimise how restricted they are
The Kanban Change Management principles of ‘Start with what you do now’ and ‘Agree to pursue improvement through evolutionary change’ are a gift to transformations — and now with the publication of The Official Guide to the Kanban Method it’s easier than ever to help teams apply Kanban to help them on their agile journey.
Why are we mentioning this here? Deploying Kanban coaching and principles to improve the waterfall areas who may take longer to be able to adopt other agile practices will both prepare them for the change and improve their lead time and ability to ‘server’ dependent agile teams who need their systems. Arguably if this goes well, you may even find some of the teams organically grow into agility even if they’re not in a current focus area — and what could be better than that?
Side note: this means actual Kanban methods, not just sticking a board with 3 columns on top of chaos. If in doubt, see the Kanban Maturity Model
4. Promote cadence and transparency
Again echoing the Kanban practice of ‘Visualise’, given that we know our agile and waterfall teams interaction will inevitably get noisy, promoting cadence and transparency is essential. Approaches should emerge during your work, but a few key starters are often:
Working with the same tools
Whether it’s Jira, Kanbanize, or a massive wall of sticky notes (ok… maybe less so that last one these days) trying to standardise the tools teams use to manage and do their work can help promote alignment and visibility within teams. This will mean compromise — everyone inevitably likes ‘their’ tool the most.
Feel the rhythm
Some of your teams may end up working in sprints (and in which case, aligning their length and schedule is a feature of pretty much all scaling frameworks) but beginning to promote cadence is also great for helping your waterfall and agile teams work together. Think about encouraging regular opportunities for:
- Retrospectives: both gathering input on the transformation, and identifying opportunities to make immediate improvements on the ground
- Roadmaps and plans: be wary of scheduling a big planning meeting and thinking this means your teams are “doing PI panning”, but providing regular opportunities to share and agree plans can only be a good thing. Try to ensure the format and approach to this breeds collaboration, not tension.
5. Don’t rush it
Transformations take time. Particularly beware of waterfall areas believing that introducing daily meetings and calling their design activities ‘sprints’ moves them forward. The path to agility requires more than just adopting terminology.
6. A v̶e̶r̶y̶ ̶l̶o̶n̶g̶ just the right length engagement
The fabulous Leise Passer Jensen provided an excellent response to the original version of this article:
I miss, however, maybe the most important: Involve and engage everyone who will be impacted — preferably most of the company if a so-called ‘transition’ is to be successful
My original focus for this piece was about ‘special’ actions for the waterfall/agile feast of loveliness which greets us, whereas involving those impacted is a very sensible idea no matter what can of change you’re making.
It does deserve a special mention here though I feel in that “doing agile to an area” is always best avoided. When training I often cite this as an antipattern when organisations misimplement scaled agile frameworks — working behind closed doors to create a complex governance process, adding a smattering of agile jargon, and then launching it upon hundreds/thousands of unsuspecting colleagues who haven’t been involved in its inception.
In the contet I’ve outlined in this article it’s vital that both the waterfall and agile areas (basically everyone), are informed and able to engage with the changes going on — before, during, and after. This is a natural partner to beginning to create a ‘pull’ towards agility - if the waterfall teams are informed and engaged in what’s going on, they’re more likely to actively want to move in that direction themselves. Trying to build this sort of enthusiasm and inspiration will always deliver a better and more lasting impact then telling teams to “become agile”.