Chapter 2

Lean
People dont buy WHAT you do, they buy WHY you do it. Simon Sinek says that this is the fundamental reasoning behind what he refers to as the Golden Circle, which he describes as a natural law occurring in many forms, in the same way as the Golden Ratio. He cites example of the Golden Circle including Martin Luther King, who said I have a dream not I have a plan and the Wright brothers, who succeeded first with manned flight despite having less money, education, connections and publicity as competitors. The Golden Circle suggests that to maximize our chances of success we should start with WHY, before determining HOW, and finally WHAT. Starting with WHAT will lead to focusing on activity at the expense of outcomes.

The Golden Circle

Starting a kanban system design with WHY involves knowing why you want to use a kanban system and the goals you are aiming for, rather than using a kanban approach just because it seems popular or a good idea. Therefore, begin by

defining your WHY, deciding where you want to go and creating a vision of the future that you hope the kanban system will help create. Then the kanban system will be a means to an end, rather than an end in itself. Your WHY is your destination, and your kanban system can be HOW you get there, and guide WHAT you do to get there.

WHY
A WHY is what motivates people to take action. It is a purpose, a cause or a belief. It is a reason to care and want to get out of bed in the morning. A WHY is not to make money. Money is a necessary precondition for business, in the same way that breathing is a necessary precondition to living although our purpose in life is not to breathe. Making money may also be a desirable result, but it is not a WHY. WHY is the equivalent of the System Thinking premise of purpose. Complex Systems have a purpose which influences behavior, the product of the systems elements and interactions. Dave Snowden uses the Magic Roundabout in Swindon as an example of a complex system whose purpose is to enable a high throughput of cars with a low accident rate. Reports show that it achieves this purpose, despite also being generally regarded as one of the scariest roundabouts in existence. By starting with WHY, the roundabouts designers created an effective, safe and resilient WHAT. Starting with WHAT leads to the less scary but more common design.

Magic Roundabout

WHY is always going to be context specific, but one simple generalization would be that it is to satisfy customer demand. Demand analysis can help understanding of what work adds value, and helps us towards our WHY, and what work doesnt add value. John Seddon describes failure demand is work that results from not doing something right, or not doing something at all. That is not to suggest that we should strive for perfection and be right first time with up front analysis and design. Value can still be added in small, incremental and iterative steps. Think of it like a ticket machine at your local deli. When a customer first takes a ticket then the request can be considered value demand. Subsequent tickets for the exactly same request can be considered failure demand. However, further tickets could be for similar, related requests because the customer comes back for more of the same, as opposed to exactly the same. Simon Sinek argues that our brain is wired to start with WHY. Our first brain, the Limbic System is what deals with emotions, unconscious thought, instinct, and governs our behavior. Our thinking brain, the Cerebral Cortex, is what deals with rationality, conscious thought, intellect, and governs our language. Thus, our natural behavior is to make decisions emotionally, unconsciously, and instinctively. We then justify those decisions rationally, consciously and intellectually with facts. I have just bought a new car (well, new for me) and spent a not insignificant amount of money in a totally impulsive purchase. I had no intention of buying a car when I entered the garage, but fell in love with the car and ended up talking myself into deciding it was an opportunity I would regret if I missed it. Similarly, both times I have bought a house, which is both an important decision and major investment, the decision was because the house felt right. The size, condition, location, price etc. came second.

How
HOW describes the way that a WHY will be realized. It can be thought of as a set of guiding principles that help map a WHY to a WHAT. A HOW can also be a specific outcome that is to be accomplished without detailing the activity and output required to complete it. Additionally, HOWs are often ways of differentiating approaches and describing them in comparison to competitors. One way of describing HOW a Lean or Agile approach enables a WHY is with the metaphor of a Recipe for Success. David Anderson popularized this idea with the following recipe: Focus on Quality

 Reduce WIP Balance Capacity against Demand Prioritise Similarly, my colleague Ken Clyne at Rally talks about the fundamentals of Agile as: Focus on customer value Deliver early and often Reduce batch size Pull quality forward Inspect and adapt Create a collaborative culture These recipes are a guide to HOW to achieve Agility in order to achieve a WHY. However, they are not specific enough to describe WHAT to do. A common explanation for WHY organizations want to become Lean or Agile is Better, Faster, Cheaper. These are at best HOWs, and not WHYs. In fact, I would suggest that cheaper isnt even a HOW. To paraphrase John Seddon, focusing on cost will usually result in cost going up. Another approach to describing HOW to become Agile is through a transformation strategy or roadmap. Options for which path to take include beginning slowly with a single, fully Agile pilot project from which to learn, diving in and moving all project to an Agile approach in one go for clarity of message, only beginning new projects or initiatives as Agile to avoid risking current work, or incrementally solve specific challenges with certain practices for a more evolutionary transition. Working Agreements can also be considered as a description of HOW. Explicit policies for how work is done can be created by recognizing how value is created, how that creation is visualized and made transparent, how the work in process is limited, what cadences are used for synchronization and co-ordination, and how continuous learning and improvement happens. My personal take on HOW to be Agile is in terms of flow, value, capability. Achieving flow involves eliminating delays and focusing on reducing the lead time from concept to consumption. Delivering value involves making sure that

the right things are being worked on and the right problems are being solved rather than doing the wrong things righter. Building capability involves developing people and their skills working as teams aligned to the organization strategy.

Lean and Agile How

What
WHAT is done proves what is believed. It consists of tangible ways with which a WHY is realized and provides clear data points that actions are according to a WHY. Agile practices are WHAT teams do in order to enable them to realize their WHY. Further, practices can be associated with HOW agility is demonstrated, in terms of flow, value and capability. The following is one interpretation of some practices. Im sure there are many others.

Flow
User Stories
User Stories are a technique to break down functionality into small pieces of demonstrable functionality which can create single piece flow.

Limiting WIP
Time-boxing and kanban-style limits are both ways of managing WIP and enabling a focus on finishing rather than starting to keep work flowing.

Visualization
Visualization approaches help teams see all the work so that they can focus their energy in the right places to keep flow.

Co-location
Strong teamwork and collaboration minimizes the need for queues and batches which cause delays.

Test Driven Development

Test Driven Development, with its emphasis on automated unit testing and refactoring, keeps designs clean and quality high so that new work can progress quickly.

Continuous Integration
Continuous integration and deployment help works flow right through to the customer without lengthy release processes causing delays.

Value
Vertical Thinking
Product Backlogs, User Stories, Minimal Marketable Features and other valuefocused forms of requirements are intended to help teams ensure they are delivering maximum benefit.

On-Site Customer
Similarly, the On-Site Customer, or Product Owner roles are intended to maximize collaboration with people who are determining and receiving the value.

Demos and Reviews

Iteration demos and reviews are a means of gaining early and continuous feedback and validation that the product is delivering the intended value.

Continuous Delivery
Frequent and continuous delivery means that the value can be realized as soon as possible.

Automated Testing
Acceptance Test Driven Development and Behavior Driven Development provide techniques for delivering value through quality and clarity of functionality.

Capability
Teams
Dedicated, cross-functional, value focused teams mean that learning and knowledge is kept, shared and built upon to develop capability.

Knowledge Sharing
Various collaborative practices, such as Pair Programming, Collective Code Ownership, Group Design, Team Estimation and Planning Poker similarly share knowledge around a team.

Demos and Reviews

Regular demos and reviews provide a cadence with which feedback and learning can build product capability.

Retrospectives
Regular retrospectives provide a cadence with which feedback and learning can build team capability.

Visualization
Visualization of work, and the way value is created, gives visibility of bottlenecks and constraints and other issues such that they can be resolved to improve capability.

Slack
Slack ensures that teams have spare capacity to both address these issues, and spend time on other forms of capability development which will improve future productivity and performance.

Conclusion
When embarking on a change initiative using Agile approaches, always Start with WHY. Use the WHY as a True North with which to guide the Agile transformation and steer decisions on which Agile practices to use for what reasons. Understand HOW agility is going to help progress towards the WHY and WHAT Agile practices will provide the means to get there. A clear WHY, that people are motivated by, will make it more likely that people will want to use Agile. However, Thomas Edison said that vision without execution is hallucination so dont stop at WHY, but make sure the Agile

HOW is also well known and the Agile practices that form the WHAT are clearly understood to ensure that the goal is successfully reached.