Agile Lean Kanban Training 1 hour

1. Agile & Lean / Kanban
0

2. What is Lean?
1

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

13. How Does Agile Fit?
12

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

18. Responding to Change > Following a Plan
17

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

21. Kanban
20

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

24. Example Development Boards
23

25. Example 2
24

26. Example 3
25

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

29. What Goes On A Card
28

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

33. Agile & Lean
32

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

36. Agile & Lean Together
35

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