There are zillions of ways to make an effective A3. I needed to find a way I could understand intuitively, so I could get past trying to figure out the technique and move quickly on to using it for actual hard problems.

This week, Steven introduced us to the A3 management system and specifically the A3 format for delivering recommendations to our customer.

This is based on a Lean book, Managing to Learn (one of many books Steven lugged all the way across the Atlantic not on his Kindle). The deal is, the A3 is a paper size (approx. USA 11×17), and there are two columns with particular formats for presenting the nature of the problem and the proposed recommendation to fix, in a concise and collaborative manner.

As I was struggling to understand the mountain of A3s (all different) that Steven had brought along as examples, I noticed a pattern to them that meant something to me:

• Harms
• Significance
• Inherency
• Plan
• Solvency

The A3 fits the outline of a very old-school stock-issues high school policy debate case. Of which I’ve written more than a few. (Cool kids don’t debate this way anymore, I’m told.)

• Harms: the problem
• Significance: what is the extent of the problem, and what metrics can be used to assess it before and after?
• Inherency: what structural or attitudinal factors are reinforcing or worsening the problem?
• Plan: the recommendation
• Solvency: how will the recommended action steps resolve the problem, and which metrics will be used to measure success?

And here’s what it might look like in practice:

• Harms: four teams are developing working software, but their integration and stabilization phases are trainwrecks and they have all come to dread their merges.
• Significance: Team A has burned a week of their latest two-week iteration just on merging. Many of Team A’s changes from their previous iteration were lost when Team C merged over the top of them, and this will take at least another week to fix. Meanwhile, Team C’s release, which seemed tested and ready, has been delayed by nearly a month fixing bugs discovered after merging.
• Inherency: the root of the problem is team branches. All four teams are working on the same product, and following a similar release cadence. All four teams easily decompose their work into small increments of working software that they are able to test and release every few days at best, every two weeks at worst. Isolating the teams doesn’t benefit anyone, and has led to the bad habit of isolated test and last-minute merge. No one team or role has responsibility for post-integration testing. Teams can’t easily understand or resolve merge conflicts found after weeks of isolation, so instead they tend to delete the changes they don’t recognize. Minor repairs to their process (many tried and failed already) won’t solve the fundamental problem that needless isolation causes harms. Only a comprehensive new branching strategy will solve.
• Plan: implement a branch by quality strategy whereby the four teams, who are, after all, all working on a single product which is ultimately totally integrated, do their primary development together in one Dev branch.
• Solvency: combining team branches into one will actually eliminate most code conflicts, and make any remaining conflicts smaller, simpler, and quicker to resolve. Earlier integration will force a number of additional practice improvements they are currently avoiding, most especially teamwork and coordination upon each checkin. Bugs caused by integration can be detected earlier. The teams will experience pain at first, especially because they have limited automated testing and regression will place new demands on their testers, but it will expose better data about their specific testing priorities, leading to better fixes in the long term. Finally, the early and frequent integrations should instill a sense, currently missing and sorely needed, that they are ultimately all one product team and that their success is measured not by the achievements of any one sub-team but by the value of the finished product.

So there you are. If you were a traditional-style high school policy debater in the USA in the late 1980s and you now want to know a key Lean management practice… yeah, OK, I’m the only one, aren’t I? Well, I’m good to go now.

And that’s my message here. I’m geeking out a bit about my modest debater past, but the real takeaway here is that sometimes I let learning get in the way of my learning. My new A3 trick is probably sub-optimal in lots of ways, but it’s superior to the A3s I wasn’t going to write at all because I didn’t know how.