Paul Hammant's Blog: Software Development Current Reality Trees Starter Pack
Current Reality Trees (CRT) from The Theory Of Constraints tool bag again. This time for software development teams general lack of flow as exemplified by a slow release cadence. No two teams’ CRTs are the same, so take the one in this blog entry with a pinch of salt. If you are willing to start with someone else’s then spend an hour or more fixing it up, you might end up with one that is valuable for your team’s decision-making.
This is a typical CRT for a software development teams that do two or more planned production releases a year. Well all the way through to weekly planned production releases. Dev teams with releases quicker than weekly will not see much relevant in this diagram, but might still find a CRT useful were it to be drawn up for themselves from scratch. For slower than weekly teams, this below is close enough. For them starting with what I have and then tweaking might be useful a good way to get going. It is an amalgam of the last ten I’ve done for different clients, so hopefully no client seems themselves in too many boxes/lines.
That’s just inline SVG, slurp it from theDOM to your drawing package. Or use a purposeful tool like Flying Logic Pro to make CRT from scratch without having to move boxes by hand to detangle lines. Yes, my arrows go in the opposite direction to conventional CRTs. If you’re going to use this for any purpose (as is, or derived), prominently credit me and link back to this blog entry.
- March 2nd: Draft 2: Worked on “isn’t modular” hierarchy (bottom right). See video discussing that - 2 mins
- March 3rd: Draft 3: Worked on “integration tests are slow” (bottom right). See video discussing that - 2 mins
- March 4th: Draft 4: There are reasons why teams can’t/don’t do service virtualization (bottom right). See video showing that - 1 min (no sound)
- March 7th: Draft 5: An insight about Test Impact Analysis. See video showing that - 3 mins
- March 8th: Draft 6: More top level boxes, human factors, and rework added
- March 9th: Draft 7: Add a Selenium node as an example
- March 10th: Draft 8: Tech Debt and pressure to cut corners or go faster added
- June 4th: Draft 9: Add NIH and move it rootwise
- Jan 7th 2022: Add “too busy” and pairing.
- Dec 3rd 2022: Add common code ownership, and re-layout left to right
- Dec 12th 2022: Call out bad branching models
Notes for this mythical average team CRT
- Like in my reduction of cycle times blog entry, there is an idea that your average story size has to be a multiple of the build duration. Also, your iteration length has to be 3x or so multiple of the average story size (at least). Also, your release cadence is a integer multiple of iteration length (2x or 3x or 4x). Some teams have release cadence and iteration length exactly the same (1:1). All Agile dev teams with decent capacity planning understand this. Many teams that understand the cycles aim to get them smaller and smaller. In this diagram three of those four things are in blue boxes - I’ve left out iterations as an explicit thing, but teams could add boxes pertinent to that and move lines around.
- My blog entry on Value Stream Mapping (VSM) might introduce the other tool from Theory Of Constraints that goes hand in hand with CRTs for peering into a teams flow to look for improvement opportunities.
- I think small stories are a good thing. I drill into the causes of that here - Call to Arms: Average Story Sizes of One Day (and more) They’re represented in this CRT in a dotted line box.
- You-should-do-DevOPS (without being named as such) is a number of boxes spread around.
- Continuous Integration - always a problem for teams with less frequent planned releases. Lots of teams say they do CI when they don’t (not continuous), or have CI feedback loop so long to execute it makes talent want to quit.
- Specifically to that last, integration tests (those that are not pure unit tests that perhaps involves TCP/IP, file I/O and multiple processes/threads) are often too long to execute as a suite. Teams chop them or relegate them to a non-continuous build. There are other ways to make that class faster and less flaky.
- Team formation issues includes nuances around Mavericks, Loose Cannons, Dunning-Kruger transgressors, those not leading with strong arguments, quorums against alignment. All as detailed in a team pschology category of my blog). Also ego, politics, envy, and un-safe behaviors and -ism -ist ways of wielding power in a team.
- Planned production releases are your intention. Unplanned releases are the bug fixes that follow planned releases. If you’re zipping you have none. Thus, planned releases to unplanned releases as a ratio is important. At least as an average - your team might have 0.75 unplanned release per planned release @ 12 a year (monthly planned release cadence).
After getting to a stable CRT for your team, by obeying the lean Kata, you’d change one thing at a time. With each change is a moment to measure how well that went - a week or so later. Then a team decision to lock it in or roll it back. After that you’d plan what to try next lean-kata style … after adjusting the CRT for your team.
The Theory of Constraints gives us this industry tool Current Reality Tree. Eliyahu Goldratt devised this “focusing procedure” decades back. Chris Hohmann goes into the creation of a CRT from scratch for a biz problem in this 17 min video.
Future Reality Trees.
Some teams use a Future Realty Tree concept that allows them to imagine where they’d end up after a lean-kata experiment pays off.
Thoughts & real world CRTs online
Tim Cochran goes into “Maximizing Developer Effectiveness” on Martin Fowler’s site Lots of wisdom there. There’s a pic of “Micro-feedback loops compound to affect larger feedback loops” (his figure 3 - 60% of the way down the article) that’s a better visual for the reduction of cycle times thing I tried to get across in #1 above. I’m going to steal it going forward. Or maybe move to a cogs/gears metaphor from a circle of arrows one.
Using Theory of Constraints To Teach Introduction to MIS - Danilo Sirias, 1997. See page 4. I feel seen!
What Should Be Changed? A comparison of cause and effect diagrams and current reality trees shows which will bring optimum results when making improvements - Fredendall, Patterson, Lenhartz & Mitchell (2002)
The thinking process of the theory of constraints applied to public healthcare - Bauer, Vargas, Sellitto & de Souza (2019). See page 15.
CRTs: Collaboratively Tool for Continuous Improvement - Paul Hodgetts presentation (2013). Zoom into page 4.
Thinking for a Change - course handout by Marc Evers and Pascal Van Cauwenberghe (2009). Various pages.
Jeremy Lightsmith, at “Agile Vancouver” in 2011 45 minutes in talks through a CRT for a case he was involved with. His presentation: Agile Isn’t Enough
Thinking Tools - For Root Cause Analysis. Kelsey van Haaster and Tavis Ashton-Bell @ LAST 2015 - I can’t find the home page for the conference :( .. will update when I get more info
Addressing ill-structured problems using Goldratt’s thinking processes: A white collar example - Edward D. Walker and James F. Cox (2006)
I’ve used “because” and “and/or because” instead of the shapes the aficionados would use (see the wikipedia page). This is better for the uninitiated I think. In the one I’ve drawn up here, there is no single root cause represented. No one thing that you could fix to alleviate “the problem”. Of course, the bottleneck only ever moves somewhere else in these things.
For biz/software problems you’d also use Value Stream Mapping (VSM). I learned both CRTs and VSMs at the elbows of Kevin Behr, Jabe Bloom and Jim Kimball (HedgeServ CTO) some years back for business-centric thinking exercises. I have been teaching and using them ever since. VSM is way faster to do - maybe only a couple of hours for a business/software process. The two are complementary. It is true to say that ThoughtWorkers were talking about CRTs as a useful tool as far back as 2010, if I recall. I’m shamed to say that I put “learn this stuff from x and y” on my TODO list, but never circled back.