Achieving Business Agility at All Scales (Book in work)

Achieving Business Agility at All Scales: Transforming Your Organization with Lean Thinking and Lean-Agile Patterns is a work in process. It is being shared so that interested readers can provide feedback to the authors. Please do so on the LinkedIn post here that announces it

Many of the articles pointed to need updating or are incomplete. They are provided to allow the interested reader to see what is being included.

This page should be thought of as an extended table of contents. The book will be printed by taking the pages pointed to in this document and putting them together. When a separate page exists for the chapter, a link to the chapter is placed to the right of the chapter title.

Note that several of the pages here require registration on either our university or our portal (registration is free).


FLow for Enterprise Transformation (FLEX)



New Roles

Technical Agility

Getting Started



Who this book is for

This book is written from the perspective of a person who is leading an adoption of or transformation to Lean-Agile methods. It can be used as a standalone approach or as a way to facilitate and improve an adoption of SAFe. All roles in the organization will, however, get value from reading the book, in particular, any chapters that are specific to their role.

Business Agility

Business agility is the ability to realize value quickly, predictably, sustainably and with high quality.

Why we need a new approach

The software industry has come a long way in 20 years. However, the movement from waterfall to Agile is far from complete. The challenge is that while the staged gate, mindset of predictability of waterfall has been fairly acknowledged as being less than effective, the team centric focus of Agile limits its effectiveness as well. The lack of how to coordinate multiple teams and no role for management leaves much for individual organizations to figure on their own.

There are new approaches to Agile at Scale, such as SAFe, LeSS, and DAD, but all are frameworks. Frameworks are useful to use as tools but can cause challenges when used as solutions. We cannot solve our challenges based on set solutions, even those that contain options.

What is needed is an approach that is an integration of business and development needs that can both guide us with principles and take advantage of existing patterns of success. Fortunately, one has existed for decades – Lean-Thinking. The challenge is that the physical world is quite different from the software world and a good translation of principles and practices has not been, as yet, achieved. This is one intention of this book.

Lean-Thinking for the mid-scale

Lean-Agile is not just Agile wrapped in Lean. And especially not Agile with Lean principles in it. It is a different mindset that incorporates the good in Agile.

See the chapter Lean-Thinking for the Mid-Scale.

Why Agile should be more predictable than waterfall

Many executives have been led to believe that Agile is inherently less predictable than a waterfall approach.  However, Agile, when wrapped in Lean-Thinking, can be more predictable because it enables working directly on the true causes of unpredictability in software development. Waterfall’s large projects and stage gate approach cause delays in feedback, workflow, testing and integration. These delays inherently create a significant amount of rework (redoing requirements, reworking code that missed requirements, finding bugs, thrashing during integration).  This work, of course, is never planned for, and therefore result in inherently bad estimation, not to mention that eliminating this extra work improves productivity.

See the chapter Why Agile Should be More Predictable than Waterfall.

FLow for Enterprise Transformation

Introduction to FLEX

FLEX is Net Objectives’ collection of Lean-Agile practices and principles that can be used to achieve business Agility. It is not a framework but rather a set of patterns that can be used on their own or applied to existing frameworks and methods.

See the chapter FLow For Enterprise Transformation (FLEX).

Collaborate across the enterprise: The Guardrails

Agile frameworks tend to have people agree to work together by using the framework. This is one of their appeals – providing guidance on how to collaborate.  But since no one-size fits all, this runs the risk of becoming dogmatic and following the framework instead of using it as the basis for what works. We believe an agreement on how to work together, regardless of approach, is critical. We call these “guardrails” because they act as guides wherein you they can be followed however appropriate by different roles as long as one stays consistent with their intent.

The basic agreements. We agree to:

  • Work on items that will realize the greatest amount of Business value across the enterprise.
  • Collaborate with each other in order to maximize the realization of Business value across the enterprise.
  • Ensure that all work will be made visible.
  • Take the necessary steps to sustain or increase predictability.
  • Keep the work throughout the value stream within capacity.
  • Encourage everyone to strive for continuous improvement.

See the chapter The Guardrails.

Understand your value stream

The value stream is one of the most important concepts in Lean.  The value stream can be thought of as the flow of work that takes an idea to the point of realization of value. Notice that what is most important is the realization of value because merely delivering product is of no value by itself. You must attend to the total time from start until your organization or your customers realize value from your efforts.

See the chapter  Understand your value stream.

Why looking at time is so important

One of the main tenets of Lean is to attend to the time between starting a project until its completion. The reason is that delays in workflow and/or feedback creates additional work to be done. By eliminating these delays, waste is eliminated.

See the chapter Why looking at time is so important.

Common challenges to flow

Because systems drive behavior and most companies are organized in similar ways, it should not be surprising that most organizations have similar challenges.

See the chapter Common challenges to flow.

FLEX solutions

The solutions to the common challenges are also similar. The order in which a plan is created has to be tailored to the organization doing the adoption, of course.

See the chapter FLEX solutions.

FLEX and the Value Stream

Lean Portfolio Management

Although our Lean Portfolio Management webinar is part of our Simplifying SAFe webinar series., it is independent of SAFe itself as it presents our approach and not SAFe’s approach to Lean Portfolio Management.

See the chapter Lean Portfolio Management.

Lean-Agile Product Management

Lean-Agile Product Management is a key part of Business Agility: the quick realization of value predictably, sustainably and with high quality. It is primarily focused on the agile Business Discovery of value to turn goals and objectives into appropriately defined and scoped requirements of those aspects of a system being built. These higher level, but well scoped and defined requirements feed business delivery by providing thinly sliced segments that can be quickly developed, providing quick feedback and the ability to pivot. Product management therefore holds business owners as its primary customers and guides business delivery to meet the expectations of its customers.

See the chapter Lean-Agile Product Management.

Reorganizing the talent

Teams should be organized in such a way that the value stream that the train is involved in stays mostly within the team. Work should be able to be brought to the teams, not having the teams be reformed for every new chunk of work. While stability is a desired trait of trains, complete stabilty is neither achievable nor desirable. Growing organizations need to embed new team members as well as adjust to changes in strategy.

See the chapter Reorganizing the talent.

Acceptance Test-Driven Development (ATDD)

Acceptance Test-Driven Development epitomizes Lean-Agile more than any other practice.  It’s heart is collaboration between product owners, developers and testers to both understand what is needed by the customer as well as how to set up the development team to implement and validate it.

See the chapter ATDD.

Planning events

Planning events are almost always useful when kicking off a transition to Lean-Agile methods. For mid-scale to larger organizations they are also sometimes useful on an ongoing basis.

See the chapter Running Effective Planning Events.

Development cadence and synchronization

Cadence means to do work at a specified interval of time.  One can think of cadence as a heatbeat. Scrum implements cadence at the team level with Sprints. At the end/beginning of a sprint a demo and retrospection are done as well as a refinement of what work will be done. Kanban merely has a timeframe within which these occur. The main difference is that in Kanban these can more easily be done on a continuous basis if desired.

In any event, the cadence of all teams should be synchronized so that there is a time for teams to reflect on how they are working together. This also provides an opportunity to test the integration of the teams’ work.


Lean-Agile at the team

There are many ways to achieve agility at the teams – Scrum, Kanban, a combination of the two or even a pure flow model.  We include all of these under the umbrella of Lean-Agile at the Team.

Shared services

Shared services, such as business intelligence, need to be managed differently from the development teams in trains. There are a few reasons for this. First, they are pulled in different directions from multiple teams in multiple programs. Second, the requests made often occur due to discoveries made during a sprint so it is often difficult to plan for.

Because of these challenges, shared services most usually are best run with Kanban.

See Northwestern Mutual Case Study: A SAFe Implementation Retrospection for an example of how shared services can be managed in a SAFe implementation.

See the chapter Shared Services.



Business Architecture

Business Architecture is “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.”ref  It is an overlooked, but essential ingredient of Agile Product Management as it relates new offerings to existing capabilities and can inform how our work management should be done to improve our systems. See a short video on business architecture here (free, but registration necessary).


Being able to see the work, workflow, impediments and constraints are critical aspects of a collaborating, well run organization.

See the chapter Create Visibility.


Culture is an important part of any organization improvement – either adoption or transformation. Two valuable perspectives are:

New Roles

Business Architect

The role of the business architect is to clarify the business

business architect is a practitioner of business architecture, a discipline concerned with developing and maintaining business capabilities of the enterprise in line with the corporate strategy as well as contributing to the business strategy and plans. This also includes design of capability models and related architectural solutions of business tasks, mapping capability functionality to the internal and external resources, developing business transformation plans jointly with senior business management, handling business solutions to the delivery and operational business functions of the company, developing and maintaining architectural governance and controls over implementation. For each step of the business transformation plan, business architects contribute in development of a blueprint of the enterprise in order to promote a common understanding of the organization and alignment of strategic objectives with tactical demands.[ref]

Product Manager

The Product Manager is the “face” of Business value to the development value stream as a whole. Product Owners go to the Product Manager for anything that requires beyond their level of customer/stakeholder understanding. See the Product Manager Reading path for more.

Technology Delivery Manager / RTE

The Technology Delivery Manager  (TDM) is responsible for managing the delivery of the technology solution of a business increment and the flow and continual delivery of the program or value stream producing it.

The Technology Delivery Manager is the person responsible for ensuring and managing the Business evolution of the system – that is, building the system oriented around quick delivery of Business value increments. The Technology Delivery Manager is responsible to maintain the functional integrity of the system throughout its development and deployment. The Technology Delivery Manager is responsible for risks associated with delivery.

The TDM is a superset of responsibilities of SAFe’s RTE. If one is doing SAFe, it is best to just call it the RTE and expand the role a  little.

See the chapter Technology Delivery Manager.

Application Development Manager / Systems Architect

The Application Development Manager (ADM) is responsible for the holistic integrity and functionality of technical solutions and system products. This includes setting technology boundaries, policies, and engineering practices and standards for system evolution and integrity. Thus, the ADM role is about the content of the system.

To do this, the Application Development Manager is responsible for creating “just-enough” architecture, plus identifying standards and processes that directly relate to successfully implementing the product itself.

Counterbalancing this, the Application Development Manager also makes sure that no architectural, process, and standards constraints are placed on implementation and maintenance beyond the minimum needed to build the product correctly.

In SAFe, the ADM role is played by the systems architect and solution architect.

See the chapter Application Development Manager.

Leadership and management

Management, of course, is not a new role. However, in the Agile space it is just coming into its own, having not even been mentioned once in the Agile manifesto. Different approaches present management in different ways. Our view is that management’s role is to create the eco-system in which teams can work in a self-organizing manner towards their organization’s goals.

See the chapter Leadership and Management.

Technical Agility

Emergent Architecture

A key tenet of Agile development is that architecture has to emerge. This is sometimes called Agile architecture as well.

See the chapter Emergent Architecture chapter.

Test-First at the team

Test-driven development is the practice of collaborating with all roles involved in a requirement and writing acceptance criteria for the behavior desired. It actually happens at all levels of Agile requirements but is best known at the product owner – development team boundary and with developers working with each other. The first is call Acceptance Test-Driven Development because we are looking for the acceptance criteria of the ask. At the team level, it is called Unit Test-Driven Development. There is some conofusion that TDD refers to Unit TDD but that is only because when TDD was first introduced with eXtreme Programming, it was being done primarily by developers.

See the chapter Test-First at the Team.

Getting started

How people learn

Before beginning an adoption or transformaiton it is important to understand how people learn and how organiations change.  While on one hand many people likek to be told what to do, there is no one-size-fits-all approach. So transformation leaders find themselves in the dilemma of needing pseudo packaged solutions that may or may not fit their needs.

Also, people have different learning styles and learn best over time.  Much of the intensive training many undergo just before an adoption bounces off. In addition, much of this training is not real hands on, but either PowerPoint presentations or exercises that mostly convey concepts.

See the chapter How People Learn.

Scaled learning

Agile has grown exponentially. This has created a demand for training that is also growing exponentially. It is unfortunate that most trainings provided, however, have not followed good training practices but have been intensive 2-4 days classes without doing any real work in the classroom. This has created a knowledge gap where people have supposedly learned something (even been certified in it) but don’t know how to apply it. This gap has often been addressed through onsite coaching. However, as more and more large companies are adopting Agile the approach of intense training and expensive coaching is no longer a viable alternative for most companies.

See the chapter Scaled Learning.

Roadmaps for discovery and the roll-out

Roadmaps need to be adjusted for who is driving, who is involved, what the culture of the organization is and where they are. The following figure shows a starting roadmap before being tailored for these factors. This chapter discusses both roadmaps to discover what you need to do as well as how to roll it out.

See the chapter Roadmaps for Discovery and the Rollout

Gauging your progress

There is much more to improvement than merely “inspecting and adapting.” It is important to understand different methods of improvement (such as Plan-Do-Study-Act, double-loop learning, OODA), learning styles, how people best learn, people’s biases against learning, how to measure your progress, the way complex systems react to change and if there’s a guide you can use to make hypothesis for improvement. Saying “just do it” just doesn’t do it.

See the chapter Gauging Your  Progress.

Scorecards as roadmaps

Scorecards can be used as both an assessment of how an organization is doing and as a roadmap fro next steps.

See the Scorecards as Roadmaps chapter.


Deciding if and how to use SAFe at small- to mid-scale with FLEX

Adopting the Scaled Agile Framework (SAFe) is not for everyone. There are several reasons to do so and several reasons to avoid it. And, of course, there is a middle ground. The chapter Deciding If and How to use SAFe at Small to Mid-Scale with FLEX takes the concepts of FLEX and uses them to help people:

  1. make a decision about if and how to adopt SAFe
  2. understand how SAFe adoptions can be made both more effective and easier to adopt using some of the concepts in FLEX
  3. see how to adopt SAFe with all of SAFe’s terminology but still incorporate some useful concepts presented in FLEX

Adopting SAFe at small-scale

SAFe was designed for large organizations. Essential SAFe is intended to be used by programs within a large organization. This chapter discusses how to adopt SAFe at Small Scale by using just what you need and adding some concepts from FLEX. See chapter here.

A lightweight, Lean approach to Agile at mid-scale (100-1000 people in technology)

This article is a synopsis of how to use FLEX at mid-scale. See chapter here.

Resources related to Business Agility

A Primer on Emergent Design (Article)
Acceptance Test-Driven Development (Article)
Adopting SAFe at Small Scale (Article)
An Agile Parable (Article)
An Introduction to Lean-Agile Software Development (Article)
Deciding If and How to Use SAFe at Small to Mid-Scale with FLEX (Article)
Dependency Management, Collaboration and Planning at Small Scale (Article)
Emergent Architecture (Article)
FLEX Solutions (Article)
Gauging Your Progress (Article)
Guardrails for the Team and Scrum Master (Article)
How People Learn (Article)
How to Use Scrum in Mid to Large Scale Organizations (Article)
How to do SAFe at Small Scale (Article)
Lean Portfolio Management (Article)
Lean-Agile Product Management (Article)
Lean-Thinking for the Mid-Scale (Article)
Manage Work-in-Process (WIP) by Focusing on Finishing (Article)
Re-thinking ScrumBut and ScrumAnd (Article)
Reorganizing the Talent (Article)
Right Sized Epics in SAFe (Article)
Roadmaps for Discovery and the Rollout (Article)
Running Effective Planning Events (Article)
Scaled Learning (Article)
Shared Services (Article)
Systems Thinking Philosophy as it Applies to Frameworks, Methods, and Approaches (Article)
Technology Delivery Manager (Article)
Test-First at the Team (Article)
The Software World Is Not Like the Physical World and What That Means (Article)
What Is the Economic Cost of Delay for Software Delivery? (Article)
Why Agile Should Be More Predictable Than Waterfall (Article)
Why Looking at Time Is So Important (Article)
Why WSJF Should Be Done on MBIs and Not Features (Article)