Current Reality Trees (CRT) from The Theory Of Constraints toolbag 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.

Produced by OmniGraffle 7.18.1\n2021-03-02 10:32:59 +0000 Canvas 1 Layer 1 Story size would be OK, but … Our Planned Releases Are Buggy We do too many unplanned releases per planned release We have not done enough QA per planned release (or iteration): we expected (or were surprised) by running out of time Full QA would take too long in the time allotted in the release (or iteration) cycle Not enough of our QA is automated QA that is automated takes too long so is not run that frequently We struggle to complete work for the planned release and/or iteration Stories are bigger than we estimate - we have trouble hitting and accurately estimating stories that are not small Wrong people on the team for high throughput Wrong technologies for high throughput Story analysis defective in itself Development foundations are crappy Too many odious non- functional requirements per story Our build times are too long (local dev workstation and CI) We build too much per build (local dev workstation and CI) the build builds too much code Our integration tests are too slow (service tests or functional tests, etc) not doing test impact analysis Our integration test technology is slow We do too much setup per integration test BA : Dev ratio is too low BAs not experienced with “ready for dev” stories Devs inexperienced with techs Not enough QA automat -ors our dev workstation suck Too many shared resources between developers or CI (flaky / unavailable / broken from time to time or permanently) Visual Basic 6 (etc) isn’t fast to work with and has upper limits e.g. only DBAs can change table shapes (with delays) we hate our tracker or VCS we are not doing Trunk Based Development (or misunderstand it) we don’t have scripted setup of dev workstations we don’t have scripted setup of shared-nothng environments for devs We started with manual QA (for a smaller application and dev team) and struggle to make the jump to automation now Our QAs feel productive and valuable with the old manual way (in the release cycle) and somewhat lost in the automation world Environment setup is time consuming, expensive, inelastic, and was done years back - so we share (lots) inexperience, “our org is special” what’s in the release often changes part way through (choice of the biz) The biz wants us to dial up releases cadence but we feel we can’t without something breaking “CI server” is late telling us about problems CI is not continuous (per commit) dev workstations under specified (CPU, RAM, Screen) team formation issues The release process itself is error prone we can’t practice releases safely or do rehearsals unsafe, ego, pride/greed/ envy ++ too much outside source control Our pre/non prod envs are shit Devs can deploy to pre/non prod envs themselves (this is not Continuous Delivery) specialist scripts not co- located with app source (or not script-able Time and money not spent on cross training our development isn’t modular enough too many flaky downstack dependencies we’re not using Service Virtualization because because because and because because and because because because and because because and/or because and/or because because because because and/or because because because because and/or because because because because and/or because because because because because because because because because because because because because because because because because and/or because because because because because because and/or because because and/or because depth-first recursive build doing all regardless changed or not we have a actual monolithic source tree and/or because

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.

Updates:

  1. March 2nd: Draft 2 - worked on “isn’t modular” hierarchy (bottom right). See video discussing that

Notes for this mythical average team CRT

  1. 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.
  2. 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.
  3. 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.
  4. You-should-do-DevOPS (without being named as such) is a number of boxes spread around.
  5. 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.
  6. 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.
  7. 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.
  8. 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).

Lean Kata

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.

Background

The Theory of Constraints gives us this industry tool Current Reality Tree. Eliyahu Goldratt devised this “focusing procedure” decades back. Christ 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.

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)



Published

February 19th, 2021
Reads: