Post on 31-Aug-2014
description
transcript
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
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
Potentially ShippableProduct Increment
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
Potentially ShippableProduct Increment
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
Potentially ShippableProduct Increment
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
Potentially ShippableProduct Increment
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
Continuous Integration
Whole Team
GA ready functionality
Demos,feedback GA
2. Agile -> Continuous Delivery
Auto-mation
Continuous Integration
Whole Team
GA ready functionality
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
Require-ments Develop Test
QAMarketing
requests New Feature
Approval Require-ments Develop Test Deploy
Require-ments Develop Test
Require-ments Develop Test
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
Potentially ShippableProduct Increment
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.