Tag Archives: SAFe 4.0

Book review: The Lean Machine

1001004008192950The lean machine. How Harley-Davidson drove top-line growth and profitability with revolutionary lean product development by Dantar P. Oosterwal. In SAFe you can find several references to this book. For me a reason to review this book.

The book is divided in three parts. The first part, the first chapter, explains the current state of product development and shows how many organizations have structured their product development. The second part, the chapters two through seven, gives insights how Harley-Davidson’s learning environment looks like. The last part, chapters eight through sixteen focusses on the learning and discovery journey in the application of lean principles, which resulted in knowledge-based product development which helps to increase new product throughput, to reduce time to market and to improve quality.

In the first chapter we get insights in a traditional command and control product development organization using very detailed standards for product development, controlled by stage gates and where problems only show up at the end of the development cycle during testing.

In the second part we focus on Harley-Davidson’s learning environment.

Chapter two describes the history of Harley-Davidson and how Harley-Davidson made a transformation towards lean manufacturing. As a result, the organization was divided into three business areas (circles) focussing on manufacturing customers, manufacturing products, and providing the required support. At the intersection of these three circles was the Leadership and Strategy Council. This circle organization structure requires trust and unpredicted levels of collaboration, a lot of coaching and investments in personnel. The traditional command-and-control was transformed in a consensus-driven organization with decision taking by individuals, shared or group and mechanisms for managing conflicts.

To complement this circle organization a formal business process was created to empower the entire organization and fully harness the energy of the workforce. This business process is anchored with three overarching “umbrella” constants: values, issues and stakeholders. The process can be visualised with the following flow: Constants – Vision – Mission and Operating Philosophies – Objectives – Strategies – Work Unit Plans – Work Group Goals.

Chapters three and four put the Product Development Leadership Learning Team (PDL2T) central. This team embraces Peter Senge’s book The Fifth Discipline to build and maintain a learning organization (Systems thinking, Personal mastery, Mental models, Building shared vision and Collective team learning).

We get insights in the set-up of the meeting room and agenda, a code-of-conduct to enable dialogue and establishing learning conversations so the attendees will balance between advocacy and inquiry and know where they are on the ladder of inference in conversation. Based on the conversations we see the creation of a system model example.

Chapter five is all about firefighting and the tipping point. The tipping point refers to that point at which a minor change ‘tips’ the system into a new and irreversible condition. Think about a delay in one of the projects or a new project that will put the whole portfolio at risk. To solve (firefight) the problem we will use some of the resources of another project resulting in an issue for that project too and before you know you are only firefighting issues in many projects in your portfolio without delivering as was promised. Consequences of this are analysed by using a system model the PDL2T created. Based on analysis of the system model and the data two critical elements were identified. cadence and flow are necessary to establish effective and efficient multi-project product development.

Chapter 6 goes into the details of having a cadence and flow. Many organizations use a phase and gate development model. Will this bring execution certainty? Probably not, it will maintain financial control, brings discipline but on the other hand it will throttle development and flow and instil bureaucracy. Having a cadence, the rhythm and the heartbeat that drives effective product development, to pace the work is much more beneficiary to deliver more or with other words to increase the flow of delivered products (or projects). Within Harley Davidson this cadence and flow was translated in standardized pieces of work called bins representing small, medium and large projects. For every bin the scope, schedule and resources was clear. This resulted in a standard portfolio were the sequence of large, small and medium size projects was clear as well as what could be managed in parallel. In the portfolio it became clear for everybody how much could be delivered (flow) and when (cadence).

Chapter 7 goes into supply and demand. Based on data analysis it became clear that improvement of throughput of new products will result in increased customer demand.

Part III: knowledge-based product development

Chapter 8 looks into possibilities to apply lean principles in product development. Is it possible to use lean principles to create cadence and flow? You get an explanation how the Wright brothers took a systems approach to their study of flight focussing first on solving the three primary obstacles preventing successful flight (wings, power and craft dynamics).

Chapter 9 gives you a first understanding of the product development learning curve. Chapter 6 already gave some cons of a phased or stage gate development process. Here you will get some more insights. Every phase builds on the previous one and each phase has specific criteria that need to be met to continue with the next phase. This life cycle is A linear ‘design and validate’ process which promotes ‘point-based’ solutions. Key is the phenomenon that is termed “false positive feasibility”. Based on this we pass tollgates and use redesign loops to fix design problems during testing with delays as a result. See the animation.

In chapter 10 we get an explanation of product development design loops. Every design loop ends/starts with an integration point. At those integration points you control product development. And chapter 11 emphasized on learning cycles. A traditional phase gate methodology promotes progression of product development linearly through stages of development. These decision gates are intended to control risk by stopping the flow of work. As a result, this methodology encourages a linear, point-based development mind-set. Only in the last phase we have the possibility to learn and find out whether the design is truly feasible. This point-based mind-set results in false positive feasibility. Examples of learning cycles are Plan Do Check Act (PDCA) or Look Ask Model Dialogue Act (LAMDA). In linear point-based development, the learning cycles occur as unplanned rework loops to fix the problems. To avoid this, we have to follow a set-based product development.

Chapter 12 gives more insights in set-based development by explaining the usage of the limit curve. Set-based design doesn’t mean that you have to develop in parallel several options but in your design you work with bandwidths (see the limit curve) and use the data to turn it into visible knowledge. Based on this knowledge you will reduce your options to move forward in the right direction. Combining set-based development with cadence and flow through experimental learning cycles results in a knowledge-based development system.

In chapter 13 the leadership learning and pull events are highlighted. The objective of a pull event is to focus the development organization on a tangible event to force completion of a learning cycle to physically demonstrate it.

Chapter 14 gives some best practices to quickening product development. We get an explanation of combat planning. Combat planning is suited to turbulent and ever-changing conditions and relies on sound aggregate objectives where alternatives are developed by individuals in order to ensure achieving shared goals. We get insights in the usage of help chains and visual management as well as After Action Reviews (AARs) as learning tools.

In chapter 15 Oobea stands in the spotlights. The Oobea process and room is explained. This Oobea is all about collaboration and sharing. Oobea is the Japanese word for “big, open office”.

The last chapter shows that Harley Davidson made an enormous step forward by developing and using this knowledge-based product development cycle.


After reading this book I can now see why there are several references to this book in SAFe. Also the usage of set-based development is now much clearer to me as well as the negative side of stage gate development cycles and the “false positive feasibility”. A must read when you want to apply lean in product development!

For more information, see: www.theleanmachine.org


Where run and change the business from a portfolio perspective meet and integrate

If we look at traditional portfolio management, like MoP or SfPfM, the focus is on doing the right projects and programmes in the right way and delivering business benefits. These are temporary set-ups to help the organization to change. I would say the traditional change in the perspective of change the business and run the business. See attached figure 1 which shows the position of portfolio management in this traditional world according tot he MoP framework.

Dia3We see, more and more, organisations benefit from the fact to keep multi disciplined teams together to deliver more often and faster changes to existing products, systems and processes to accommodate business agility. These teams become permanent and will have their position in the organizational structure. This means these teams become part of the Business as Usual / Run the business environment. In this case, the work to be done, the functional changes, additions, regulatory changes etc. will be brought to these teams. The teams can focus on the development or become DevOps like teams. And this is a complete mind shift if I compare this with the traditional projects and programmes where the people are brought to the work itself.

I expect that the number of projects and programmes will decline because much of needed changes will be handled by these permanent teams. I don’t believe projects and programmes will disappear completely. For transformations, developing new product/market combinations, organizational and/or behaviour changes etc. we still need these temporary projects and programmes but after delivering, and closing these projects/programmes, new permanent teams can be established to maintain and operate the results. In these situations, we can still benefit a lot from frameworks like PRINCE2 Agile, AgilePM, MSP, RPM, and AgilePgM.

We see an enormous increase in the usage of agile delivery frameworks like Scrum by these permanent delivery teams. We also see an explosion of the number of these teams and this asks for a certain level of coordination between these teams. Delivery of specific changes may ask for orchestration between these permanent delivery teams. The usage of Scrum of scrums is not enough and new frameworks to help with this coordination are needed. Frameworks like Nexus and SAFe are developed to support this orchestration.

Like we had in the past, also for these permanent teams we need to prioritize the work to be done. At the lowest level, the development team itself, a product owner can do the prioritization, and if there are a few teams a group of product owners can discuss and agree about the prioritization among the teams. But when we have more and more teams there is definitely a need for portfolio management at the highest level. The SAFe framework contains a portfolio level to divide budget between different value streams based on the alignment with strategic themes. Within the value streams epics are prioritized by using backlog and using simple business cases or mechanisms like Weighted Shortest Job First (preference for those epics with the shorter duration and higher Cost of Delay).

As a result, we will have two portfolio management mechanisms. One for the temporary bigger one-time changes in the Change the business organization and one for the changes managed by the permanent delivery teams in the Run the business organization.

I would suggest to integrate these two mechanisms into one portfolio office. In figure 2 I changed the original set-up based on MoP and suggest to integrate the portfolio part of SAFe with MoP.

Dia4It still starts with Strategic / Business Planning. The Portfolio Office needs to be closely aligned with this strategy team. Based on the strategy there will be the understanding of strategic themes (SAFe) or categories (MoP). Here we also need to understand which value streams in the organisation are supporting the strategy. As a result, one or more permanent teams can be dismantled or added. In the traditional set-up portfolio management was only looking at Change the business and prioritized the work to be done by the Programme and Project Management organization. Now we see that also the work to be done by the Development / DevOps teams as part of Run the business needs to be prioritized. During the Understand practice (MoP) we will look at all traditional changes and Epics and categorize them across buckets for the traditional (temporary) world as well as the Backlog for the (permanent) world. Following the SAFe framework these Epics can be assigned to the corresponding Value Streams and within the Value Streams (outside the portfolio Office) to the corresponding Agile Release Trains and from there, via the Program Increment Planning meetings to the delivery teams.

I am looking forward to your ideas regarding this set-up. Many people are looking for Agile Portfolio Management. Maybe this article can trigger a discussion and as a result an outline of Agile Portfolio Management can be co-created.

Scaled Agile Framework SAFe 4.0

This week I joined a great Leading SAFe 4.0 training class. Pieter de Beijer from Capgemini managed to give a good overview of the SAFe 4.0 framework. We simulated a PI Planning meeting and had many discussions regarding the practicality and usage of the method. I summarized this SAFe 4.0 framework for the readers of my blog.

The Scaled Agile Framework (SAFe 4.0) synchronizes alignment, collaboration, and lean-agile delivery for a large number of agile teams operating in a business as usual/indefinite environment. For one-time programmes/projects you could better use MSP, AgilePgM, AgilePM or PRINCE2 Agile.

Extensive information about SAFe 4.0 is freely available on ‪www.scaledagileframework.com. See attached picture. If you use the website this picture contains behind every icon a hyperlink to the explanation, including hyperlinks to definitions or other articles and where applicable downloadable templates etc.

SAFe in 8 Pictures with Speaker Notes (V4.0.1)SAFe 4.0 is based on four core values, a lean-agile mind set, nine principles and can be divided in four levels: team, program, value stream and portfolio level and is supported by many techniques/practices.

  • Core values: Build-in quality, program execution, alignment and transparency.
  • Lean-agile mind set: Lean house, leadership, respect for people and culture, flow, innovation and relentless improvement and support the agile manifesto.
  • SAFe principles:
    1. Take an economic view
    2. Apply systems thinking
    3. Assume variability; preserve options
    4. Build incrementally with fast, integrated learning cycles
    5. Base milestones on objective evaluation of working systems
    6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths
    7. Apply cadence, synchronize with cross-domain planning
    8. Unlock the intrinsic motivation of knowledge workers
    9. Decentralize decision-making.
  • Techniques/practices (not limitative):
    1. WSJF: Weighted Shortest Job First: to prioritize based on CoD/duration (CoD =Cost of Delay)
    2. CoPs (Communities of Practice)
    3. MBSE (Model Based System Engineering)
    4. Economic framework
    5. Metrics on Portfolio, Value Stream, Program and Team level
    6. budgets

Team level

On the Team level we find Agile Teams. These teams are cross-functional, empowered and self-organizing teams who deliver valuable, tested, working products every two weeks. These teams will benefit from Scrum, XP and Kanban practices including planning, execution, demonstrations and retrospectives and deliver value via (Enabler) User Stories in a Team Backlog and Team Objectives. On this level we see the Agile Team and the Scrum Master and Product Owner.

Program level

On Program level we see a virtual self-organising organisation of 5-12 agile teams (50-125+ individuals). Every two weeks a tested and working product increment will be delivered that fits within a vision, and is compliant with architecture and user experience guidelines. In the framework this is visualised by an Agile Release Train to deliver solutions to customers via system demos and any time releases. This Agile Release Train will synchronize the iterations of the underlying Agile Teams to frequently deliver valuable and evaluable system/product-level solutions driven by Enablers and Features in a Program Backlog.

On the Agile Release Train, we see, besides de Agile Teams the following roles: Release Train Engineer (RTE; Chief Scrum Master), Product Management (to define, prioritize the Program Backlog), System Architect-Engineering (technical solution guidance), System Team (integration), Business Owners (the key stakeholders).

One iteration is a fixed time box of ten weeks (default) called a Program Increment containing five iterations (sprints). Every increment starts with a Program Increment (PI) Planning meeting of two days and ends with an Innovation and Planning (IP) iteration (the fifth). In this iteration there is room for validation, innovation/hackathon/spikes for the next PI, education and a Program Inspect and Adapt (I&A) workshop and the next PI Planning meeting.

Value Stream level

Value Stream level: this optional level (new in version 4.0) will help to build really big systems or products and coordinates and integrates multiple Agile Release Trains and suppliers into one Value Stream to deliver an integrated solution via enablers and capabilities prioritized in a value stream backlog. All Agile Release Trains will have their PI Planning meetings at the same time. Before and after the PI Planning meeting there are scheduled pre- and post PI Planning meetings to build an aligned plan and to recap, communicate and provide feedback via Demo and Inspect and Adapt

Within the Value Stream level we see the Value Stream Engineer (VSE, compare the RTE), Solution Management (compare Product Management) and Solution Architect/Engineer (compare System Architect-Engineering) and all the other roles mentioned at program level.

Portfolio level

On the Portfolio level we have a Portfolio Backlog of prioritized Enablers and Epics related to Strategic Themes of an Enterprise which will be delivered by several Value Streams. Financial governance with dynamic budgeting will take place on Value Streams to accommodate dynamic budget adjustment to meet changing business needs. We see the following roles: Program Portfolio Management, Epic Owners and Enterprise Architect.

Witin SAFe we will not see separate manager positions but self organising teams on all levels:

  • Team level: Agile Team – PO – SM
  • Program level: System Arch/Eng – Product Mgmt – RTE
  • Value Stream level: Solution Arch/Eng – Solution Mgmt – VSE
  • Portfolio Level: Enterprise Architect – Program Portfolio Mgmt – Epic Owner

Relations between the levels:

  • Process: SM – RTE – VSE – Epic Owner
  • Product: PO – Product Mgmt – Solution Mgmt – Program Portfolio Mgmt
  • Delivery: Agile Team – System Arch/Eng – Solution Arch/Eng – Enterprise Architect

Hierarchy of artifacts: Epics – Capabilities – Features – Stories