Achieving Business Agility at Small to Mid-Scale (Book in work)

“Achieving Business Agility at Small to Mid-Scale: A Guide to Enterprise Wide Effectiveness With 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 the True North Consortium LinkedIn discussion group

You may also be interested in the companion piece Lean-Agile at the Team: A Lean Approach to Scrum and Kanban

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. Also be aware that some articles require subscribing to this site (no fee for this but you will get monthly emails from us which you can opt out of). 

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).

Introduction

FLow for Enterprise Transformation (FLEX)

Lean Practices

Teams

Organization-wide

New Roles

Technical Agility

Getting Started

Ongoing improvement

Miscellaneous

Introduction

Who this book is for

The task is, not so much to see what no one has seen yet; but to think what nobody has thought yet, about what everybody sees. – Arthur Schopenhauer

This book is written more for the attitude a person has than for the role they fill. If you are looking to know how to create more value for your organization or its customers this book is for you. This is not yet another ‘Agile’ book trying to provide a path for you to follow. It is a book that presents both experience and theory so that you can make decisions for yourself without having to reinvent the wheel. The gap between what is known and not used is much bigger than the gap between what is known and needed. This book focuses on what we know works, but has not been widely adopted.

It is written from the perspective of internal change agents. However, regardless of your role, improvement has as much to do with conveying concepts to those you work with as they do your understanding them.  Because this book takes an holistic view of the challenge of organizational improvement, it can be used by anyone to help influence any other role.

If you are a small company (less than 100 in technology) who is looking to do SAFe and want to get a quick review of what’s in store, read these two chapters.

  The Business Case for Agility

  Using the Essence of SAFe at small- to mid-scale

If you come across any terms you are not familiar with, just take the links present as needed.

Why we need a new approach

I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Buckminster Fuller

Those who cannot remember the past are condemned to repeat it. George Santayana

Insanity – doing the same thing over and over and expecting a different result – Albert Einstein

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 waterfall’s mindset of predictability and stage gates has been fairly acknowledged as being less than effective, the team-centric focus of Agile has limited its effectiveness as well. The lack of a focus on business agility,  an unclear role for management, and how to coordinate multiple teams, has left many organizations with reasonably effective teams but still being unable to deliver value effectively.

There has long been a belief by many promoting Agile that intelligent people in self-organizing teams will figure things out if given a few basic practices and principles. Evidence shows otherwise – not because of a lack of intelligence but because they are busy working and often don’t step back and take the time required to figure things out. This is not to say that self-organization isn’t important – it is. But it is best done when teams know what they want to do.  This is why our current way of giving some intense training and leaving people alone or, alternatively, providing expensive coaching is expensive. The first is expensive in people’s time the second expensive to the company’s budget.  People need both a way to start and a way to overcome challenges that present themselves. Taking advantage of people’s experience while providing them a support system while learning is a must.

Many Agilists, and Scrum (the most common Agile framework)proponents in particular  have long claimed the goal is to “be Agile.” I believe this is a mis-guided goal. Not surprisingly, it leads to executives and management not embracing Agile which has become a bad word in many organizations. There are several reasons for this. First of all, requiring people to change values is both more optimistic than evidence suggests and in some ways demeaning as it doesn’t respect where they are.

Jerry Sternin’s observation that “it is easier to work your way into a new way of thinking than think your way into a new way of working” is consistent with Lean’s focus on eco-systems.  But more than a shift from people to environment is needed. Our industry is overly focused on certifications and frameworks. Improvement is a journey and the goal is to get better, forever.

The latest approaches to Agile at Scale, such as SAFe, LeSS, and DAD, but all are frameworks. Frameworks are useful to use as tools. However, they 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.

This work is based on Lean-Agile. This means that the context for all the work is Lean Thinking. Lean Thinking provides an holistic view, focuses on the eco-system within which work takes place,

Lean Thinking for the mid-scale

Theory without experience is worthless. Experience without theory is expensive. (paraphrase) – Edwards Deming

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.

For more information, please read the chapter The Essence of Lean Thinking.

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.

For more information, please read the chapter Why Agile Should be More Predictable than Waterfall

The Business Case for Agility

Business agility is the ability to realize value quickly, predictably, sustainably and with high quality. This chapter explains why this is so important and provides some concepts which are useful to achieve it.

 For more information, please read the chapter The Business Case for Agility

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.

 For more information, please read the chapter FLow for Enterprise Transformation (FLEX)

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.

 For more information, please read 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.

 For more information, please read 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.

 For more information, please read 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.

 For more information, please read the chapter FLEX solutions

FLEX and the Value Stream

Lean solutions are based on the realization of value and attending to the value stream to enhance one’s ability to do it. This chapter represents FLEX as a value stream.

 For more information, please read the chapter FLEX and the Value Stream

Lean Practices

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.

For more information, please read 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.

 For more information, please read the chapter Lean-Agile Product Management

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.

 For more information, please read 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.

 For more information, please read 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.

Teams

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.

 This is included in another book, Lean-Agile at the Team: A Lean Approach to Scrum and Kanban

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.

 For more information, please read the paper Northwestern Mutual Case Study: A SAFe Implementation Retrospection. This gives an example of how shared services can be managed in a SAFe implementation. 

For more information, please read the chapter Shared Services

DevOps

Organization-wide

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 (free, but registration necessary).

Visibility

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

For more information, please read the chapter Create Visibility

Dependency management, collaboration and planning at small-scale

When development organizations are large and not able to deliver to delivering software on a frequent basis, a full two-day planning event that decides what to work on for the next 2-3 months may make sense. But at small scale, doing this is far from Agile. This article describes different ways of running planning events. The following methods are one’s that we’ve seen work really well in the situations discussed. They are given in approximate order of being more desirable.  The key is to try what appears to be best and then adjust as you learn.

For more information, please read the chapter Dependency Management, Collaboration and Planning at Small-Scale. 

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.

For more information, please read the chapter Reorganizing the talent

The relationship between visualization and reorganization.

This chapter puts the concepts of visibility and reorganization into context with each other.  An advantage of using Lean Thinking behind both Scrum and Kanban is that both tend to ignore one or the other in their own manner. Scrum prescribes reorganization into cross-functional teams while LKU Kanban says reorganization is “orthogonal to Kanban” most likely because LKU Kanban is based more on theory of constraints which does not focus on reorganization

For more information, please read the chapter The Relationship Between Visualization and Reorganization

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.

  For more information, please see the Product Manager Reading path

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.

  For more information, please see the Technology Delivery Manager Reading Path

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.

  For more information, please see the Application Development Manager Reading Path

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.

 For more information, please read the chapter Leadership and Management

Technical Agility

Emergent Architecture

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

 For more information, please read the chapter Emergent Architecture

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.

 For more information, please read the chapter Test-First at the Team

Getting started

Improving your company’s culture

Culture eats strategy for lunch.

Agile is intended to create a new culture.  Many agilists talk about being Agile instead of doing Agile. The challenge is that it is difficult to change one’s being.  While trust and respect is a key value of Agile, it should be a key value for every approach. The question isn’t if trust and respect is a good idea, it’s a question of how do you create it if the culture isn’t already demonstrating it. This chapter discusses how cultures are a result of management systems in an organization and how to change both the management system and thereby the culture of an organization.

For more information, please read the chapter Improving your company’s culture

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.

 For more information, please read the chapter The Guardrails.

How people learn

Before beginning an adoption or transformation it is important to understand how people learn and how organizations change.  While on one hand many people like 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.

 For more information, please read 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.

For more information, please read 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.

 For more information, please read the chapter Roadmaps for Discovery and the Rollout.  

 Improvement

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.

 For more information, please read 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.

 For more information, please read the chapter Scorecards as Roadmaps

Small to Large-Scale Support System

Coming soon.

Miscellaneous

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.

 Please read the chapter A Lightweight Lean Approach to Agile at Mid-scale

Adopting SAFe at small to mid-scale overview

SAFe was designed for large organizations. Essential SAFe is intended to be used by programs within a large organization. This chapter discusses provides an overview how to adopt SAFe at small to mid- scale by using just what you need and adding some concepts from FLEX.

 Please read the chapter Adopting SAFe at Small to Mid-Scale Overview.

Adopting SAFe at small to mid-scale in depth

SAFe was designed for large organizations. Essential SAFe is intended to be used by programs within a large organization. This chapter discusses provides an overview how to adopt SAFe at small to mid- scale by using just what you need and adding some concepts from FLEX.

 Please read the chapter Adopting SAFe at Small to Mid-Scale Overview.

Resources related to Business Agility

A Primer on Emergent Design (Article)
Acceptance Test-Driven Development (Article)
Adopting SAFe® at Small to Mid-Scale In Depth (Article)
An Agile Parable (Article)
An Introduction to Lean-Agile Software Development (Article)
Cost of Delay (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 (Article)
Guardrails for Leadership and Management (Article)
Guardrails for the Team and Agile Coach (Scrum/Kanban Master) (Article)
How People Learn (Article)
How to Use Scrum in Mid to Large Scale Organizations (Article)
Improving Your Company's Culture (Article)
Lean Portfolio Management (Article)
Lean-Agile Product Management (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 and How It Can Be Applied to Frameworks and Methods (Article)
Technology Delivery Manager (Article)
Test-First at the Team (Article)
The Business Case for Agility (Article)
The Essence of Lean Thinking (Article)
The Relationship Between Visualization and Reorganization (Article)
The Software World Is Not Like the Physical World and What That Means (Article)
Using the Essence of SAFe at Small to Mid-Scale (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)