Mapping Lean Principles to SAFe® – Pt 1

We haven’t yet come across a recipe for the magic, overnight, organisation-wide adoption of Lean principles. If only! No matter how good a Lean language people speak, the proof is in the code-face pragmatics of everyday software delivery.

‘Scaling’ Lean-Agile is the default journey for putting Lean principles into practice and, of course, there are any number of formal frameworks and vendor-inspired models that are designed to achieve it. The Scaled Agile Framework (SAFe®) is the one we use, not because it’s the world’s most widely-used framework, but because it’s the most closely-aligned to Lean and which best translates Lean into practical behaviours and activities to create the paradigm shift.

SAFe® and Lean product development FLOW

Lean principles have roots in Lean manufacturing and recognise the differences inherent in knowledge work and the knowledge economy. Don Reinertsen’s 2009 seminal work The Principles of Product Development Flow created a new mental model for applying the principles to software development organisations. Derived from the ‘Toyota Way’ and decades of field experience, his eight principles of product development flow were:

• Take an economic view
• Actively manage queues
• Understand & exploit variability
• Reduce batch sizes
• Apply WIP constraints
• Control flow under uncertainty: cadence & synchronisation
• Get feedback as fast as possible
• Decentralize control

Since SAFe® is based on the continuous flow of delivered value within Value Streams through Agile Release Trains (ARTs), we can map each of Reinertsen’s principles to SAFe® and, in the process, show the extent to which principles are embedded in practice.

1. Taking an economic view

The purpose of modern software development is to implement features that deliver economic benefit to an organisation. The focus of Reinertsen and SAFe® is that all software development activities should be viewed with an economic lens which magnifies delays in order to understand their true cost.

Software developers, testers and others should be trained to think of their daily work in economic terms. Three examples in SAFe® are:

• Weighted Shortest Job First (WSJF) prioritisation is slightly modified from Reinertsen’s work – this lean economic prioritisation model focuses on the Cost of Delay & remaining job size to determine the relative value of a set of features. WSJF is a key concept to prioritising the flow of work within a two-to-three-month time box
• Because each level of SAFe® (Team, Program, Portfolio) focuses on delivery & each level utilises the WSJF prioritisation mechanism, the focus is clearly on delivered value that is measurable by the business
• Lean Metrics provide a holistic view of economic value that emphasise the opportunity cost of delays. It’s not easy to measure economic value directly but the proxy variables used in Lean extend the traditional focus of how busy people are in the system to include cycle times & delays which typically have a higher economic impact

2. Actively manage queues

All long queues are bad – they result in delays, waste, unpredictable outcomes and low morale. In knowledge work queues (eg. software that is partially discovered, written or tested) are often hidden. In SAFe®, queues are made visible at different levels of the organisation through portfolio, program and team information radiators.

Little’s Law (describes queuing systems and tells us that average wait time = average queue length/average processing rate). It is helpful in explaining why long queues are detrimental and need to be actively managed at all levels of the organisation. Persistent, longer-lived queues are leading indicators of delays, helping us identify bottlenecks and focus our improvement efforts.

3. Understand and exploit variability

In the world of manufacturing, all variability is considered bad – products must be made within tight tolerances to ensure quality. In technology, there are many incorrect assumptions, risks and unknowns that ensure the inevitability of product variability. Rather than fighting entropy (and having 'death by business case' in search of the perfect plan), organisations use short planning cycles that allow them to adjust to continuous learning and changing business/market demands, thereby exploiting variability rather than trying to contain it.

SAFe® accepts the fact that variability exists and attempts to exploit it where possible by:

• Limiting backlogs to a finite size
• Frequently replanning to adjust and adapt as the organisation learns new things about the solution they’re building
• Deliberately planning Spikes (research activities) to allow teams to investigate & learn how a system will perform prior to predicting a story/feature estimate
• Limiting the utilisation of people & teams to 80% so the organisation can flex to the variability as it happens. This principle is especially counter-intuitive to most matrixed models which attempt to set their resources to 100% utilisation to increase efficiency, something which is contradicted in the principles of flow
• Using an ‘Innovation|Planning’ (IP) sprint to promote innovation events that allow teams the freedom to use their experience & detailed domain knowledge to explore & present innovative ideas to the business, whether it is finding a new development pattern or identifying a fantastic new feature

4. Reduce batch sizes

Traditionally, IT has worked with large batch sizes and accepted large transaction costs (cost of handing work from one group to another). The act of reducing batch size by having co-located, cross-functional teams that deliver small, potentially shippable increments of work is designed to significantly reduce production batch size and transport batch size.

The System team in SAFe® also facilitates the reduction of transport batch size through continuous integration and validation. The collaborative DevOps approach extends the ability to reduce transport batch size by continuously reducing infrastructure and deployment costs through automation.

The batch size sweet spot, found through ‘U-curve optimisation,’ optimally balances the transaction cost of planning and transport with the holding cost associated with requirements, code and tests going stale over time.

At the Portfolio Level, we move away from projects – bringing people to the work – towards Epics or initiatives – bringing the work to the people. At the Program Level, we focus on features which fit into regular cycles and can therefore be completed by one or more teams in less than 8-12 weeks. In this way, Agile programs deliver many small increments of work which, when integrated, fulfil the features and Epics that deliver real value to the business as early as possible.

5. Apply WIP constraints

The simple concept of constraining work in process (WIP) is often difficult to put into practice. In a nutshell, we simply balance the amount of work in process against capacity. Once an organisation reaches its capacity, they stop taking on more work.

A common mantra heard in many Agile organisations is ‘stop starting and start finishing’, which implies that a small amount of work is pulled by teams who are working at a sustainable pace and they drive it to completion before starting any more work.

In SAFe®, WIP is constrained locally by teams up through the program to the Portfolio Level. The principle of constraining WIP is applied with different practices at each level.

6. Control flow under uncertainty: cadence and synchronisation

SAFe® uses cadence – a regular rhythm – to plan and deliver capability at Sprint and Release boundaries to ensure that frequent and regular adjustments are made to the plan to help deliver predictable, valuable results.

Synchronisation occurs at each of the planning boundaries; for example, at sprint boundaries, all of the teams’ delivered work is synchronised, integrated and demonstrated as working software. SAFe® also separates 'development' cadence from 'release' frequency in order to provide an Agile program with the optimal heartbeat for a long-term sustainable pace.

Agile Release Trains deliver integrated, tested capability when the business is ready, which is often not the same date as the planning/development boundary.

7. Get feedback as fast as possible

A key principle of Lean is gathering feedback across all aspects of the process as frequently and as fast as possible. Feedback can be from customers or internally between teams or levels of the organisation. Feedback is omnidirectional and can be manual or automated. The most valuable feedback provides new information from which we can learn. Examples of feedback in SAFe® are:

• At the Team Level – Rapid feedback is gained through co-located, cross-functional teams sharing information & holding sprint reviews with the Product Owner every two weeks. Agile teams also use Spikes to test assumptions & validate risk. Team Level feedback is facilitated by small batch sizes, sprint retrospectives & technical practices such as continuous integration, pair programming, automated testing
• At the Program Level – Feedback is gained from the fortnightly System Demo & the Inspect & Adapt Workshop, which is a Program Level retrospective designed to address & remove systemic impediments. Additionally, small batch sizes in terms of the top 10 or 15 features undertaken in a 8-12 week cycle promote faster feedback from the field

8. Decentralise control

One of the well-known strengths of Scrum® is the use of self-organising teams. In Scrum®, teams are empowered to achieve Sprint goals using their domain knowledge and expertise to decide the best way to implement a solution. Empowering Agile teams and programs to make fast, local decisions at the last responsible moment is the responsibility of servant-leaders and ‘Lean Thinking Manager-Teachers’ (a term derived from Eiji Toyoda's ‘Toyota Way’). Pushing decisions closer to the code face promotes local autonomy and is key to successful Agile organisations.

Oriented towards flow

By explaining in detail how Lean principles are mapped to SAFe® it’s easier to see how the paradigm shift away from economies of scale to economies of flow is achieved. It’s also easier to see at the delivery level how thinking and behaviours are changed by the principles and scaled through SAFe®, and in turn, how an organisation’s DNA is actually edited in practical terms. The organisation is now oriented towards flow – improving its ability to deliver value – rather than the utilisation of people in the system.

In addition to adopting the Lean Principles, SAFe® added a few more. We’ll cover these in Part 2 and explore why they continue to push organisations to be even more effective.