Circles Of Causality

The Misnomer of ‘Move Fast and Break Things’

image06For a while I’ve wanted to visualise the pain points of the development cycle so I could better explain to product & business owners why their new features take time to deliver. Also to squash the misnomer of the overused “Move fast, break things” mantra of Facebook.


So some of you may know that recently Facebook realised this wasn’t actually sustainable once you have your product stable and established. It might work in the early conception of a product, but later on it will come back to haunt you.

At the F8 Developers conference in 2014, Facebook announced they are now embracing the motto “Move Fast With Stable Infra.”

“We used to have this famous mantra … and the idea here is that as developers, moving quickly is so important that we were even willing to tolerate a few bugs in order to do it,” Zuckerberg said. “What we realized over time is that it wasn’t helping us to move faster because we had to slow down to fix these bugs was slowing us down and not improving our speed.”

I’ve recently been reading Peter Senge’s “The Fifth Discipline: The Art and Practice of the Learning Organization” and thought circles of causality would be a good way to express this subject. Using system thinking and looking at the whole picture can really help you stand back and see what’s going on.

circles of causality1Be it growing user acquisition or sales, a good place to start is what are you trying to achieve and how to exponentially increase it. In this case lets say that as a business you want to drive user engagement and grow your DAU.  One possible way is to add new features to your product.

So following the circle in this diagram we assume that by delivering new features, we increase user engagement which in turn leads to growing your DAU/Virality.

Lets assume the product has been soft launched, you’re acquiring users, A/B testing initial features and have begun growing your list of improvements and new features. Lets create a ‘Backlog’ of all this work, prioritise them, plan how we deliver those quickly using an Agile Scrum framework.

We want to deliver a MVP as quickly as possible, so lets do two week ‘Sprints’. The product team have lots of great ideas but far too many to put into one sprint and some of the new features require several sprints. Product owners & other business leaders debate the product roadmap and you have your sprint planning….simple right ?….Well to begin with yes


circles of causality2So lets look at what the size of the backlog does to delivery. In this diagram you see that the size of backlog directly affects how soon improvements/features are made. Why? Well because the backlog is also made up of bug fixes and technical debt, often inherited from your prototyping phase and deploying your MVP.

You’d love to tell the business that you’ll just work on new stuff; but hey worse case we deliver something every two weeks, but some features could take months to appear.

So with a relatively small backlog we are ok. Yes some business leaders are a bit frustrated their feature won’t get deployed in this sprint but the short term roadmap is clear right ?

Dev team gets their head down and get on with the sprint….but in the background product/business owners have moved on from yesterday’s must have feature to yet another new shiny idea or potential crisis; the backlog grows and the roadmap is changed. Features get pushed further down the priority list.

So the situation is we have X amount of resource and over time the business is getting frustrated at the pace of delivering changes to the product. Weeks have passed and only 25% of these ideas/features are shipped.

The Symptomatic Solution

So there could be two potential fixes for this…move faster and drop quality so we can ship stuff quicker or throw more people at it. Lets look at what happens with the “Move fast, break things” mantra. So to increase delivery time we cut corners, drop some testing, code reviews, developers pushed to make hacky solutions etc etc

circles of causality3As you see in this diagram, as you do this you create more bugs and the QA process takes longer. Any initial advantages are lost as this builds up.



Now we have also added a ‘side effect’. More bugs increase the size of the backlog creating the opposite effect you intended in the first place.




So lets put in more man hours (overtime) to get those bugs down and reduce this growing backlog. More overtime increases fatigue & the quality of the work. Developers get burnt out, they make more mistakes, quality of work suffers and again more bugs and are even more demoralised.

Lets look at the result of this on staff & the complexity of their work. In this diagram we see that by reducing quality we also increase code complexity which generates technical debt, which again slows down development. Tech debt is pretty demoralising, as usually no one is invested in fixing it and in most cases you just work around it.

Adding more developers has a different outcome with equally diminishing results. Big teams in an Agile framework, isn’t always a great idea. The typical strategy is to organize your larger team into a collection of smaller teams, and the most effective way to do so is around the architecture of your system.

The harder you push, the harder the system pushes back

When you look at the whole system, each part has a cause and effect. The harder you push one part, other parts are affected. Each one of these parts needs to be balanced against each other so that the system runs efficiently. It’s also important to step back and make sure you are solving the actual problem not trying to fix a symptom.


In this example the perceived view is that the team is moving slowly, whereas in fact they are moving at a pace that balances the system. Move fast, with stable infra is the sensible option. Use system diagrams like this to seek out counter balance to reinforcing circles.

Reference – “The Fifth Discipline: The Art and Practice of the Learning Organization” Peter Senge – Chapter 5 “A Shift Of Mind”


What Size Are You? Experimenting with T-Shirt Sizes in Story estimation

There’s a lot of negative energy surrounding story estimates in most Agile organisations. Developers tend to fear the process of estimating their work more-so than other Agile elements that should in theory be much scarier – such as sacred deadlines or standing up in front of their peers every morning.

Historically, sprint teams tend to suffer from a lot of unnecessary noise focused on estimates – in particular story points. Estimates are *supposed* to give the product owner / producer a broad steer towards the size of the work required; this additional context allows a firmer sense of priority in terms of product direction. Unfortunately, estimates are too often treated as contractual obligations that serve to be an imaginary stick hovering mentally over developers’ heads. As a result, you find sprint teams needlessly getting their knickers-in-a-twist. The problem with using days or hours as a unit for estimating tasks is that these units mean the same for everyone and are comparable.

Ted estimates 1 day for a task – Dougal estimates the same task at 2 days. Without context, this tells you that Ted is twice as good/quick as Dougal. But it doesn’t give the whole story. Dougal might have lots of meetings whereas Ted might have a clear run at his desk for a day. Dougal might be a junior. Whatever the reasons, time as an estimate metric is misleading.

Story points, as an Agile artifact, were supposed to counter this. You’d estimate a story and assign a numerical value to it – and this number meant nothing other than a relative value to the other stories. For example:

  • STORY A = Estimate is 2
  • STORY B = Estimate is 10
  • STORY C = Estimate is 2
  • STORY D = Estimate is 100

The above set of estimates are deliberately meaningless – they only serve to indicate the size of a story when compared to the other stories. We can see that Story D is massive – about ten times the size of Story B. We can also see that Stories A and C are roughly the same amount of work.

However, story points prove difficult when you are dealing with cross-discipline teams. You are adding two estimates together that don’t share the same value system. Let’s say a story requires some Front End, Back End and Design work:

  • Front End estimate = 2
  • Back End estimate = 5
  • Design estimate = 4

You’d add the estimates together and come up with TOTAL = 11. However, you are essentially adding 2 apples to 5 oranges to 4 pears. They are different metrics because the Design team have only estimated 4 compared to other Design tasks.

Recently, we’ve been experimenting at Mind Candy with throwing out numerical values in the Estimate process and replacing them with T-Shirt Sizes. Essentially, sprint members are allowed to give a story estimate in one of five sizes:

  • TENT

How do you measure progress? Well, we’ve trialled drawing a t-shirt on the white-board that corresponds to each story – and when some progress is made, the team member simply colours in a part of the t-shirt. When complete, we draw a smiley face on the t-shirt. We’re seeing how this goes; it’s very indicative and visual and the teams are responding well to it. We’ve thrown out the burndown chart and just using the whiteboard as a quick visual guide to how coloured in the t-shirts are.

T-Shirt Scrum Board

Most importantly, the sprint teams are no longer getting their knickers-in-a-twist.