3. Agile Development Methods (Dogma)
eXtreme Programming (XP)
Scrum
Lean Software Development
Behavior Driven Development (BDD)
Feature Driven Development (FDD)
Crystal Clear Methodology
DSDM
Others: Test Driven Development (TDD), Model
Driven Development (MDD), Rational Unified
Process (RUP).
2
4. Lean Has History
Standard software development practice for the last
decade.
Agile is the combination of principals that have existed for
W. Edwards
over 60 years. Deming
Lean Software Development exposes the pedigree of
Agile.
Almost all Agile practices can be traced back to Deming’s
System of Profound Knowledge and his 14 Points for
Management.
Deming’s System of Profound Knowledge:
Deming advocated that all managers need to have what he
ing
Ma ix S
Qu gem a)
(S
tur
na igm
nu ean
called a System of Profound Knowledge, consisting of four
ali ent
fac
ty
L
parts: Lean
Ma
Appreciation of a system: understanding the overall Software
Dev.
processes involving suppliers, producers, and customers
(or recipients) of goods and services (explained below); Agile
Knowledge of variation: the range and causes of
variation in quality, and use of statistical sampling in
measurements;
Theory of knowledge: the concepts explaining
knowledge and the limits of what can be known.
Knowledge of psychology: concepts of human nature.
3
5. Agile Lean
Principals Principals
Communications Optimize the Whole
Simplicity Eliminate Waste
Feedback Create Knowledge
Courage Build Quality In
Respect Defer Commitment
Visibility Deliver Fast
Honesty Respect People
Realism
Quality
4
6. Eliminate Waste
Everything not adding value to the customer is
considered to be waste (Muda). This includes:
Unnecessary code and functionality
Delay in the software development process
Unclear requirements
Bureaucracy
Slow internal communication
5
7. Create Knowledge / Amplify Learning
Customer Feedback
Short Cycle Times
Refactoring
Code Review
Automated Test instead of documented
defects.
6
8. Build Quality In
Unit Test / TDD
Automated Acceptance Tests
Refactoring
Pattern Based Development
Continuous Integration
7
9. Defer Commitment
Wait till the last “Responsible” moment to
make an irreversible decision.
Set Based Design
Pursue multiple solutions eventually choosing
the best one.
Agile Version: Prioritize backlog, but don’t
commit more then one iteration at a time.
8
10. Deliver Fast
Small Batch Sizes
Short Iterations
Feedback, Feedback, Feedback.
Close Customer Collaboration
Software Demos
9
11. Optimize the Whole
Manage the Value Stream
Look beyond the Development Team
Standardize the process
Efficiency vs. Effectiveness
10
12. Respect People
Trust in people that they know the best
way to do their jobs.
Recognize Teams and Individuals for their
effort and contribution
People are not “Resources”
Empower the team to make the right
decisions and improve the process.
11
14. The Agile Manifesto – Agile Principals
“We are uncovering better ways of developing software... Through this work we
have come to value:”
Individuals and interactions over processes
and tools
Working software over comprehensive
documentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.
13
15. Individuals & Interactions > Process and Tools
We value communication and teamwork over strict
processes and the tools to enforce them.
Most software problems can be traced back to
communication problems early on in a products
lifecycle.
Osmotic communication
means that information
flows into the background
hearing of members of the
team, so that they pick up
relevant information as
though by osmosis.
14
16. Working Software > Comprehensive Documentation
Working Software requires just as
much documentation as the
customer needs.
No More & No Less.
15
17. Customer Collaboration > Contract Negotiation
Remove barriers
between the developers
and the customers.
Understand that the
closer the relationship
between the customer
and the development
team the better the
product.
16
19. Agile Principals
Some of the principles behind the Agile Manifesto[6] are:
Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing
teams.
At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.
18
20. Typical Agile Simple Lean
Adoption Adoption
1. User Stories 1. User Stories
2. Acceptance tests 2. Acceptance tests
3. Iterative Development 3. Iterative Development
4. Burn Down Charts 4. Burn Down Charts
5. Story Boards V.S. 5. Kanban Boards
6. Daily stand-ups 6. Daily stand-ups
7. TDD / Unit Tests 7. TDD / Unit Tests
8. Continuous integration 8. Continuous integration
19
22. Kanban
Signboard or Billboard
Kan means "visual," and ban, means "card" or "board”
Is a signaling system to trigger action
Uses cards to signal the need for work to be done
Another Toyota Lean lesson focusing on Just in Time
production
Example: 20 car doors, 5 left = “time to make more doors”
Doors are requirements, requirements are inventory
21
23. 3 Rules Strict
Queue
1. Strict Queue Limits Limits
2. Pull Value Through
3. Make it Visible Pull
Kanban Value
Through
Make it
Visible
22
27. Work In Progress (WIP)
Create Columns for Each Step in your process
Pick Limits for “Active” Queues (team size divided by 2
or just be logical)
Set “Wait” Queues to 2 or 3, keep small, Eliminate
waste, get feedback
FIFO
If a slot is full, can’t start more work (A.K.A. PULL)
Team sets Queue sizes to be most efficient,
experiment
Designed to Limit WIP, More WIP means slower flow
26
28. WIP
Visible feature goals to minimize thrashing
MMF = minimal marketable feature
or MUF = minimal usable feature
Can Only reorder in “Wait” Queue to move
MUF forward
Put Team Signals/Rules Above WIP
Queue & Cross Team Signals On Bottom
Could add a Queue for External Team
3 Rules: Strict Limit, Pull Value, Visible
27
30. Cycle Time / Throughput
Goal is to get optimum flow
How many days does it take to flow through the team
once it enters the WIP?
Keep a chart: Wait/Cycle Time for each card size
Good teams/systems: XS to Medium cards, Large = Bad
If 22 ~same size cards in WIP, track 22 as well
Sum up unit value on each board
Velocity is a trailing indicator
Throughput is a measure of demonstrated capacity
29
31. Backlog Board
3 Queues to show priorities
Set back log limit for each board to equal number of
slots on WIP
Make assumption relative sizes will be close
Same number of items in WIP on each board (22 in
this example)
Add up the “units” to ensure they are close, move wait
line if they are considerably (not marginally) off
Can now forecast based on logical assumptions
Schedule regular backlog honing meetings with
customer, rules at top
Trigger release planning meetings when necessary
Card is a TOKEN, physical means real, avoid
temptation to live by a tool
30
32. What’s Changed:
Optimize/Continuous Flow
No Iteration Planning Meetings
FIFO work order, don’t sign up
Cycle Time replaces velocity, always updated
Signal Event
Show & Tell
RPM
Scheduled Events
Retrospectives
Releases per MMF/MUF or Cadence
31
34. Scrum vs. Kanban
Why do we really care?
Agile Manifesto is about uncovering better ways of doing
software – not about one practice vs. another
Principles
Frequent Delivery does not mean you must do
iterations
Maintain a constant pace indefinitely (sustainable
pace AND consistent pace?)
33
35. Daily Scrum/Standup
Used to Be
What did I do yesterday
What am I going to do today
Do I have any road blocks
Could Now Be
How are things flowing?
Team stands and reviews the WIP
Talk about blocks & constraints
Downstream work is most important
Take Turns with each person “reading” the flow
34
37. Agile & Lean Teams
1 Team Agile – 2 Week Interations
1 Team Lean – Kanban
Coordination:
Release on the Cadence – 2 Weeks
Separate Stand-Ups / Scrum of Scrums
Rotating Testing & Verification
Product Owners provide work to both teams based on
criteria.
Velocity, Lead Time & Cycle Time can all be
coordinated.
36
38. Kaizen - Continuous Improvement
改善
Team retrospectives, Scrum of Scrums, Scrum Master
Retrospectives
Product Owner Retrospectives, Release Retrospectives
The entire process of development at an Agile Enterprise
should be regularly inspected and improved.
The outcome of the PDCA process must include the
Check and Act portions.
37