This is a session on Lean Principles for Agile Teams presented at ERUC in October 2013. This is the deck used with the LEGO building block exercise PDF.

1. Lean Principles for Agile Workshop
Elizabeth Woodward, Lean and Agile Strategist
Fariz Saracevic, Agile Evangelist

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

3. Status quo is not an option
INTRODUCTION
3

4. New Technologies Change
What We Develop and How We Develop
Cloud
Big Data
Requires Continuous Learning and
Improvement,
Lean and Agile Methods
Mobile
Social
Internet of Things
4

5. Many firms are underprepared for these rapid changes in technology,
affecting their ability to be competitive
Technology Trends Most
Impacting Competitiveness
Organizations Underprepared
for Technology Trends
Mobile device proliferation
Collaboration across the ecosystem
Explosion of unstructured data
Cloud platforms and solutions
Intelligent–connected systems
Note: Survey respondents were
allowed up to three selections
The Challenge: Innovation, quality, speed in
rapidly changing conditions
Source: “The Software Edge: How effective software development and delivery drives competitive advantage,” IBM Institute of Business Value, March
2013
5

6. Highlights of a few key activities over the past decades
BRIEF HISTORY OF LEAN AND AGILE
6

7. Brief History of Lean and Agile
HBR
New
New Product
Development
Game
Plan /
Measur
e
DevOps
Monitor
/
Optimize
Continuous
Innovation,
Feedback
and Improvements
Release
/ Deploy
7
Develop
/ Test

8. Importance of principles and values
The Toyota story has been
intensively researched and
painstakingly documented,
yet what really happens inside
the company remains a
mystery. Here’s new insight
into the unspoken rules that
give Toyota its competitive
edge.
– HBR, Decoding the DNA of the Toyota Production System
8

9. Agile and lean
transformations are culture
changes
“Culture reflects
the
realities of people working
together every day…
values, practices,
and traditions that define
…a set of
who we are as a group.”
--Frances Hesselbeim
Work by Uwe Kils) http://www.ecoscope.com/iceberg/
9

10. Relationship between Agile and Lean
Agile
Lean
Design build delivery focus
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 software
Eliminate Waste
Welcome frequent and late changes in requirement
Build Quality In
Strong collaboration between business and
development team
Defer Commitment
Face-to-face conversation
Sustainable development
Simplicity - the art of maximizing the amount of work
not done
Deliver Fast
Focus on Learning
Respect People
Optimize 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

11. Toyota Production System’s Three Types of waste
MURA
Elimination of Uneveness
11
MUDA
Elimination of Waste
MURI
Avoidance of the Unreasonable
11

12. Improve flow through the system
ELIMINATING MURA (UNEVENESS)
斑
12

13. JIT Pull vs. Push
Push
Anticipate usage
Large batches
High inventory
Pull
Focus on actual consumption
Small batches
Reduced inventory
Demand
Authorizes work
Empty unit or kanban authorizes work
Raw
Material
Input
Finished
13

14. Reducing cycle time by reducing batch sizes

Two ways to reduce cycle time:
• Reduce work arriving
• Create steady pace of service
Cycle Time as a Function of Utilization and Batch Size*

45

Cycle Time (hours)
40
Large Batches
35



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
Medium Batches
30
Small Batches
25
20
15
10
5
0
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Utilization
Figure source : Implementing Lean Software Development
14

15. WIP Constraints and Kanban ―information radiator‖
Not started
Development
Testing
G
I
F
Acceptance
C
Done
A
B
E
J
H
Exit Criteria
Exit Criteria
Exit Criteria
Exit Criteria
Exit Criteria
How can this flow be improved?
15

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

17. Exercise: Improving flow
Experiments to demonstrate elimination
of Mura.
45 min
17

18. 5 Whys
 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."
Why
Why
Why
Why
Why
18

19. Ruthless elimination of 7 wastes in manufacturing
ELIMINATING MUDA (WASTE)
無駄
19

20. WASTES
20
7
無駄
1.
2.
3.
4.
5.
6.
7.
Transportation
Inventory
Motion
Waiting
Overproduction
Over-processing
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 + Profit
Profit = Price - Cost
無駄
21

22. 1
Transportation Moving products creates risk of damage, lost, and
delay with no added value for which customer is willing to pay.
In Software =
Movement between systems
Movement between team members and
handoffs
無駄
22

23. Provide teams with the tools they need. Open and integrated.
―Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.‖ – Agile
Manifesto
Team Members
Continuous Delivery
Bridge Mainframe
and Mobile Skills
Open Lifecycle and Service Management Integration Platform
Link Systems of Record
to Systems
of Engagement
23

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
24

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
25

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
26

27. 2
Inventory Inventory is raw materials, work-in-progress (WIP),
or finished goods—capital outlay that has not produced income.
In Software =
Delivering partially-completed capability
Never-ending backlog
無駄
27

28. Delivering potentially shippable product every iteration
 No partially-completed work
accepted
Sprint
Goal
Product
Backlog
 Software delivered meet
acceptance criteria
 Software delivered meets the
definition of done
24 hrs
Daily Scrum
Meeting
2-4 weeks
Potentially Shippable
Product Increment
Sprint
Backlog
Sprint
Planning
Sprint
Review
28

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
…
29

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
30

31. 3
Motion refers to the damage that the production process inflicts on
the entity that creates the product (equipment or workers).
In Software =
Task switching
Death march
Throwing software ―over the wall‖
無駄
31

32. Cost of multi-tasking
 One project at a time
 Eliminate unimportant work
Sprint
Goal
Product
Backlog
24 hrs
Daily Scrum
Meeting
2-4 weeks
Even brief mental blocks created by shifting
Potentially Shippable
Product Increment
Sprint
Backlog
40 %
between tasks can cost as much as
of someone's productive time. – David Meyer,
University of Massachusettes
Sprint
Planning
Sprint
Review
Sprint
Reflection
32

33. Preventing a Death March
“Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely. “*
 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‖
*agilemanifesto.org
33

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…
34

35. 4
Waiting Products that are not in transport or being
processed, they are waiting.
In Software =
Delays in delivery working software to customers
Bureaucracy—Decisions, approvals
Elimination of blockers (inefficient tools, input,
reviews)
Waiting for feedback
無駄
35

36. Daily planning addresses blockers and inefficiencies
Sprint
Goal
Product
Backlog
24 hrs
Daily Scrum
Meeting
2-4 weeks
Potentially Shippable
Product Increment
Sprint
Backlog
Sprint
Planning
Sprint
Review
Sprint
Reflection
36

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?
37

38. Continuous feedback
“Business people and developers
must work together daily throughout
the project.” – Agile Manifesto
Sprint
Goal
Product
Backlog
24 hrs
Daily Scrum
Meeting
2-4 weeks
 Reviews of working
software provide
additional feedback and
adaptation
Potentially Shippable
Product Increment
Sprint
Backlog
Sprint
Planning
Sprint
Review
Sprint
Reflection
38

39. 5
Overproduction More product is produced than needed at
that time. Produced by large batches. Leads to excess inventory.
In Software =
Producing unnecessary features
Backlog refinement based on horizon
無駄
39

40. Producing Unnecessary Features
Often or Always
Used: 20%
Features and Functions Used
in a Typical System
Rarely or Never
Used: 64%
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
40

41. Agile work is done in ―small bites‖ from an ordered
backlog
Sprint
Goal
Product
Backlog

―Simplicity--the art of maximizing the
amount of work not done--is
essential.‖ –Agile Manifesto
24 hrs
Daily Scrum
Meeting
2-4 weeks
Potentially Shippable
Product Increment
Sprint
Backlog
Sprint
Planning
Sprint
Review
41

42. Agility and Simplicity
―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
Test Driven Development (TDD):
Programming practice in which all
production code is written in
response to a failing test.‖
List
Requirements
Write One
Test
Run Test to
Make Sure It
Fails
Refactor to eliminate code
smells (e.g., duplicated
code)
Add or modify just enough code to
make new test pass and all previous
tests pass
Test + Design
42

43. 6
Over-processing More work is done than is required by the
customer (e.g. more precise, higher quality).
In Software =
―Gold plating‖
Unnecessary testing
Excessive audits and validation
無駄
43

44. User Stories Agile Practice
Reducing 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‖
Card
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.
44
Conversation
Confirmation
•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
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
45

46. Excessive audits and validation
 Most enterprises
embracing agile eventually
adapt their business gating
processes
 Business validation
processes often acquire
excessive requirements
over time
46

47. Reducing excess processing—IP example
Can the IP Law office work through
non-disclosure agreements quickly
enough?
Can the IP Law office execute the
patenting process quickly enough?
47

48. 7
Defects Poor quality increases costs which should not be
passed on to the consumer and are taken as a loss.
In Software
Cost of defects increases over time
Technical debt carries additional cost
Missing requirements
Integration and migration failures
無駄
48

49. Waterfall cost of defects found over time
49

50. Earlier defect detection with agile leads to less waste
Analysis
Analysis
Design
Code
Test
Analysis
Design
Analysis
Analysis
Design
Design
Code
Code
Code
Test
Analysis
Code
Test
Analysis
Design
Design
Test
Design
Test
Analysis
Design
Code
Code
Test
Code
Test
Test
50

51. Agile practice of continuous integration helps to find
issues earlier.
51

52. Agile teams addressing technical debt (Example)
Agile team dedicated to new capability
Agile team dedicated to technical debt
80%*
*Percentages vary based on circumstances
20%*
52

53. 5
3
Example: Technical Debt Measures used at IBM
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%
~ $10,000,000
~ $6,400,000
Technical Debt
Note: Goals are either internal IBM statistics or industry benchmarks.
53

54. Value Stream Mapping Method for
IDENTIFYING WASTE
54

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.
Cycle Time
Customer Request
Customer Satisfied
55

56. Enterprise agility requires coordination, communication and
collaboration across the enterprise.
SSE (hardware/software) has been pushing those boundaries.
IT Example:
Retail customer is targeting 24 hours from accepting
new product to making web updates and adapting
supply chain to fulfill request
Supply Chain
Enterprise
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.
Organization
Portfolio
Program
Lean concept of optimization of the whole
– ―whole‖ continues to expand.
Team + Stakeholder Collab
Product and
Embedded
Coverage
Common IT
Coverage
IBM’s
Intent
56

57. devOps in SaaS – Common Definition
1. Agile
2. Agile -> Continuous Delivery
GA ready
functionality
Whole
Team
Users
Auto-mation
GA ready
functionality
Demos,
feedback
Whole
Team
GA
Auto-mation
Continuous
Integration
Development
Demos,
feedback
GA
Continuous
Integration
Development
Operations
3. Agile -> Continuous Delivery
GA ready
functionality
Whole
Team
Auto-mation
Demos,
feedback
Operations
Continuous
Deployment
GA
Continuous
Integration
Dev/Ops Collaboration
57

58. Spread of Agility across roles
1. Development team
2. Operations
3. Customers/users
4. Product management
5. Marketing
6. Sales
7. Education/Enablement
8. Services
9. Intellectual property
10.Software supply chain
11.Product supply chain
Supply Chain
Enterprise
Organization
Portfolio
Program
Optimization of
the whole with
expanding view of
―whole‖
Team + Stakeholder Collab
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?
59

60. Example Waterfall Value Stream
Customer tells of Feature Need  Customer Gets Benefit
Requirement
Identified
1 hour
Reqt
Reviewed
Reqts
DB
1 week
1 month
1 hour
18 Month
cycle
9 months
Review &
Decision.
“In Plan?”
Candidate
List
1 day
3 months
1 hour
0
Just for this feature
1 week
DCR
Selection?
2 months
9 months
DCUT
1 month
7 months
Testing
FV SVT IVT
2 months
1 day
Mfg
Test
Prep
Docs
1 week
1 day
Install
Upgrade
60
1 year
Migrate
Applications
Avg Customer Request to Ship
Dev Time
= 3 Months
Dev Waiting Time
= 24 Months
Total Dev Time
= 27 Months
Total Dev Efficiency = 13%
In Production
Avg Customer Request to Benefit
Dev/Cust Working Time
= 15 Months
Waiting Time
= 24 Months
Total Customer Time = 39 Months
Overall Customer Efficiency = 38%
60

61. Value Stream Example
Requirements
Develop
Test
23 - 33%
Efficiency
123 hours Value
Require
-ments
1 hour
1 hour
1 week
Develop
Test
Develop
Test
Requirements
value
waste
Requirements
Approval
Test
Requirements
Marketing
requests New
Feature
Develop
Develop
Test
2 weeks working together
1 day
500-660 Hours
Total Cycle Time
1 week
QA
Deploy
How much is
Value?
2-3 months to
merge
1 hour
½
week
IBM Internal Use Only : With Thanks to Mary and Tom Poppendieck
61

62. Exercise: Value Stream Maps
Select 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
Value Added Time
– Process Efficiency =
Total Cycle Time
* George & Wilson, Conquering Complexity in Your Business
62

63. Avoidance of the unreasonable
MURI
63

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
64

65. Continuous Improvement
KAIZEN
65

66. Relentless improvement, Learn through experiments
Sprint
Goal
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.
Standardized work is the basis for Kaizen
Product
Backlog
24 hrs
Daily Scrum
Meeting
2-4 weeks
Potentially Shippable
Product Increment
Sprint
Backlog
Sprint
Planning
Sprint
Review
Reflection
66

67. Continuously improving through shared learning while extending boundaries
AN APPROACH TO SELF-OPTIMIZING
TEAM OF TEAMS
67

68. IBM DevOps Reference Architecture for Agile Transformation
Agile
Agile
Transformation
Quality Improvement
Continuous Delivery
Initiative
Market
Experimentation
Plan /
Measure
Develop /
Test
Release / Deploy
Portfolio
Management
Code
Deployment
Mobile Transformation
Monitor /
Optimize
Monitoring
SW-Defined
Environments
Legacy
Systems
Level of importance:
Critical
Important
Requirements
Test
Provisioning
Customer Feedback
Nice to Have
Optional
Collaboration
Change & Configuration
Management
Dashboard /
Analytics
Jazz, OSLC and Open Standards Platform
Discussion
68

69. Where do you start: DevOps Adoption Roadmap
Assess desired outcome and supporting practices to drive strategy and roll-out
Step 4
Step 3
Step 2
Step 1
Determine
What am I trying
to achieve?
Where am I
currently?
Where are my
bottlenecks and
priorities?
How should I plan
my practice
improvement?
Activities
•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
•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
•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
Objective
Business Goal Determination
Current Practice
Assessment
Objective & Prioritized
Capabilities
• 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
69

70. Development / Test
Define release with business
objectives
Measure to customer value
Improve continuously with
development intelligence
Test Continuously
Manage environments through
automation
Provide self-service build,
provision and deploy
Automate problem isolation and
issue resolution
Optimize to customer KPIs
continuously
Reliable
Plan and source strategically
Dashboard portfolio measures
Manage data and virtualize
services for test
Deliver and integrate continuously
Standardize and automate crossenterprise
Automate patterns-based
provision and deploy
Optimize applications
Use enterprise issue resolution
procedures
Link objectives to releases
Centralize Requirements
Management
Measure 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
Monitor using business and end
user context
Document objectives locally
Manage department resources
Manage Lifecycle artifacts
Schedule SCM integrations and
automated builds
Test following construction
Plan and manage releases
Standardize deployments
Monitor resources consistently
Collaborate Dev/Ops informally
Practiced
Scaled
Plan / Measure
Repeatable
Practice based maturity model: Industry Average
Release / Deploy
Fully Achieved
Monitor / Optimize
Centralize event notification and
incident resolution
Partially Achieved
70

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
71

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

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: AddisonWesley, 2003.
73