Lean Business Agility Framework™ - Enfocus Solutions · Lean Business Agility Framework opyrigt...

Lean Business Agility Framework™

July 2014 V3www.EnfocusSolutions.com

© Copyright 2014 Enfocus Solutions Inc. Enfocus Requirements Suite™ is a trademark of Enfocus Solutions Inc. All Rights Reserved.

Contact Us:[email protected]

Lean Business Agility Frameworkwww.EnfocusSolutions.com

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved.

Table of Contents

pp Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

pp Lean Business Agility Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

pp Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

pp Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

pp Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

pp Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

pp Business Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

pp Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16


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

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.

Lean Business Agility FrameworkThe 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.



Organizations that face any of the following challenges will find the framework useful in the move to business agility:

p� Want to adopt lean or agile but do not know where to startp� Want to align IT with the business by defining value streams and related servicesp� Need new methods to support organizational change and support lean and agile development practicesp� 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 processesp� Implemented agile successfully at the team level but are having difficulty migrating to the enterprisep� Have rigid service management processes for change and release management and are having a difficult time adjusting them to support rapid agile release cyclesp� 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:

p� Strategyp� Portfoliop� Programp� Teamp� Business Change

All of these levels are explained in the following pages.

PortfolioService Strategy

Business C

hangeProgram

BusinessService

TechnicalService

Service DesignService PortfolioManagement

Customer Development

LaunchImproveRetire

BusinessFeature

ArchitectureFeature

BusinessEpic

ArchitectureEpic

EpicBacklog

PDIA - Plan-Do-Inspect-Adapt

Innovation Management Impacts, Gaps, and Risks Value Flow Management

FeatureBacklog

Collaborative Business Architecture

Product Discovery

People Process

Data RulesTechnology

People Process


Release Planning and Management

CheckPerformanceLearn

Conduct Experiments

Bundle Bundle Bundle

DevOps UX Devops RTEShared

ProductManagement

Developers & Testers

ScrumMaster

ProductOwner

PortfolioManagement

ProductBacklog

Negotiated Changes

Sprint 1 Sprint 2 Sprint 3 Sprint 4 HIP Sprint

ProductBacklog


ProductBacklog


Bundle

Bundle

Bundle

Bundle

Bundle

System Team

Validate Before Building

Continuous Verification Develop on Cadence

Deliver on Demand

Outcome Based Services

ChangeExperiment

Change Experiments Validated Learning

Dev Team

Dev Team

OutsourcedTeam

ProductBacklog

ProductBacklog

Reusable Knowledge

MeasurePerformance

Reduce Waste

Hypothesis & Assumptions

Bundle Bundle Bundle

Agile Release Train

Agile Product Development

SDP SDP

Managing Flow of Value and Realization of Benefits

ServiceManagement

AgileDevelopment

Team

Kanban Management Validated Learning

Lean Value Streams

Lean Business Agility Framework

Continuous Customer Engagement

MVPs/ExperimentsCustomer & Need

Pivots

Heuristics

EpicOwner

FeatureOwner

BusinessSponsor

EnterpriseArchitect

ServiceOwner

ProcessOwner

Change Team

Understand Impacts. Gaps & Risks

Eliminate Waste

Hypothesis and Assumptions

Address Real Problem or Need

© Copyright 2014 Enfocus Solutions Inc. All Rights Reserved.

TransformationEpic

UtilityWarranty

Customer Experience

Transparency

Limit WIPVisualize Workflow

Manage Flow

Value StreamMapping

Participatory DesignCurrent StateFuture State

Transformation PlanService Delivery Model

Learning

People Process


Team

Value StreamOwner

ReleaseManagement

Lean Budgeting and Accounting

Value StreamAccounting

Lean-AgileBudgeting

Innovation Accounting

Business and Customer Outcomes

Lean Change Canvas

Hypothesis and Assumptions

ManageFlow

Plan-Do-Inspect-Adapt




Strategy

Customer Development

For every enterprise it is vital to know

1. Who are our customers, and

2. What do the customers value, need, or want?

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.

Key Principlesp� Hypotheses and Assumptionsp� Manage Service Portfoliop� Outcome-Based Servicesp� Lean Value Streamsp� Reusable Knowledge

Customer Discovery

Customer 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:

p� Why should customers buy our service?p� Why should they buy this service from us?p� What features and components do customers want and are willing to pay for?p� What is the demand for the service?p� What are customers willing to pay for our service?p� 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:

p� How are services orderedp� How are customer relationships managedp� How are customer needs and expected outcomes identifiedp� How are service enhanced and new innovations introduced

Also, the Service Design Model addresses the following supply functions:

p� How is the service deliveredp� How suppliers are managedp� How service problems and incidents are managedp� How is service performance measuredp� 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

According to Lance Bettencourt in the book Service Innovation, most organizations fail to distinguish between service innovation and service development. Bettencourt describes service innovation as the process of devising a new or improved service concept that 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:

p� Peoplep� Processp� Technologyp� Datap� Rules

Key Principlesp� Address Real Problem or Needp� Understand Impacts, Gaps, and Risksp� Business and Customer Outcomesp� Manage Flow



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:

p� 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.p� 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. p� 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.

p� 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:

p" Manage data instead of paper; paper inherently causes delaysp" Make Work Visiblep" Manage Queuesp" Keep Batch Sizes Smallp" Manage WIP Constraintsp" Design Fast Feedback Loopsp" Decentralize Control

p� 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:

p" Extra Featuresp" Handoffsp" Defectsp" Technical Debtp" Work-in-Processp" Task Switchingp" Delays

p� 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 satisfaction and higher quality for most companies but has not resulted in cost savings. Agile has not resulted in cost savings because requirements are often developed using code 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.

Key Principlesp� Eliminate Wastep� Validate Before Buildp� Deliver on Demand

Delivery TrackDevelop releasable software based on validated backlog items.

Discovery TrackDiscover business and customer needs, and generate validated product 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:

p� A model for continuous improvementp� Developing a new or improved design of a process, product, or servicep� Defining a business process or repetitive workflowp� Planning data collection and analysis in order to verify and prioritize problems or root causesp� 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 assess progress throughout the development lifecycle. Assessments are performed alongside regular cadences of work, known as Sprints or iterations. At the end of each iteration, teams present a potentially shippable product 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:

p� Backlog Grooming (aka Backlog Refinement),p� Sprint Planning, p� Daily Scrum (aka 15-minute standup), p� the Sprint Review Meeting, and the p� Sprint Retrospective Meeting.

Key Principlesp� Continuous Verificationp� Visualize Workflowp� Limit WIPp� Develop on Cadence



Business Change

Lean Change Canvas

The Lean Change Method was developed by Jeff Anderson and is used by agile change agents to facilitate organizational change in a lean agile environment. Switching to agile is a disruptive paradigm shift for most organizations as they move from a traditional organization focused on command and control to a lean and agile 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.

Key Principlesp� Transparencyp� Change Experimentsp� Continuous Customer Engagementp� Validated Learning

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 Change

Negotiate the Change

Validate Behavior

Verify 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:

p� Data p� Business Processesp� Technologyp� Business Rules

Getting StartedMany 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:

p� “We need to deliver more value-driven services to our customers.”p� “We need to offer faster and more responsive services.”p� “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:

p� Change Risk—implementing a change that will solve business problemsp� Resistance Risk—implementing an approach that will result in successful adoption across the organizationp� 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.

AcknowledgementsThe 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:

p� Entrepreneurs are everywherep� Entrepreneurship is managementp� Validated Learningp� Innovation Accountingp� 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 InformationContact 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™ - Enfocus Solutions · Lean Business Agility Framework opyrigt...

Documents

Transcript of Lean Business Agility Framework™ - Enfocus Solutions · Lean Business Agility Framework opyrigt...