Lean Principles for Agile Teams

Lean Principles for Agile WorkshopElizabeth Woodward, Lean and Agile StrategistFariz Saracevic, Agile Evangelist

Agenda Introduction: Status quo is not an option (5 min) A brief history of lean and agile (5 min) Lean principles

– Mura with Flow Exercise (60 min)– Break (10 min)– Muda with Value Stream Mapping Exercise (60 min)– Muri (10 min)– Kaizen (10 min)

An approach to self-optimizing team of teams (5 min) Summary (5 min)

2

INTRODUCTIONStatus quo is not an option

3

New Technologies Change What We Develop and How We Develop

4

Social

Cloud

Mobile

Internet of Things

Big Data

Requires Continuous Learning and Improvement,

Lean and Agile Methods

Many firms are underprepared for these rapid changes in technology, affecting their ability to be competitive

Mobile device proliferation

Collaboration across the ecosystem

Explosion of unstructured data

Cloud platforms and solutions

Intelligent–connected systems

Technology Trends Most Impacting Competitiveness

Organizations Underpreparedfor Technology Trends

Note: Survey respondents were allowed up to three selections

Source: “The Software Edge: How effective software development and delivery drives competitive advantage,” IBM Institute of Business Value, March 2013 5

The Challenge: Innovation, quality, speed in rapidly changing conditions

6

BRIEF HISTORY OF LEAN AND AGILEHighlights of a few key activities over the past decades

7

Brief History of Lean and Agile

HBRNew

New Product Development

Game

Monitor /

Optimize

Develop / Test

Release / Deploy

Plan / Measur

e

DevOpsContinuousInnovation,Feedback

and Improvements

8

Importance of principles and values

The Toyota story has beenintensively researched andpainstakingly documented,yet what really happens insidethe company remains amystery. Here’s new insightinto the unspoken rules thatgive Toyota its competitiveedge.

– HBR, Decoding the DNA of the Toyota Production System

Agile and lean transformations are culture

changes “Culture reflects the realities of people working together every day…

…a set of values, practices, and traditions that define who we are as a group.”

--Frances Hesselbeim

Work by Uwe Kils) http://www.ecoscope.com/iceberg/

9

http://en.wikipedia.org/wiki/User:Kils

http://www.ecoscope.com/iceberg/

Relationship between Agile and Lean Agile

Design build delivery focusLean

Process improvement focus

Objective To achieve faster and better software development and delivery

To improve processes by focusing on customer value and systematically identifying and removing waste

Principles Early and continuous delivery of working softwareWelcome frequent and late changes in requirement Strong collaboration between business and development teamFace-to-face conversationSustainable developmentSimplicity - the art of maximizing the amount of work not done

Eliminate WasteBuild Quality InDefer CommitmentDeliver FastFocus on LearningRespect PeopleOptimize the Whole

Agile and Lean are fully aligned and compatible methodologies with the common goal of increasing customer value and output quality while delivering results faster.

10 10

MURA MUDA MURI

斑無駄無理Toyota Production System’s Three Types of waste

11 11

Elimination of Uneveness Elimination of Waste Avoidance of the Unreasonable

12

ELIMINATING MURA (UNEVENESS)Improve flow through the system

斑

13

JIT Pull vs. Push

Empty unit or kanban authorizes work

DemandAuthorizes work

RawMaterial

InputFinished

Push PullAnticipate usage Focus on actual consumptionLarge batches Small batchesHigh inventory Reduced inventory

14

Reducing cycle time by reducing batch sizes

Cycle Time as a Function of Utilization and Batch Size*

0

5

10

15

20

25

30

35

40

45

10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Cycl

e Ti

me

(hou

rs)

Small Batches

Medium Batches

Large Batches

Utilization

Figure source : Implementing Lean Software Development

Agile planning—finer grained stories nearer in event horizon

Splitting stories into tasks for sprint planning

Recommendations for small tasks

Small batch size reduces cycle time

Large batch sizes increase variability

High utilization increases variability

Two ways to reduce cycle time:• Reduce work arriving• Create steady pace of service

15

WIP Constraints and Kanban “information radiator”Not started Development Testing Acceptance Done

Exit Criteria Exit Criteria Exit Criteria Exit Criteria Exit Criteria

A

BE

FI

H

G

J

C

How can this flow be improved?

16

Value of cross-functional teams

Toyota Production System:– One operator works across

multiple machines– Reduces handoffs– NOTE: One person may walk

their piece through multiple processes (not quite the same as a cross-functional team)

Agile cross-functional team: All skills required to complete the work.

Exercise: Improving flow

Experiments to demonstrate elimination of Mura.

45 min

17

18

5 Whys

WhyWhyWhyWhyWhy

Used to explore the cause and effect relationships underlying a particular problem

Taiichi Ohno: “…the basis of Toyota's scientific approach . . . by repeating why five times, the nature of the problem as well as its solution becomes clear."

19

ELIMINATING MUDA (WASTE)Ruthless elimination of 7 wastes in manufacturing

無駄

20

WAS

TES

71. Transportation 2. Inventory3. Motion 4. Waiting 5. Overproduction6. Over-processing7. Defects

無駄無駄

20

21

What is waste? A process adds value if it results in something customer will pay for. Waste is when more resources are consumed than are necessary to

produce what the customer wants.

Price = Cost + ProfitProfit = Price - Cost

無駄

22

In Software =Movement between systemsMovement between team members and handoffs

Transportation Moving products creates risk of damage, lost, and delay with no added value for which customer is willing to pay.

無駄

1

23

Provide teams with the tools they need. Open and integrated.

Open Lifecycle and Service Management Integration Platform

Continuous Delivery

Bridge Mainframe and Mobile Skills

Link Systems of Record to Systems

of Engagement

Team Members

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” – Agile Manifesto

24

Recommendation of face to face communication

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” – Principles of the Agile Manifesto

Strive for the Richest Communication Channel Possible

25

Transportation waste includes damage to and loss of information

Edward T. Hall (1959), a renowned social anthropologist, argued that in a normal conversation:

“More than 65 percent of social meaning occurs through the nonverbal channel.”

Nonverbal Communication

26

Use effective methods for distance communication and collaboration to reduce waste

1 •Conference phones and headsets

2 •Screen sharing

3 • Instant messenger

4 •Video conferencing

5 •Agile Project Management (Electronic Task board)

6 •Lifecycle Management

27

In Software =Delivering partially-completed capabilityNever-ending backlog

Inventory Inventory is raw materials, work-in-progress (WIP), or finished goods—capital outlay that has not produced income.

無駄

2

28

Delivering potentially shippable product every iteration No partially-completed work

accepted

Software delivered meet acceptance criteria

Software delivered meets the definition of done

2-4 weeks

24 hrs

ProductBacklog

SprintBacklog

Daily ScrumMeeting

Potentially ShippableProduct Increment

Sprint Goal

SprintPlanning

SprintReview

29

Features meet the “definition of done”

All Acceptance Criteria of the User Story are met Code meets general Coding Standard Refactoring Design Review Functional Tests pass Unit Tests cover >70% code Code Review Functional Tests Written and passed Functional tests added to regression suite User acceptance tests pass Performance tests pass Integration tests pass …

30

Prevent wasted backlog maintenance efforts

Will the team get to last item in this lifetime?

Effort to maintain extra backlog

Effort to create the extra backlog

31

In Software =Task switchingDeath marchThrowing software “over the wall”

Motion refers to the damage that the production process inflicts on the entity that creates the product (equipment or workers).

無駄

3

32

Cost of multi-tasking

Even brief mental blocks created by shifting

between tasks can cost as much as 40 % of someone's productive time. – David Meyer, University of Massachusettes

One project at a time Eliminate unimportant work

2-4 weeks

24 hrs

ProductBacklog

SprintBacklog

Daily ScrumMeeting


Sprint Goal

SprintPlanning

SprintReview

SprintReflection

33

Preventing a Death March“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. “*

*agilemanifesto.org

Use Sprint burndown to track progress

Collaborate with stakeholders to make adjustments as needed

Reduce amount of work taken into the Sprint to “get to done”

34

“Whole Team” to reduce waste related to motion

The Whole Team practice recommends having a team that includes people with all skills and functions needed for creating the product:

– Developers

– Testers

– Designers

– Technical writers

– Customers

– IT Operations…

35

In Software =Delays in delivery working software to customersBureaucracy—Decisions, approvalsElimination of blockers (inefficient tools, input, reviews)Waiting for feedback

Waiting Products that are not in transport or being processed, they are waiting.

無駄

4

36

Daily planning addresses blockers and inefficiencies

2-4 weeks

24 hrs

ProductBacklog

SprintBacklog

Daily ScrumMeeting


Sprint Goal

SprintPlanning

SprintReview

SprintReflection

37

Team identifies issues during Daily Standups (Daily Scrums)

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?

2. What will I do today to help the Development Team meet the Sprint Goal?

3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

38

Continuous feedback

Reviews of working software provide additional feedback and adaptation

2-4 weeks

24 hrs

ProductBacklog

SprintBacklog

Daily ScrumMeeting


Sprint Goal

SprintPlanning

SprintReview

SprintReflection

“Business people and developers must work together daily throughout the project.” – Agile Manifesto

39

In Software =Producing unnecessary featuresBacklog refinement based on horizon

Overproduction More product is produced than needed at that time. Produced by large batches. Leads to excess inventory.

無駄

5

40

Producing Unnecessary Features

Rarely or Never Used: 64%

Often or Always Used: 20%

Features and Functions Used in a Typical System

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

41

Agile work is done in “small bites” from an ordered backlog

“Simplicity--the art of maximizing the amount of work not done--is essential.” –Agile Manifesto 2-4 weeks

24 hrs

ProductBacklog

SprintBacklog

Daily ScrumMeeting


Sprint Goal

SprintPlanning

SprintReview

42

Agility and Simplicity

List Requirements

Write One Test

Run Test toMake Sure It

Fails Add or modify just enough code to make new test pass and all previous

tests pass

Refactor to eliminate code smells (e.g., duplicated

code)

Test Driven Development (TDD):Programming practice in which all

production code is written in response to a failing test.”

Test + Design

“Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won't be needed. If they write code that ultimately is not used, I will be paying for that code for the life of the system, which is typically longer than my professional life. If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain.”

-- Jeff Sutherland, CTO PatientKeeper

43

In Software =“Gold plating”Unnecessary testingExcessive audits and validation

Over-processing More work is done than is required by the customer (e.g. more precise, higher quality).

無駄

6

44

User Stories Agile PracticeReducing unused software through acceptance criteria

The product owner’s conditions of satisfaction:– Testable so that you have an easy, binary way of knowing whether a story is finished– Done or not done; no “partially finished” or “done except”

As a network administrator, I want to be able to apply policies to groups of network devices that require similar management so that I can reduce administrative efforts.

•Able to group resources by location•Able to group resources by vendor•Able to group resources by services offered•Able to apply a policy to a group of resources

Card ConfirmationConversation

44

45

Combinatorial Test Design (CTD) For a customer in the Insurance Industry

– The client had 15,000 tests, manually reduced to 6000 based on risk estimates– IBM modeled the claims adjudication process using CTD– – IBM identified 41 test cases to perform system test with better coverage

For a customer in the Telecommunication Industry– IBM reverse-engineered the model present in 117 hand-written test cases– Concluded that these tests could be replaced by 12 test cases

IBM internal – System recovery– The test team suggested ~50 tests– After holes were found and a model was created, there were ~7,800 tests– CTD suggested only 17– Out of the 17 tests, 14 revealed unknown defects– A total of 20 new defects identified– No more outages for over two years

46

Excessive audits and validation

Most enterprises embracing agile eventually adapt their business gating processes

Business validation processes often acquire excessive requirements over time

Reducing excess processing—IP example

Can the IP Law office execute the patenting process quickly enough?

Can the IP Law office work through non-disclosure agreements quickly enough?

47

48

In Software Cost of defects increases over timeTechnical debt carries additional costMissing requirementsIntegration and migration failures

Defects Poor quality increases costs which should not be passed on to the consumer and are taken as a loss.

無駄

7

49

Waterfall cost of defects found over time

50

Earlier defect detection with agile leads to less waste

Analysis

Design

Code

Test

Analysis

Design

Code

TestAnalysis

Design

Code

TestAnalysis

Design

Code

Test

Analysis

Design

Code

TestAnalysis

Design

Code

Test

Analysis

Design

Code

TestAnalysis

Design

Code

Test

51

Agile practice of continuous integration helps to find issues earlier.

52

Agile teams addressing technical debt (Example)

Agile team dedicated to new capability Agile team dedicated to technical debt

*Percentages vary based on circumstances

80%* 20%*

Example: Technical Debt Measures used at IBM

Note: Goals are either internal IBM statistics or industry benchmarks.

Metric Goal 2006 Measurement 2010 Measurement

Maintenance / Innovation 50/50 42% / 58% 31% / 69%

Time to Market (Major) 12 Months 18 + Months 12.5 Months

Customer Calls -5% YoY ~ 135,000 ~100,000 (-19% since 2009)

Customer Defect Arrivals -5% YoY ~ 6,900 ~2200

On Time Delivery 65% 47% 92%

Defect Backlog 3 Months 9+ Months 3 months

Enhancements Triaged 85% 3% 100%

Enhancements into Release 15% 1% 21%

Customer Sat Index 88% 83% 88%

Beta Defects Fixed Before GA 50% 3% 94%

Technical Debt ~ $10,000,000 ~ $6,400,000

53

53

54

IDENTIFYING WASTEValue Stream Mapping Method for

55

Value Stream Maps – Where did we waste the time?

Cycle Time– Average end-to-end process time

• From problem detection• To problem solution

Begins and ends with the customer*

Software Development Cycle Time– The speed at which a customer need is reliably

and repeatedly translated into deployed software.

Customer Request Customer Satisfied

Cycle Time

Enterprise agility requires coordination, communication and collaboration across the enterprise. SSE (hardware/software) has been pushing those boundaries.

Supply Chain

Enterprise

Organization

Portfolio

Program

Team + Stake-holder Collab

Product and Embedded Coverage

Common IT Coverage

IBM’s Intent

IT Example: Retail customer is targeting 24 hours from accepting new product to making web updates and adapting supply chain to fulfill request

SSE: Aerospace contractor is including manufacturers from supply chain early in requirements and design efforts Note: SSE is addressing complex lean and agile challenges that will eventually overlap with IT.

Lean concept of optimization of the whole – “whole” continues to expand.

56

57

devOps in SaaS – Common Definition Users

Auto-mation

Continuous Integration

Whole Team

GA ready functionality

Demos,feedback GA

1. Agile

Auto-mation


Whole Team


Demos,feedback GA

2. Agile -> Continuous Delivery

Auto-mation


Whole Team


Demos,feedback GA

3. Agile -> Continuous Delivery ContinuousDeployment

Dev/Ops Collaboration

Development Operations Development Operations

Spread of Agility across roles1. Development team2. Operations3. Customers/users4. Product management5. Marketing6. Sales7. Education/Enablement8. Services 9. Intellectual property10.Software supply chain11.Product supply chain

Supply Chain

Enterprise

Organization

Portfolio

Program

Team + Stake-holder Collab

Optimization of the whole with

expanding view of “whole”

Increasing communication and collaboration

58

59

Value Stream Map - Goals Goals of Value Stream Mapping

Be able to answer these questions– How quickly can you bring value to your

stakeholders?– Where does the time go?– What is the cost of batching your deliveries?– What is the fastest you could deliver / respond?– Did you really respond to your customer?

6060

Example Waterfall Value StreamCustomer tells of Feature Need Customer Gets Benefit

RequirementIdentified

ReqtsDB

ReqtReviewed

CandidateList

Review &Decision.“In Plan?”

DCRSelection?

MigrateApplications

InstallUpgrade

MfgTestingFV SVT IVT

Docs

TestPrep

DCUT

In Production

Avg Customer Request to ShipDev Time = 3 MonthsDev Waiting Time = 24 MonthsTotal Dev Time = 27 MonthsTotal Dev Efficiency = 13%

Avg Customer Request to BenefitDev/Cust Working Time = 15 MonthsWaiting Time = 24 MonthsTotal Customer Time = 39 MonthsOverall Customer Efficiency = 38%

1 hour 1 week 1 month

2 months9 months

1 week

1 hour1 day1 hour

2 months

3 months9 months

1 week

0

1 year1 day

1 day1 month7 months

Just for this feature

18 Monthcycle

61IBM Internal Use Only : With Thanks to Mary and Tom Poppendieck

Value Stream Example

value

23 - 33% Efficiency

1 week 1 day

1 hour

1 week ½ week

2-3 months to merge

waste2 weeks working together

How much is Value? 1 hour

123 hours Value

500-660 HoursTotal Cycle Time

1 hour

Require-ments Develop Test


QAMarketing

requests New Feature

Approval Require-ments Develop Test Deploy



Exercise: Value Stream MapsSelect a Process / Problem that is Relevant to you

– Decide when the clock starts (e.g.. customer has a need) and when it stops (need is filled).

Create a Value Stream Map– List / diagram the key steps to delivering customer value

( value add and waiting )– List the average time of each step

( value add and waiting )– If any step repeats, use the average number of repetitions

Calculate Process Cycle Efficiency*– Add up time of each step plus time between steps

= Total Cycle Time– Add up Value Added Time in each step– Process Efficiency = Value Added Time

Total Cycle Time

* George & Wilson, Conquering Complexity in Your Business 62

63

MURIAvoidance of the unreasonable

64

Applying lean Muri principles to agile development

Muri is avoided through:– Standardized work,

standardized conditions of output

– Work Flow, or logical directions to be taken

– Repeatable Process Steps and Machine Processes

Agile examples:– Agile frameworks– Test automation– Procedures for continuous

integration– Recommended practices– Varies according to what works

for the individual team– Definition of done

65

KAIZENContinuous Improvement

Relentless improvement, Learn through experiments

66

Kaizen:1. Set goals and provide any

necessary background.2. Review the current state and

develop a plan for improvements.3. Implement improvements.4. Review and fix what doesn’t

work.5. Report results and determine any

follow-up items.

2-4 weeks

24 hrs

ProductBacklog

SprintBacklog

Daily ScrumMeeting


Sprint Goal

SprintPlanning

SprintReview

Reflection

Standardized work is the basis for Kaizen

67

AN APPROACH TO SELF-OPTIMIZING TEAM OF TEAMSContinuously improving through shared learning while extending boundaries

IBM DevOps Reference Architecture for Agile Transformation

Discussion

LegacySystems

SW-Defined EnvironmentsMobile TransformationMarket

Experimentation Continuous Delivery Quality Improvement AgileInitiative

AgileTransformation

Nice to Have

Optional

Important

Critical

Level of importance:

Deployment

Provisioning

Release / DeployDevelop /Test

Monitor / Optimize

Monitoring

Customer Feedback

Code

Test

Portfolio Management

Requirements

Plan /Measure

Jazz, OSLC and Open Standards Platform

Collaboration Change & ConfigurationManagement

Dashboard / Analytics

68

Where do you start: DevOps Adoption Roadmap Assess desired outcome and supporting practices to drive strategy and roll-out

What am I trying to achieve?

•Think through business-level drivers for improvement •Align vision and pains to common business drivers across silos•Look across silos, not just within the team, for improvements

Where am I currently?

•What do you measure and currently achieve•What don’t you measure, but should to improve•What practices are well scaled vs. incubating•Refine objectives to particular practice areas

Where are my bottlenecks and

priorities?

•Business-level drivers expose practice gaps across silos•Focusing outside of the bottleneck limits overall improvement•It’s not just about tools, its about People, Practices, Technology, and information

Step

1St

ep 2

Step

3

Current PracticeAssessment

Objective & Prioritized Capabilities

Determine Activities Objective

How should I plan my practice

improvement?Step

4 • Identify improvements to skills, processes, and tools to achieve desired outcome• Roadmap activity to define actionable plan• Target improvements which get the best bang for the buck

Roadmap

Discussion

Business Goal Determination

69

70

Plan / Measure Development / Test Release / Deploy Monitor / Optimize

Scaled

Reliable

Repeatabl

e

Practiced

Practice based maturity model: Industry Average

Define release with business objectives

Measure to customer value

Optimize applicationsUse enterprise issue resolution

procedures

Standardize and automate cross-enterprise

Automate patterns-based provision and deploy

Fully Achieved Partially Achieved

Manage data and virtualize services for test

Deliver and integrate continuously

Link objectives to releasesCentralize Requirements

ManagementMeasure to project metrics

Link lifecycle information Deliver and build with test

Centralize and automate test management

Plan departmental releases and automate status

Automated deployment with standard topologies

Document objectives locallyManage department resources

Manage Lifecycle artifactsSchedule SCM integrations and

automated builds Test following construction

Plan and manage releases Standardize deployments

Monitor resources consistentlyCollaborate Dev/Ops informally

Plan and source strategicallyDashboard portfolio measures

Monitor using business and end user context

Centralize event notification and incident resolution

Automate problem isolation and issue resolution

Optimize to customer KPIs continuously

Improve continuously with development intelligence

Test Continuously

Manage environments through automation

Provide self-service build, provision and deploy

71

Summary Lean principles are embodied by many agile practices Lean and agile are complementary IBM DevOps provides paths for continuous improvement

Examples Agile methods help address the 7 wastes of Muda Agile frameworks and practices can help improve flow Agile frameworks and practices support standardization IBM DevOps is an approach to Kaizen—continuous learning and improvement Success relies on embracing people and management first

72

Acknowledgments Many people have provided insight that is captured in this presentation.

We wish to acknowledge:– Millard Ellingsworth and Maria Ericsson for providing feedback on the content for this

workshop– Paul Bahrs and Albert Ho for sharing their insight on the DevOps Maturity Model and

Assessment– Thanks to Tom and Mary Poppendieck for the time they spent educating IBM teams

during the early stages of IBM’s agile transformation.

73

References The Agile Manifesto. n.d. http://agilemanifesto.org/. Ambler, Scott, and Mark Lines. Disciplined Agile Delivery. Boston: IBM Press,

2012. Poppendieck, Mary, and Tom Poppendieck. Leading Lean Software

Development: Results Are Not the Point. Boston: Pearson Education, Inc., 2010. —. Lean Software Development: An Agile Toolkit. Upper Saddle River: Addison-

Wesley, 2003.

http://agilemanifesto.org/

http://agilemanifesto.org/