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.
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 is the ability to realize value quickly, predictably, sustainably and with high quality.
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.
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:
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.
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.
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 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.
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 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 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.
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.
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, 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 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:
The role of the business architect is to clarify the business
A 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]
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.
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.
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.
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.
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-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.
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.
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
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 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:
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)