Lean Business Agility Framework

Lean Business Agility Framework™
Contact Us:
210.399.4240
[email protected]
© Copyright 2014 Enfocus Solutions Inc. Enfocus Requirements July 2014 V3
Suite™ is a trademark of Enfocus Solutions Inc. All Rights Reserved. www.EnfocusSolutions.com
Lean Business Agility Framework
www.EnfocusSolutions.com
Table of Contents
ppIntroduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
ppLean Business Agility Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
ppStrategy.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
ppPortfolio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
ppProgram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
ppTeam.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
ppBusiness Change.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
ppGetting Started.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved.

Business agility is more important now than ever, according to a recent report by Forrester
Research. In the report, they define business agility as “the quality that allows an enterprise
to embrace market and operational changes as a matter of routine.” As Forrester astutely
points out, seventy percent of the companies that existed on the Fortune 1000 list ten years
ago are no longer in service—the number one cause being incapable of adapting to change.
Companies face constant change and threats triggered by market and technology shifts.
In the complex business world that we operate in today, companies have to be able to
adapt rapidly and cost efficiently to the constant changes in the environment and customer
behavior.
IT is increasingly changing the way customers receive value, both directly through IT-
enabled products and services, and indirectly through more efficient product/service
development, production and delivery, and customer support. Delivering superior
customer value is the true purpose of the enterprise and everyone in it. Yet in survey after
survey, the majority of business people report that IT does not understand their business,
understand customer needs, or deliver value proportional to the investment made in IT.
Frequent complaints include that the IT organization is slow to respond, engages in projects
that rarely finish successfully or on time, creates systems with excessive complexity that
are difficult to use and maintain, and is unable to keep up with the rapid pace of business
change. These surveys repeatedly show that executives are often “baffled, frustrated, and
even angered by their IT organizations.”
In response, many organizations have begun to adopt agile methods for software or
product development. Agile methods have helped organizations deliver more rapidly,
increase customer satisfaction, and improve quality. However, agile development
alone does not make the enterprise agile. An agile business must be able to make rapid
changes that affect people, processes, data, technology, and rules to support threats and
opportunities in the market.

The Lean Business Agility Framework was developed by Enfocus Solutions to help
organizations visualize what is needed to transform to an agile enterprise. The framework
incorporates current trends and integrates various methods from sources such as the
Scaled Agile Framework®, ITIL®, Lean Thinking, and Lean Startup® into an integrated
approach for moving to business agility. The framework is intended to serve only as a
guide and requires an organization to selectively choose the methods that best fit their
organization based on their level of maturity and culture. This is best done by defining a
vision of what lean business agility is for your organization, preparing a roadmap of how to
get there, and conducting a series of change experiments to validate that you are on the
right path.
© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 1

Organizations that face any of the following challenges will find the framework useful in the
move to business agility:
Want
to adopt lean or agile but do not know where to start
Want
to align IT with the business by defining value streams and related services
Need
new methods to support organizational change and support lean and agile
development practices
Have
already implemented an IT Service Catalog for infrastructure services but now
want to provide end-to-end services to the business using best practice ITSM processes
Implemented
agile successfully at the team level but are having difficulty migrating to
the enterprise
Have
rigid service management processes for change and release management and are
having a difficult time adjusting them to support rapid agile release cycles
Have
rigid portfolio and project management practices and are having a difficult time
letting go of rigid stage gates and review and approval processes
The Scaled Agile Framework® (SAFe®) is an excellent framework for software development
and delivery. Basic SAFe® concepts are fully incorporated into the Lean Business Agility
Framework. However, it provides little in the areas of understanding the customer
need (Discovery) and making necessary business changes to support the new software
functionality. The Lean Business Agility Framework takes the three levels from SAFe®
and front-ends them with a Strategy Level and back-ends the SAFe® levels with Business
Change. In total, there are five levels in the Lean Business Agility Framework:
Strategy

Portfolio

Program

Team

Business
Change
All of these levels are explained in the following pages.

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. www.EnfocusSolutions.com
Customer Development Service Portfolio Service Design Value Stream Collaborative

Value Stream
Management Mapping Business Architecture
Business Technical
Service Strategy
Owner
Service Service
Service SDP SDP People Process

Owner Participatory Design
Service Launch Utility Current State
Management Improve Warranty Future State
Process Retire Customer Experience Transformation Plan Technology Data Rules
Owner Hypothesis and Assumptions Service Delivery Model Outcome Based Services Lean Value Streams Reusable Knowledge
Innovation Management Impacts, Gaps, and Risks Lean Budgeting and Accounting Value Flow Management
Business
Hypothesis and Assumptions Managing Flow of Value and
Epic Epic Realization of Benefits
Portfolio
Owner
Architecture
Epic People Process
Portfolio
Enterprise Epic Value Stream Lean-Agile Innovation
Management Transformation Manage Reduce Measure
Architect
Backlog
Epic
Technology Data Rules Accounting Budgeting Accounting Flow Waste Performance
Address Real Problem or Need Understand Impacts. Gaps & Risks Business and Customer Outcomes Manage Flow
Product Discovery PDIA - Plan-Do-Inspect-Adapt Release Planning and Management

Agile Release Train
Business
Feature Feature Release
Owner
Management
Program
Customer & Need Hypothesis &

MVPs/Experiments
Assumptions
Architecture Shared DevOps UX Devops RTE
Heuristics
Business Feature
Product Sponsor Bundle

Bundle Bundle
Bundle Bundle
Bundle
Feature
Management Backlog Change Learning Pivots
Experiment
Eliminate Waste Validate Before Building Deliver on Demand
Agile Product Development

Product Bundle Product Sprint 1 Sprint 2 Sprint 3 Sprint 4 HIP Sprint
Owner Dev Team Backlog
Team
Bundle Sprint 1 Sprint 2 Sprint 3 Sprint 4 HIP Sprint

Agile Scrum
Development Dev Team Product
Master Backlog
Team
Bundle Sprint 1 Sprint 2 Sprint 3 Sprint 4 HIP Sprint
Developers & Outsourced Product

Testers Continuous Verification Team Visualize Workflow Backlog Limit WIP Develop on Cadence
Lean Change Canvas Negotiated Changes Kanban Management Validated Learning

Bundle Plan-Do-Inspect-Adapt
Business Change
Product
Backlog
Change Team
People Process Conduct
Bundle Experiments
Product Check
Backlog Technology Data Rules Learn Performance
System Team
Transparency Change Experiments Continuous Customer Engagement Validated Learning
Strategy
Customer Development Key Principles
For every enterprise it is vital to know Hypotheses
and Assumptions
Manage
Service Portfolio
1. Who are our customers, and
Outcome-Based
Services
2. What do the customers value, need, Lean
Value Streams
or want?
Reusable
Knowledge
Answering these simple questions defines the
purpose of the organization and can lead everyone within the organization on a journey of
learning and discovery. Obtaining answers for these questions often produces unexpected
insights about our customers and what they really want from us. These insights are needed
to guide transformative strategy.
In the book The Entrepeneur’s Guide to Customer Development, author Steve Blank
describes Customer Development as a four-step framework to discover and validate that
you have identified the market for your product, built the right product features that solve
customers’ needs, tested the correct methods for acquiring and converting customers, and
deployed the right resources to scale the business.
Customer Customer
Discovery Validation
Pivot

Service Portfolio Management

Central to answering the questions above is defining what services our customers expect
from us and what they are willing to pay for the services we provide. ITIL® defines the
service portfolio as all services that a service provider provides to its customers along with
the business value that the service provides.
According to ITIL: Service Strategy, service portfolio management is a dynamic method

for controlling service management investments throughout the enterprise and actively
managing their value. It involves processes for creating new services, enhancing existing
service offerings, and retiring services that no longer meet customer needs. ITIL: Service
Strategy describes the objective of service portfolio management as providing the answer
to the following questions:
Why
should customers buy our service?
Why
should they buy this service from us?
What
features and components do customers want and are willing to pay for?
What
is the demand for the service?
What
are customers willing to pay for our service?
What
resources are needed to provide the service?
An efficient Service Delivery Model is key for an agile enterprise. The Service Delivery
Model defines how demand and supply are managed for a group of services in the service
portfolio. The Service Design Model addresses the following demand functions:
How
are services ordered
How
are customer relationships managed
How
are customer needs and expected outcomes identified
How
are service enhanced and new innovations introduced
Also, the Service Design Model addresses the following supply functions:
How
is the service delivered
How
suppliers are managed
How
service problems and incidents are managed
How
is service performance measured
How
are service enhancements developed and delivered
Service Design
According to ITIL: Service Design, service design is the activity of planning and organizing
people, processes, technology, communication and material components of a service to
improve its quality and the interaction between service provider and customers. Service
design focuses on understanding the customer needs and designing a service that is user-
friendly, competitive and produces the outcomes the customer wants.

Value Stream Mapping

It is important to define how we discover, build, deliver, support, and improve the product
or service that we offer to our customers. In Lean terms, this process is called a value
stream. As the name implies, it relates to the flow of actions required to bring a product
or service from concept to launch, from order to delivery, and from service request to
customer satisfaction.
In most organizations, no one person can describe the series of events that takes place to
transform a customer request into a product or service (i.e., the value stream). This lack of
understanding about how work flows in delivering value to the customer is a fundamental
problem that results in poor performance and poor business decisions.
Value stream maps are powerful tools in visualizing and simplifying how work gets done at
a macro level in order to make better and faster strategic improvement decisions. Value
stream maps are also useful for visualizing how IT services enable the delivery of value to
customers. Value stream maps often reveal disconnects, redundancies, and unnecessary
complications that otherwise aren’t understood by everyone across the organization. The
value stream below shows the value stream for student enrollment at a university.

Portfolio
Innovation Management Key Principles
According to Lance Bettencourt in the book Address
Real Problem or Need
Service Innovation, most organizations fail to Understand
Impacts, Gaps, and
distinguish between service innovation and Risks
service development. Bettencourt describes Business
and Customer
service innovation as the process of devising Outcomes
a new or improved service concept that
Manage
Flow
satisfies the customer’s unmet needs. Service
development, in contrast, occurs once a service
concept has been devised and refers to all the
activities involved in bringing that concept to market.
According to Bettencourt in Service Innovation, the secret of true service innovation is to
shift the focus away from the solution and back to the customer. The primary goal of service
innovation is to help customers get their jobs done better or faster. Most companies,
unfortunately, do not understand customer needs or how to uncover them. Bettencourt
writes that without proper customer inputs, companies are likely to end up with
incremental “me-too” service improvements, high service failure rates, general confusion
about what new services to offer, and poor execution due to cross-functional misalignment.
By overemphasizing the unique characteristics of services, service innovation has fallen
into a trap which, according to Bettencourt, has plagued product innovation for decades:
capturing requirements on the solution rather than customer needs.
The end result of innovation management is to define hypotheses and assumptions
expressed in the form of Epics, which will go through a number of discovery and
learning experiments and ultimately get developed and deployed if the hypotheses and
assumptions hold true. The goal is to deliver what customers truly need as quickly as
possible. The goal of portfolio management is to chose the Epics that provide the highest
value to the customer and the business.
Impacts, Gaps, and Risks

After an Epic has been defined, it is important to understand the impacts, gaps, and risks
for developing a solution and transitioning from the current state to the future state.
Impacts describe what needs to change. Gaps define the extent of the change due to
moving from a current to a future state. Risks describe what could go wrong when making
the change. Understanding the impacts, gaps, and risks is critical for successfully deploying
new software to the enterprise. Impacts, gaps, and risks are defined for the following areas:
People

Process

Technology

Data

Rules


Lean Budgeting and Accounting

Transparency is essential for Lean, but Lean results are often hidden behind the mask of
traditional accounting, which dilutes the benefits of a Lean implementation. When your
organization opts to go Agile and Lean, it’s important to provide your accountants with
Lean tools that align with the Lean mission. Changes are needed in the following areas:
Value
Stream Accounting—A recently evolved management accounting model,
Value-Stream Accounting, sometimes referred to as Lean Accounting, has potential for
providing valuable information in a format that encompasses revenues and costs as
they relate to value streams within an organization. This approach has the advantage of
tying accounting information to lean management concepts and has proven effective in
both for-profit and non-profit environments.
Innovation
Accounting—Eric Ries coined the term Innovation Accounting in his book,
The Lean Startup. One of the biggest challenges for product managers is determining
whether their product development efforts are leading to real progress. Ries reminds
us that if we’re building something that nobody wants, it doesn’t much matter if we’re
doing it on time and on budget. Innovation Accounting is a quantitative approach
that allows us to see whether our Lean implementation is providing positive results.
According to Ries, Innovation Accounting enables startups to prove objectively that
they are learning how to grow a sustainable business. Innovation Accounting involves
creating a quantitative financial model from the assumptions discussed. As Ries points
out in The Lean Startup, every business plan has some kind of model associated with it,
even if it’s written on the back of a napkin. The model provides assumptions about the
business’ successes in the future.
Agile-Lean
Budgeting—In the past, budgets were prepared for projects and controlled
at the project level. We now must learn to budget at other levels such as Agile Release
Trains, Value Streams, Teams, Services, or Epics. This looks like only a small change, but
can actually be quite significant when determining what is capital or operating expenses
and other issues.
Value Flow Management

The ability to respond to customer needs is an important objective in agile and lean
software development. To achieve this goial, it is important to have a continuous and
smooth Flow that rapidly delivers value to customers.
Manage
Flow—According to Donald Reinersen in the book The Principles of Product
Development Flow: Second Generation Lean Product Development, “Today’s product
development orthodoxy is broken. What’s wrong? Companies are pursuing the wrong
goals. They maximize capacity utilization, and wonder why cycle times are so long. They
strive to conform to plan, and wonder why new obstacles constantly emerge. They try
to eliminate variability, and wonder why innovation disappears. They carefully break
processes into phases and gates, and wonder why things slow down instead of speeding
up. Ironically, each of these actions actually hurts more than it helps.”

Flow is an essential ingredient of Lean. The goal of Flow is to manage the flow of work
to deliver value to the customer as quick as possible. According to Reinersen, in product
development, Flow is negatively impacted by the invisible and unmeasured queues that
undermine all aspects of product development performance. Allowing work to pile up
lengthens cycle time. At the same time, those piles of idle work delay vital feedback
and destroy process efficiency. According to Reinersen, Ninety-eight percent of product
developers neither measure nor control their queues. In designing efficient Flow, it is
important to consider the following:
"" Manage data instead of paper; paper inherently causes delays

"" Make Work Visible
"" Manage Queues
"" Keep Batch Sizes Small
"" Manage WIP Constraints
"" Design Fast Feedback Loops
"" Decentralize Control
Reduce
Waste—For most organizations, there is tremendous waste in the software
development process. Eliminating this waste can result in much faster cycle times and
higher delivery of value to the customers. According to Mary and Tom Poppendieck,
there are seven key wastes in software development:
"" Extra Features

"" Handoffs
"" Defects
"" Technical Debt
"" Work-in-Process
"" Task Switching
"" Delays
Measure
Performance—Metrics are key part of both Lean and Agile. The goal is to have
the right number of the right metrics.

Collaborative Business Architecture

Business architecture is gaining recognition as an essential capability enabling businesses
to address major challenges ranging from M&As to the reversal of customer attrition to
entering new markets. The business architecture allows a business to establish a common
vocabulary, shared vision, and degree of transparency that is needed to support agility in a
rapidly changing environment.
Enterprises have become more complex; sometimes making a simple change in a

department can have significant impacts on downstream processes. Systems have become
highly integrated and often making a change in one application can cause problems in
other systems. Business architecture is needed to assess these impacts and manage
risks. Serious problems can occur when teams are unaware of business and architectural
impacts while building a solution. Non-functional requirements often get left behind or
aren’t structured properly. It is highly risky to leave architectural decisions in the hands
of the developers and people implementing the system who might not have knowledge
of the impacts on other systems and business processes or a high-level view of where the
architecture needs to go to support the business strategy. These problems are mitigated
when collaborative business architecture is used and is available to the business and team
members developing the solution.
Business architecture began as a core element of enterprise architecture. The early

practitioners were largely IT enterprise architects. Today, business architecture is rapidly
becoming a business-focused and business-managed initiative. For most organizations, the
focus has shifted from technology and efficiency to strategy, customer engagement, and
business effectiveness. The goal for many organizations is to have business architecture
fully integrated into planning, portfolio management, business analysis, and all aspects of
business transformation. The business architecture should be deployed and leveraged on
all projects. However, to make this happen, organizations can no longer make the business
architecture a back-room exercise available to only a select few. The business architecture
must be transparent and available to development and business change teams. The
business architecture should be linked to business strategy and collaboratively maintained
by the business.

Program
Discovery
Agile has delivered increased customer Key Principles
satisfaction and higher quality for most Eliminate Waste

companies but has not resulted in cost savings.
Validate Before Build

Agile has not resulted in cost savings because
requirements are often developed using code Deliver on Demand

instead of using more cost effective methods such

as prototypes. According to a recent Voke brief,
the practice of analyzing and refining requirements in source code is an expensive practice
and could lead to significant schedule delays and higher costs.
According to Standish Group research, 67% of Features are rarely or never used. Better
validation and prioritization methods can have a significant impact on project and ongoing
maintenance costs. Many needs are not validated when placing stories in the backlog.
Writing code to validate needs is very expensive.
Discovery is the heart of product management and business analysis. It requires gaining an
understanding of the customer and their needs and determining what features will satisfy
those needs. It involves considering various options and choosing the set of features that
will produce the outcomes the customer needs. The combination of discovery and agile
product management is often referred to as dual-track agile, as shown in the diagram
below.
Discovery Track
Discover business and customer needs, and generate
validated product backlog items.
Delivery Track
Develop releasable software based on validated
backlog items.

PDIA: Plan-Do-Inspect-Adapt
Discovering and developing features is done in several iterations and usually follows a cycle.
In Lean, this cycle is often referred to as PDCA (Plan - Do - Check - Act), or the Demming
cycle. The Lean Startup uses a similar cycle called Build-Measure-Learn. The Scaled Agile
Framework simply uses Inspect and Adapt. Enfocus Solutions refers to this cycle is Plan-Do-
Inspect-Adapt. This cycle is designed for learning and is used for:
A
model for continuous improvement
Developing
a new or improved design of a process, product, or service
Defining
a business process or repetitive workflow
Planning data collection and analysis in order to verify and prioritize problems or root causes

Implementing
organizational change
Release Planning and Management
The Scaled Agile Framework® focuses on the development of large scale, complex system
and software solutions. But the goal of SAFe® isn’t to just to develop working software;
it is to continuously define, develop, validate, deploy, and support the software for the
customer. This allows the customer to receive the benefits of our latest innovations: new
features, increased quality, and enhanced performance. A constant stream of delivered
value is the goal of every Agile Release Train and value stream.
Prior to agile, releases were usually predefined by a set of requirements documents most
often consisting of a Business Requirements Document (BRD), Systems Requirements
Specifications, and a System Design Document, which collectively defined the functionality
for the release. In most situations, there was a single “big bang” release that happened at
the end of the project. In agile, this approach differs significantly as the goal is to deliver
a continuous stream of value to the customer throughout many releases as the software
is developed and made ready for release. In agile, the release question becomes, “when
do we have sufficient new functionality (the right batch size, for us and our customer) to
warrant release?” This question is answered not once, but continuously. That’s what creates
the continuous flow of value.
Many organizations have adopted Release and Deployment processes based on ITIL®.
These processes often need to be redesigned to support agile development and release
management.

Team
Agile Product Development
Agile development provides opportunities to Key Principles
assess progress throughout the development Continuous Verification

lifecycle. Assessments are performed alongside Visualize Workflow

regular cadences of work, known as Sprints
or iterations. At the end of each iteration, Limit WIP

teams present a potentially shippable product Develop on Cadence

increment. According to Laszlo Szalvay at

AgileMethodology.org, by focusing on the
repetition of abbreviated work cycles as well as the functional product they yield, agile
methodology is described as “iterative” and “incremental.” In waterfall, development
teams only have one chance to get each aspect of a project right. In an agile paradigm,
every aspect of development — requirements, design, etc. — is continually revisited. When
a team stops and re-evaluates the direction of a project every two weeks, there’s time to
steer it in another direction.
This “inspect-and-adapt” approach to development improves quality and reduces time

to market. Because teams can develop software at the same time they’re gathering
requirements, “analysis paralysis” is less likely to impede a team from making progress.
And because a team’s work cycle is limited to two weeks, stakeholders have recurring
opportunities to calibrate releases for success in the real world.
Scrum is the most popular agile method due to its simplicity and flexibility. However, many
organizations that claim to be doing Scrum, aren’t doing anything close to Scrum’s real
definition. According to the ScrumAlliance.org, Scrum emphasizes empirical feedback,
team self management, and striving to build properly tested product increments within
short iterations. Doing Scrum as it’s actually defined often conflicts with the existing culture
of non-Agile organizations.
In Scrum, there are only three roles: Product Owner, Team, and Scrum Master. Developers
and testers are part of the Scrum Team. The responsibilities of the traditional project
manager and business analysis roles are split up among these three Scrum roles. The
Scrum process consists of five meetings:
Backlog
Grooming (aka Backlog Refinement),
Sprint
Planning,
Daily
Scrum (aka 15-minute standup),
the
Sprint Review Meeting, and the
Sprint
Retrospective Meeting.

Business Change
Lean Change Canvas
The Lean Change Method was developed by Jeff Key Principles
Anderson and is used by agile change agents to Transparency
facilitate organizational change in a lean agile Change Experiments
environment. Switching to agile is a disruptive
paradigm shift for most organizations as they
Continuous Customer
move from a traditional organization focused Engagement
on command and control to a lean and agile Validated Learning
organization focused on enabling learning
through speed and self-organization. With the
Lean Change method, we still rely on change agents and change stakeholders to manage
change, but we use a lean approach to do so. Using the Lean Change method, we follow an
approach that is based on learning, co-creation, and experimentation. We maximize the
input from the people on the ground who are being asked to change.
Using the Lean Change method, we generate models of the future using a holistic, visual
approach that emphasizes co-creation, prototyping, and re-creation. Similar to Lean Startup,
which uses either the Lean Canvas or Business Model Canvas to document the plan, the
Lean Change Method uses the Lean Change Canvas for documenting the change plan. The
Lean Change Canvas is an informal plan on a single page which lays out many of the “static”
elements found in Kotter’s Eight Steps of Change lifecycle. The Lean Change method uses
the Change Canvas in two ways: a Minimum Viable Change (MVC) Canvas is used to describe
a small incremental change, one that impacts a limited number of employees, while a
Transformation Canvas describes an organizational transformation initiative.
Canvanizer.com

Negotiated Changes
According to Anderson in The Lean Change Method, the purpose of a change management
program is to try to help an organization improve business outcomes. To start, we define
a target state and plan a set of change actions. Many of the upfront choices that we are
faced with concerning the expected change are really just assumptions. As Anderson writes,
when we execute our change plan, we continually uncover new information about business
value, existing capability, current culture, workload, and a variety of other facts. This new
information requires us to constantly rethink the validity of our assumptions.
Traditional change management methods make it difficult to ensure that the change
plan keeps up with the organization’s continued learning. Usually, a major incident
must occur before change is considered. According to Anderson, organizations end
up with a change that does not provide the intended value. Using the Lean Change
Method, changes are negotiated with stakeholders who will be impacted by the change
and assumptions are tested by defining Minimal Viable Changes (MVCs) and tested
through a series of Improvement Experiments.
Kanban Management
We’ve talked previously about how Improvement Experiments are used to validate different
aspects of a Minimum Viable Change. According to Anderson in The Lean Change Method,
as change recipients gain experience in lean and agile methods, they start to evaluate
Improvement Experiments against performance metrics, which is why many organizations
have started following Kanban best practices. Anderson writes that Kanban provides a
rich set of metrics such as leadtime, throughput, and failure intake can be analyzed using
statistical process control or cumulative flow diagrams.
Validated Learning
In the Lean Change Method, Minimal Viable Changes are introduced to the organization
using a validated change lifecycle. The Validated Change Lifecycle integrates Kotter’s
Eight Steps with the Meta-Iteration Lifecycle Pattern from the book, Running Lean: Iterate
from Plan A to a Plan that Works by Ash Maurya. Using this lifecycle, Minimum Viable
Changes are defined and validated according to a specific sequence, as shown in the
diagram below.
Agree on Negotiate Validate Verify

Change the Change Behavior Performance

Even though the Lean Change Method was primarily designed for organizational change,
the same concepts can also be applied to other areas of change, such as:
Data

Business
Processes
Technology

Business
Rules
Getting Started
Many organizations view business agility as essential to survival. Others view Lean agile
as necessary to achieve better business outcomes, which is often phrased in sentences
such as:
“We
need to deliver more value-driven services to our customers.”
“We
need to offer faster and more responsive services.”
“We
need to reduce our costs and become more efficient.”
Transforming an organization to Lean agile is not easy. Agile often involves rethinking the
entire organization, including people, processes, and technology. IT organizations need to
move to self-organizing teams, but this is difficult as most IT departments operate more
like a maze of functional silos. This can almost seem like an insurmountable task, especially
when research has shown that over 70% of change initiatives have failed. However, there
are ways to mitigate this risk and successfully transform the organization to Lean agile.
The first recommendation is to use lean agile methods to manage the change—using old
organizational change methods that only have a 30% success rate for waterfall projects is
certainly a recipe for failure.
Possibly the best approach is to treat the agile transformation as what Eric Ries calls a Lean
Startup. Lean Startups operate in a world of uncertainty mitigating product, customer, and
market risk. Organizational change operates in the world of uncertainty and risk. Mitigating
the following risk can certainly improve the chances for success:
Change
Risk—implementing a change that will solve business problems
Resistance
Risk—implementing an approach that will result in successful adoption
across the organization
Sustainability Risk—getting the right commitment necessary to achieve change benefits


Lean Change is a method developed by Jeff Anderson and Alexis Hui that applies Lean
Startup concepts to change management. The approach involves:
1. Using a Change Canvas to brainstorm the initial change model
2. Building a change plan consisting of small change experiments (MVCs)
3. Validating the experiments and making adjustments to reflect learning
Enfocus Solutions provides software and services to help organizations transform business
agility. We offer both strategic and implementation services. Our strategic services consist
of conducting an assessment of where you are at, developing a vision of where you want to
be, and then developing a roadmap of how to get there. We use the Lean Business Agility
Framework as a starting point for discussion to help assess an organization’s maturity and
desired direction.
Our implementation services generally involve defining a set of change experiments and
working with your organization through a series of learning cycles to adjust the practices to
your organization’s capabilities and culture. In performing our services, we work as a coach
and mentor to your teams and use our software to support collaboration and knowledge
management.
Acknowledgements
The Lean Business Agility Framework is based on leading practices from the following
sources:
The Scaled Agile Framework was developed by Dean Leffingwell.
This model of agile adoption has been elaborated primarily in
his books Agile Software Requirements: Lean Requirements for
Teams Programs and the Enterprise (2011) and Scaling Software
Agility: Best Practices for Large Enterprises (2007). The framework
has been successfully applied in programs of only 50-100 people,
and in enterprises employing thousands of software developers.
ITIL® is the most widely accepted best practice for IT Service

Management. ITIL® was originally developed by the UK
Government, but is now managed and supported by Axelos.
The Service Strategy manual provides instructions on how to
position and define services as strategic assets. The principles
described in the service strategy underpin the service lifecycle
with helpful policies and guidelines as well as processes in
the context of the lifecycle phases of service design, service
transition, service operation, and continual service improvement.

ITIL® is the most widely accepted best practice for IT Service

Management. ITIL® was originally developed by the UK
Government, but is now managed and supported by Axelos.
The Service Design manual provides guidelines for the design
and the development of services and service management
processes. The volume includes design principles and methods
for the realization of strategic goals in service portfolios and
service assets. However, the scope of service design is not
limited to new services. It also contains advice on necessary
changes and improvements to enhance or maintain the added
value of the services across the individual lifecycles, ensure their
continuity, achieve the service levels, and fulfill the compliance
requirements. Service design provides the organization with
valuable advice on the question of how to develop and acquire
capabilities for service management.
The Lean Change Method is licensed under a Creative Commons

Attribution-ShareAlike 3.0 Unported License to Jeff Anderson
and Alexis Hui, based on the work that can be found at http://
leanchangemethod.com.
The method is based on concepts from The Lean Startup and
Kotter’s eight-step lifecycle. The work provides excellent method
for effecting organizational change in a Lean agile environment.
The Lean Startup provides a scientific approach to creating and

managing startups and getting a desired product to customers’
hands faster. The Lean Startup method teaches you how to drive
a startup—how to steer, when to turn, and when to persevere—
and grow a business with maximum acceleration. It is a principled
approach to new product development. It is based on the
following principles:
Entrepreneurs
are everywhere
Entrepreneurship
is management
Validated
Learning
Innovation
Accounting
Build-Measure-Learn


This is an excellent book that is a guide on how to implement

the principles and practices of Steve Blank’s book, The Four
Steps to the Epiphany. Steve Blank published The Four Steps to the
Epiphany in 2005 not as a “traditional” business book, but as a
compilation of lecture notes for the business school classes he
taught at Stanford University and UC Berkeley. Blank’s book
lays out an actionable framework for starting and building new
startups, based on the insight that most startups fail because
they didn’t develop their market, not because they didn’t
develop their product. The Lean Startup is heavily based on
Blank’s work also.
Service Innovation is an outstanding piece of work by Lance

Bettencourt. The book is focused on the fact service innovation
must begin with the recognition that services are solutions
to customer needs. The book states “Services that provide
distinctive value to customers have more than three times the
success rate of me-too services. And services that clearly align
with customer needs achieve more than five times the success
rate of services that have a poor fit with customer needs. In
other words, successful service innovation begins with a proper
understanding of customer needs.”
Enfocus Solutions Inc. Contact Information

Contact us today to discuss how the software and services of Enfocus Solutions can help
implement the Lean Business Agility Framework in your organization.
Email: [email protected]
Phone: (210) 399-4240
Toll-free: (877) 253-0275

Lean Business Agility Framework

Uploaded by

Copyright:

Lean Business Agility Framework

Uploaded by

Document Information

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Lean Business Agility Framework

Uploaded by

Copyright:

Lean Business Agility Framework™

ppLean Business Agility Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved.

Lean Business Agility Framework

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 1

All of these levels are explained in the following pages.

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 2

Customer Development Service Portfolio Service Design Value Stream Collaborative

Service SDP SDP People Process

Product Discovery PDIA - Plan-Do-Inspect-Adapt Release Planning and Management

Customer & Need Hypothesis &

Product Sponsor Bundle

Agile Product Development

Bundle Sprint 1 Sprint 2 Sprint 3 Sprint 4 HIP Sprint

Developers & Outsourced Product

Lean Change Canvas Negotiated Changes Kanban Management Validated Learning

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 4

Service Portfolio Management

According to ITIL: Service Strategy, service portfolio management is a dynamic method

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 5

Value Stream Mapping

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 6

Impacts, Gaps, and Risks

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 7

Lean Budgeting and Accounting

Value Flow Management

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 8

"" Manage data instead of paper; paper inherently causes delays

"" Extra Features

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 9

Collaborative Business Architecture

Enterprises have become more complex; sometimes making a simple change in a

Business architecture began as a core element of enterprise architecture. The early

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 10

instead of using more cost effective methods such

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 11

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 12

teams present a potentially shippable product Develop on Cadence

increment. According to Laszlo Szalvay at

This “inspect-and-adapt” approach to development improves quality and reduces time

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 13

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 14

Agree on Negotiate Validate Verify

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 15

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 16

1. Using a Change Canvas to brainstorm the initial change model

2. Building a change plan consisting of small change experiments (MVCs)

3. Validating the experiments and making adjustments to reflect learning

ITIL® is the most widely accepted best practice for IT Service

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 17

ITIL® is the most widely accepted best practice for IT Service

The Lean Change Method is licensed under a Creative Commons

The Lean Startup provides a scientific approach to creating and

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 18

This is an excellent book that is a guide on how to implement

Service Innovation is an outstanding piece of work by Lance

Enfocus Solutions Inc. Contact Information

Phone: (210) 399-4240

Toll-free: (877) 253-0275

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 19

You might also like