Institutionalizing Continuous Improvement

(and the value of formal patterns)

I’m not Christopher Walken (that’ll be relevant in a bit). So I want to talk about formalizing continuous improvement a bit.

I’ve argued for a while that there are two explicit processes missing in SAFe (and outside SAFe, in the practices of most corporate-scale IT shops).

• Capturing product ideas and product improvement ideas from the teams building the products;

• Explicitly getting feedback on the results/outcomes of delivered work

In most large orgs, the “why” is determined on the 35th floor, the “what” on the 22nd and maybe some of the “how” in the annex where the work floor is sited. There’s a strong one-way channel down, and one of the things that leads folks to be critical of SAFe as a scaling framework is that is makes that downward flow of information very efficient and enables responsive orgs that maintain that one-way flow.

In addition, the product ideas are developed by folks who send the work out to be done, and then pivot and start working on digesting the next big strategy they have been given from above.

All of this is driven by a kind of ‘semiconductor’ information flow (as Alex Yakyma puts it) where the org is optimized for the smooth flow of information down and out – and much less so for up and in.

Thinking about it, I want to add a third one.

• Formal processes for continuous improvement

Yes, teams do retros and ART’s do I&A sprints – but in reality what work flows out of these tends to be process-focused and given to the scrum master or RTE. I & A is too often the buffer for ‘work not done this PI’ and while good ART’s go through the exercise of doing an ART retro – is the work that flows out of it really a priority in the next PI or sprint?

So we’ve got a problem – a world in which the issues seen by teams – whether they are for improvement in product, process, or impediment – have trouble being brought in to the flow of work moving downward and outward through the organization.

How do we solve it?

Sidebar on ‘formal’ processes

Let me digress for a moment and talk about ‘formal’ processes and their value. I’ve said in the past that our job as agilists is to ‘democratize excellence’ – to take what the top leaders and managers do innately and come up with rote processes which almost anyone can learn which will let the average leader or manager improve – and maybe open the door in them to eventually become most excellent.

Many agilists are dismissive of formal processes. I think they’re wrong.

The rote processes that define Scrum are valuable because they serve as mechanical steps anyone can readily follow that do the things that a team that’s truly gelled as high-performing does without thinking.

Kind of the way the footprints on the Arthur Murray dance lesson teach people like me to move in ways we’d never be able to do otherwise. Or the way Mr. Miyagi used waxing and painting as ways to build base skills to learn karate.

So the beauty of Scrum (and SAFe IMHO) is that they set out the mechanical process. If that’s all you do, you’re still likely to be a better dancer than if you didn’t have those guides. You may still look ridiculous, and you’re nowhere near dancing like Christopher Walken – but you’re on the path.

Being stuck at the mechanical/rote level is not great – and part of our job is to convince the organization’s leaders that it’s not the end, it’s the start of their change journey. But to me, launching change in an organization without some formal steps for them to learn and act on is like calling me up and asking me to be in a Fatboy Slim music video. It’s not going to be pretty or good.

…back to the point:

So what I think we need are explicit mechanics – rote steps – to move improvement work up and in so it can be a part of the ongoing work that we do.

Let me suggest what that might look like.

When a team does a retro, it should decide on some set of things that need to be done to make things better. Those things may be doable by the team itself (including the Scrum Master or Product Owner), in which case they are captured and added to the backlog, or they may not, in which case they need to be escalated.

We need a clear escalation path, with some explicit process to capture these, affinity-group them (because the odds are that an issue one team has isn’t their issue alone), move them to a group that has the capability to solve them, and then add them to that group’s backlog.

This needs to happen visibly (the issues need to be visible and the work needs to be visible in the work management tool), and on a cadence that aligns with the planning and intake cadences of the groups.

In my piece on LPM, I suggested that the core of LPM was capacity allocation, and then work breakdown to fill the capacity. I want to argue here that we need a class of capacity reserved for improvement – so  we might have ‘strategic work’ then ‘tactical work’ then ‘BAU or KTLO work’ and then ‘improvement work.’ How you allocate capacity will be organization specific – and more, specific to a moment in time for each organization (it ought to change dynamically).

So we’re going to need someone who plays the role of the intake engine for these improvements, someone who clusters them and looks for patterns, and who allocates things out to the right people. This can be collaborative, with someone facilitating (and taking responsibility for it happening), or it can be one or more people tasked with the role.

Amusingly, I just read Rob England and Dr. Cherry Yu’s book ‘The Agile Manager’ yesterday, and they call for almost exactly the same thing – an “Advancement” team (although as I read their model that team is responsible both for transformation work and improvement work. I see these as separate functions – the improvement work should persist indefinitely, while I see transformation as an intermittent, stepwise process that proceeds as there is change capacity available (see my piece on “offramps”).

I think formalizing this is an important part of the change recipe – what do you think?