It’s probably worth starting by explaining where the three circles ideas came from. Most of it is born out of my frustrations of seeing too many attempts at Agile fail or become very hard work to the extent that Agile gets a bad name or teams adopt a “fragile” approach instead.

In all client meetings you will always here me talk about why attempting to make Agile adoption your goal is the best way to fail. When the focus of the conversation is shifted to make the end goal improved effectiveness everyone feels much more relaxed and at ease discussing better ways of working.

Effectiveness

I talk a lot about effectiveness but how do I define effectiveness? For me, effectiveness is best represented with the above Venn diagram which asks the three questions: Are we building the right thing, are we building it right, and are we building it fast enough. The first circle, are we building the right thing is important because there’s nothing worse than building more of the wrong thing quicker. And Agile practices can certainly help you to do this! Building the right thing right is not a new concept. The concept has been around a long time and referenced in many peoples work following Senge, Deming, and many other systems thinkers. But something was missing for me. The reason I added the third circle (are we going fast enough) was to complete the missing element of the mental framework which would make sense of the behaviours and beliefs of organisations and teams I come across all the time. Are we building it fast enough is a really important element that underpins entire business cases. But ultimately it all comes down to balance.

The three circles in isolation:

• Build it fast enough: We can be really efficient but delivering the wrong widget badly is pointless
• Build it right: We can deliver high quality but taking years to develop a widget that no one wants is pointless
• Build the right thing: We can build the right widget but building it badly and taking too long to do it is pointless

What role do the three circles play on a day to day basis? I see them used as guiding principles at every level of the organisation. You can see evidence of the three circles at work across all of my clients in metrics, governance & controls, risk management, explicit policies in Kanban systems, and prioritisation controls. They are as steady as the pole star and provide everybody with a true north.

Before we dip into how they manifest themselves on a day to day basis I just want to explore the Venn a bit further. The whole point of a Venn is that it’s not just about three circles but rather all 7 zones when you count the overlapping areas.

Where all three circles overlap in the centre is the sweet spot. This is when you are building the right thing right and quick enough. This is effectiveness. But what is in the other overlapping areas where just two circles overlap? These areas for me are where most organisations are lacking processes and practices.

The three circles combined:

• Build it fast enough / build it right – we have built the widget in record time with zero defects and the shiniest interface known to mankind. Nobody needs the widget – pointless
• Build it right / build the right thing – everybody needs and wants this widget, we are building it with zero defects and the best user interface known to mankind. The first release will be in 300 years time. Pointless. [extreme I know but just demonstrating a point]
• Build the right thing / build it fast enough – everybody needs and wants this widget, we can deliver it in days, but it will be riddled with defects and the user experience is very poor. Pointless.

The trade-off zones

These zones offer the most opportunistic, but at the same time, the most perilous areas for product development, depending how they are managed. These are the zones where I find most teams spend their lives. These are the zones that demoralise teams, strip companies of profits, and yet could be the zones offering maximum growth for companies. Let’s explore what we commonly find in these zones and what they represent.

• Tech Debt – so many teams talk about tech debt. In some organisations it’s become a taboo word. I’ve even heard some managers say it’s an excuse for developers to moan…sigh. Whatever you think it is or isn’t, the first step is to bring out your dead debt. Create a section in the backlog and declare a tech debt amnesty. Once the debt is visible and quantified it can be managed. We manage this by making sure stakeholders understand the basic concept of ‘the more tech debt you have, the slower development will go’ then feed this into Kanban system policies. Tech debt isn’t something developers intend to create. They normally introduce it as the result of a trade-off decision. This is not the same as cutting corners or shoddy workmanship.

• Short Changing – “If we descope the Back Office tools from the release and defer them to the next release we can ship on-time”. This is a totally reasonable decision, however you are now on a perilously narrow cliff edge. What if you make the release without back office tools and your back office demand increases? How will you handle the demand? What if the back office tool requirements never get reprioritised again due to other “more important customer facing features”? Minimum Viable Product (MVP) is a great concept but I’m seeing it used more and more as a facade for short changing.

• Releasing with known issues – is a trade-off decision that lands squarely at the feet of the product owner. Again, it’s an effective mechanism for releasing value early and frequently but neglect servicing the known issues will simply degrade the quality of your platform and customer experience over time. Card these decisions up and make them very clear in the backlog where they can be managed.

• Incidents and support – another common pattern I see with dotcom’s is a growing backlog of P3, P4, and P5 incidents/problems. The reason the backlog is growing is that individually the P3’s are not deemed high enough priority to select when compared to a new feature. They are normally logged in a separate system from development teams and not made visible on the card walls of dev teams. By building this source of demand into your product development lifecycle you will improve effectiveness. This can be used as a key quality metric to drive more effective behaviours and decision making.

• Rapid Prototyping – we’ve got an idea. We don’t know if it’s the right idea so let’s validate it. We can trade off customer experience to a certain degree (low fidelity prototype) and quality (only works on browser x and device y so let’s do controlled testing with users who meet this criteria). By trading off customer experience and quality we may deliver faster but ultimately what we are doing is enabling faster feedback.

Trade-off decisions come in many forms and for many reasons but the main point here is to find a way to capture these decisions in a controlled fashion and make them highly visible in the backlog. Combining this with Kanban’s classes of service you can enable a system of balance across the three circles.

In this photo you can see classes of service in operation. The white cards are the big strategic focus. Pink, green, blue, and yellow cards represent trade-off decisions and investment themes. The 1-2-1-1 cards on the top edge of the card wall show the allocation of capacity which supports the Next column selection policy. Basically, capacity is reserved for 1 green card, 2 yellow cards, 1 pink card, and 1 blue card to be ‘in play’ on the card wall. Given the total ‘in play’ capacity is 11 cards, this means the nearly 55% of the overall team capacity is dedicated to the trade-off / investment theme work types and only 45% to the overall strategic work.

 

The three circles and Metrics

I don’t intend to cover the whole metrics piece in this article as I run a separate training course on that and it’s too big to cover here, but all zones in the Venn diagram have supporting metrics which in turn has the result of driving behaviours across the whole organisation towards effectiveness. Watch out for my upcoming blog post to cover the metrics in more detail.

 

The three circles and Governance

Whether you’re operating a product development lifecycle or a project lifecycle one of the most powerful concepts Agile practices give you is feedback loops. I always introduce the three circle concept as a set of questions that could be asked to improve the effectiveness of product steering groups or project boards when they meet:

• Are we building the right thing – show me evidence that customers have been involved in the validation, how confident is the Product Owner that we’re developing the right thing, what is our insight and web analytics telling us about what we’re shipping?

• Are we building it right – how many trade-off decisions have we all made? Show me the breakdown of the backlog including tech debt, live defects. How satisfied are our customers? Show me data.

• Are we building it fast enough – what is the burn-up chart telling us about how frequently and when value will be released? What can we do to help the team to go faster? Do we really need to ship everything in the backlog? How is our return on investment impacted by what we discuss? If we deliver a week later does our business case still stack up? What about two weeks later?

Steering groups or project boards should be asking these questions very frequently, say every week as a minimum. The above questions should also give you a glimpse into some of the metrics mentioned in the previous section.

 

Practical manifestations of the three circles on the ground

So the first step as described above is to make all trade-off decisions visible in the backlog. Simply doing this doesn’t make the right work get prioritised but it certainly helps non-technical folk to understand the big picture which in turn influences their decision making process.

If necessary, use classes of service as a mechanism to dedicate capacity to specific work types. For example, if team morale and performance is suffering due to increasing levels of tech debt but your product owner is hell bent on only delivering new features then classes of service may help with this, especially when the capacity allocation is agreed at a higher level than the product owner.