My local pizza restaurant sells wood-fired pizzas and they are so good people queue out the door.  They offer pizzas with perhaps a dozen different toppings, so the focus is simple.  Not much has changed in the last three years and the customers.  They could add cheesy rings or doughy deep pan bases, but why would they?  The product is tried and tested and customers keep coming back for more.  This is evidence that they produce a great product.

The modern world is rarely simple and complexity is the norm.   A natural response is to second guess customers and plan based upon assumptions and previous experience.  Traditional, ‘waterfall’ projects are based upon such assumptions and typically only tested after all development is ‘complete’.  Even with clear business goals this often results in flabby, unsuitable products customers do not want and did not ask for.

Feedback Loops

What is missing is early and frequent feedback to develop knowledge from two perspectives:

Product feedback – are we making the right thing?  Does this pizza taste good?

Team performance feedback – are we working well together?  Can we make and serve pizza more efficiently?

Empirical approaches, such as Agile, Lean, Lean Start-Up, etc, involve iteration and incremental delivery/releases to enable early and timely feedback.  Stakeholder confidence in the product grows as learning increases from accumulating evidence.  Evidence of progress through reviews, testing, and customer feedback.  Small failures are essential little experiments to harvest evidence to learn what is needed, what is not, and to make adjustments accordingly.  Eric Ries, in The Lean Startup, describes how the organization that is able to learn the fastest will win.

A Clear Business Goal

A clear business goal is a beacon to orientate Agile teams through an initial period of high uncertainty, but it is not enough.  There is a place for upfront, top-down design, and assumptions if validated by bottom-up evidence from iteration.  In the excellent Black Box Thinking: The Surprising Truth About Success, Matthew Syed writes:

‘Ultimately, technological progress is a complex interplay between theoretical and practical knowledge, each informing the other in an upward spiral. But we often neglect the messy, iterative, bottom-up aspect of this change because it is easy to regard the world, so to speak, in a top-down way. We try to comprehend it from above rather than discovering it from below.’

The shape of a project can be formed at a high level with little detail before development.  The Agile team focuses on delivering the solution incrementally.  Each slice is designed, reviewed, tested, and refined until it is correct, from the customer/user perspective, during short periods of development.  These are called timeboxes or more commonly sprints.  Early and continuous user feedback fits with the Lean ethic of reducing waste by focussing on customer needs and minimizing all unnecessary work.

Michael Bungay Stanier talks about ‘The Strategic Question’, in The Coaching Habit:

‘If You’re Saying Yes to This, What Are You Saying No To?’

Some tasks deliver more relative value and must be a priority. Knocking the important things off the list often negates the needs for subsequent tasks.  As the solution unfolds and Agile teams learn what is really needed as they close in on the goal more effectively. Everyone has heard of ‘Pareto’s Principle’ or the ‘80/20 Rule’? Richard Koch defines it in The 80/20 Principle:

‘The 80/20 principle asserts that a minority of causes, inputs or effort usually lead to a majority of the results, outputs or rewards.’

Agile Teams Use Feedback to Informs Adaptions

Open loops mean feedback is actively sought, interpreted, and acted upon to maintain focus on the important stuff. Scrum co-creator, Jeff Sutherland states, in Scrum: The Art of Doing Twice the Work in Half the Time:

‘This allows you to make the features they value, first, and release your product when you’ve only done about 20% of the work. You know it’s not perfect, but it’s darn close. Every hour spent polishing the apple is lost opportunity value.’

Feedback is essential to successful teams, whether they are medical, sports, service-sector, creative, military, etc.  Examples include:

  • OODA, (Observe Orient(ate), Decide, Act) – formulated by the US Air Force
  • PDCA (Plan, Do, Check, Act) – The Deming Cycle used to form the basis of the Toyota Production System and subsequent philosophies
  • Build, Measure, Learn – the Lean Start-up feedback cycle

General Stanley McChrystal notes, in Team of Teams: New Rules of Engagement for Complex World:

‘Efficiency remains important, but the ability to adapt to complexity and continual change has become an imperative.’

Without feedback, teams cannot change and adapt to focus on the right thing, in the right way and at the right time. As Matthew Syed writes:

‘A closed loop is where failure doesn’t lead to progress because information on errors and weaknesses is misinterpreted or ignored; an open loop does lead to progress because the feedback is rationally acted upon’

Too often there is a separation of realities between stakeholders.  If feedback is exchanged frequently – preferably daily – then opportunities to make small changes can be acted upon more easily.  Ideally, feedback opportunities are built into a process.  Jeff Sutherland writes:

‘Scrum incorporates the concepts of continuous improvement and minimum viable products to get immediate feedback from consumers, rather than waiting until a project is finished…You need to get that product out to the public as early as is feasible.  This will get you the feedback you need to power your decision loop and prioritization…Make those mistakes early, with as little damage as possible…Then, when you do an official release, or a rollout of a big program, you’ll have already adjusted and found out what people actually value.’

Such feedback is crucial for a Startup company where uncertainty runs high.  Do consumers even want the product or service?  In The Lean Startup, Eric Ries explains:

‘Instead of making complex plans that are based on a lot of assumptions, you can make constant adjustments with a steering wheel called the Build-Measure-Learn feedback loop. Through this process of steering, we can learn when and if it’s time to make a sharp turn called a pivot or whether we should persevere along our current path.’

Taking time to validate and verify what is being produced saves businesses time and money in the long run.  Failure to ensure quality leads to train crash projects.  Stages trundle into one another, analysis into the design phase, design into development, development into testing, etc.  Testing is typically reduced by over-run and re-work causing high-levels of technical debt and missed deadlines.  Better to take time along the way to see and check.  Samuel Beckett put it best:

“Go on failing. Go on. Only next time, try to fail better.”