Thanks to Rachel Davies for sharing her approach to constructing a diagram of effects.

Rachel proposes that the diagram of effects can trigger a team to discuss how a variety of issues relate and goes on to highlight advice from Bas Vodde and Craig Larman in their first book “Scaling Lean and Agile Development”, the First Law of Diagramming is “The primary value in diagrams is in the discussion while diagramming—we model to have a conversation.”

I have been using a slightly different approach in retrospectives recently. With a similar intent to Rachel I hope to trigger conversations that result in a team sharing there concerns and issues and coming to a shared view as to how these relate and where would be a good point for intervention.

I’ve used this approach a couple of times recently when running retrospectives that cover a few months i.e. not iteration retrospectives where we choose to commit a few hours to investigating issues in some detail.

My favoured approach is borrowed from Eliyahu Goldratt’s Theory of Constraints, it is one of the 5 TOC thinking process and is know as a current reality tree. A current reality tree is a tree of undesirable aspects of your current situation, these are connected to indicate cause and effect.

My approach to constructing this diagram is as follows:

Identify undesirable effects
Invite the whole team to stand around a table thinking of undesirable / unwanted traits of their existing approach (process, tools, methods etc.). Each item should be written on an index card and placed on the table in no particular order. Team members can try to avoid duplicats but if one pops up it is not a problem.

Begin to identify cause effect relationships
Invite the team to select two related cards. These should be stuck on the board and joining with an arrow pointing from cause to effect.

Continue to grow the diagram
The whole team should collaborate to add the cards to the diagram. When I first tried this I wondered how I would cope if groups of cards were not related. I’ve not seen this actually happen yet but should it then I guess we allow for the growth of separate diagrams until we discover a relationship.

Review relationships
In CRT literature there are a set of steps for assessing the existence and relationships between UDEs. My approach is to invite team members to consider where items are missing. Often where many causes relate to a single effect there is a missing intermediate effect.

Since I tend to run this approach in a time boxed session I an looking for the point at which returns begin to diminish. As the group settle on a basic shape and begin to look for intervention points I move to support this.

A good candidate point to intervene at would be contributing to a number of effects or participating in a feedback loop. By focusing on one effect we can select actions that will contribute to reducing this effect and by association those related effects.

Of course, an added benefit of this approach is that we can use the cause and effect diagram to review the effect of our interventions; did we get it right, if not was there something we missed in the analysis?

I hope that this is useful. Do share if you’ve used this approach or something similar yourself.

There has been some renewed discussion recently on the subject of technical debt, this has been played out on twitter as well as a variety of blog posts including this one.

The technical debt metaphor is one I use often and I believe that there is some clarification required around this subject.

At it’s broadest, technical debt is any trait of the current system that is considered sub optimal from a technical perspective. The debt aspect reflects the cost of ownership of that trait. For example and overly complex and untidy method is sub optimal, it incurs cost each time it needs to be re-visited and re-understood due to either a defect in the logic or a new requirement. This method obviously incurs more cost if it is re-visited more often.

Much of the debate recently has been focused on the times that it might be good to incur technical debt. The debt metaphor reminds us of borrowing money from the bank to get that new toy a little sooner. The question here is two fold, does technical borrowing exists and how can we view the rate of interest or total cost.

Before we can consider technical borrowing we need to split technical debt into two categories. First, the design or implementation decision that was sound the day it was made but now, with new information, is constraining our ability to progress. Second, the quick and dirty approach that we can see on the day of writing is gong to cost us very soon.

The first category of debt is a direct result of doing the simplest thing that could work and resisting the temptation to predict the future. We develop simple software that is easily changed through effective use of tests, the code that is written is written well. We categorise these design traits as debt when new information presents its self and we identify a change that will enable the system to serve us better. We may decide to make the change or not based on the ongoing cost of maintaining an design that no longer reflects our understanding of the problem or technology.

The second category is often the result of a deadline looming. A common chorus of “lets hack this in now and we’ll fix it later” is coupled with the nagging concern that later never arrives. In my mind, this category of debt can give the first category a bad name. But, is this thinking sound? Surely there are times when the wrong technical solution is the right business decision. It is my belief that there are situations where a quick fix is the right decision, imagine a major flaw that brings down a trading system. However, there are too many instances where code bases become un-maintainable through a feeling of time pressure that leads developers to incur debt with little or no benefit. In fact, in most cases, untidy, poorly designed software incurs cost both short and long term. In the short term, defects delay the release of the software and in the long term software is difficult to maintain and rigid in the face of changing business need.

So we arrive at technical borrowing. The decision to borrow must be explicit. As a team, along with appropriate stake-holders consider the decision. For example,

we have selected framework X for the next release, it does not offer the scaling flexibility we would like but we believe that our early entry to the market is a higher priority. We plan to move to framework Y in the next release window to achieve our target scaleability.

There are less extreme examples of refactorings that should be done but won’t fit in this iteration. Again, be explicit. Discuss the need for refactoring with your Product Owner or Project Manager, consider the cost of the refactoring, the cost incurred by not doing so, the risk of refactoring. One approach to maintaining a healthy code base is to keep a backlog of refactoring and allocate time in each iteration.

However, beware the temptation to save time, get it done, do a quick fix or tidy it up later. In almost all cases code that is hurried, poorly designed, overly complex or untidy will incur far more cost both short and long term than the time saved today by not doing it right.

Finally, this can be most difficult in a legacy code base where technical debt abounds. I use a simple motto that has served me well with a few teams:

Do no harm!

Where you cannot fix it all be sure to agree, as a team, that you won’t make it worse. In fact agree to making one small aspect of everything you touch better for the next person.