'Practical Agile' - using Agile to make agility happen
So I’ve burned a bunch of electrons talking about agile practices, and about ways I’d consider changing frameworks we use for agility. One point I keep bringing up is that we start too often with misaligned incentives baked into the business model of management & transformation consulting.
As Utah Phillips famously said:
…The rule is, that in the crew they're supposed to pick among their own members, who's going to be the cook. Now, they don't try to do it sensibly, like draw lots or decide who the best cook is. What they do is they wait to find out who bitches and whines and pisses and moans the most about the cooking, and they say "alright wise-guy, you think you can do better, you get to be the cook."
So if I think what we’re doing is unsustainable, and that I can do better, what’s my plan? How do we align incentives and solve for three problems:
Maximizing the likelihood that the improvement effort that’s been contracted will succeed;
Maximizing the value delivered by the actual improvement;
Maintaining value for the people doing it so they can be paid decently well and we can attract good people?
I think there’s a direction that supports these. Let me base it on a few principles of what I’m calling ‘Practical Agile.’
Our goal is organizational fitness – helping organizations develop the characteristics that will help them compete and thrive in the environment they operate within;
Agility (at every level) is only a part – a key part to be sure - of what’s needed for organizational fitness (much as flexibility is a part of physical fitness – it also requires strength, endurance, and skill). Change must address everything an organization needs, and agilists must assemble a true cross-functional team able to effectively support every aspect of an organization’s needs;
We work incrementally, with a focus on driving change that addresses the real obstacles preventing organizations from being ‘fit’ so that there is immediate delivery of value;
Internal change agents must own the change and be able to sustain and continue it – establishing, advancing, and enabling those change agents must be a key part of the organization’s change plan. Ideally, these change agents are already embedded within the management hierarchy – i.e. our goal is to turn all managers into coaches.
So what’s the role of the coach/consultant then?
Let me suggest a few and remind folks that they may not all live within the same person or organization – but they should all be a part of the same team. I’m working to define a taxonomy that will help determine where these live, and I’ll add some tags from that.
But first a digression – am I saying that the market for agile coaching and transformation is over? No, not nearly. I’m saying it needs to evolve, and that one of the main reasons for the evolution is that the easy successes have mostly been won. There will be agile transformation engagements that will be won by companies like my old one, going forward. There will be role and team training and team-level coaching. The market isn’t going to vanish with a snap of Thanos’ fingers.
But I do think that everyone who makes a living doing agile is going to face a steeper hill, and if you aren’t already near the top of the profession, it’s going to get harder and harder to get the work that will help you advance, and that the economics underpinning the industry are shifting.
What I’m doing here is trying to set out a part forward – to frame up what I would tell a trusted client or someone who worked with me. How should they frame engagements? What skills do they need to look for and build, respectively?
Let me try and build some ‘classes’ of what it takes to really move an entire organization (I’m sure I’m forgetting something, weigh in and remind me):
Change the ‘making’ process – we want to realign the factory floor to make work more incremental and team-driven;
Improve ‘making practices’ – in tech, move to DevSecOps, outside tech, develop similarly contained skills to integrate the full spectrum of operations;
Change the ‘designing’ process to tie to closer to customer needs and make it incremental and value-driven;
Change the ‘planning’ process – broadly, move from from PPM to capacity management in LPM;
Change HR practices to move away from ‘winner take most’ and rules-enforcing to talent- finding, creating, sustaining;
Shift finance from ‘a constraint’ to a ‘guardrail’;
Bake in a ‘change’ process - build institutions to support continuous improvement (why institutions? Because if it’s no one’s job, it doesn’t usually happen);
Change management behavior from ‘command-and-control’ to ‘in command and out of control.’
Agilists typically focus on #1 and maybe #2 and #3, rarely #4. It’s not nearly enough, and the experience of most agile transformations I’d argue, suggests that without the other changes, the impact of agile change is deeply constrained. And today, virtually all organizations have been exposed - at some level - to these practices.
The challenge I’m seeing is the declining effectiveness of introducing these practices by themselves - and hence the declining value in the marketplace of people who implement them.
One school of agilists – what I call for shorthand the ‘break down management structures’ one, seems to want to restructure organizations in a way that eliminates the other factors. (Yes, I’m not giving full credit here, and that discussion is worth its own piece.)
I want to argue instead that to be truly valuable as agilists, we must be a part of a cross-functional team that has the full range of capabilities to do the work – that we should apply the practices we teach to ourselves, and the work we’re setting out to do. We need to look in the mirror and apply what we teach to what we do.
What does that look like practically? Watch this space.