Agile Lean Kanban Training 1 hour
-
Upload
ryan-polk -
Category
Technology
-
view
6.407 -
download
3
description
Transcript of Agile Lean Kanban Training 1 hour
0
Agile & Lean / Kanban
1
What is Lean?
2
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).
3
Lean Has History Standard software development practice for the last
decade.
Agile is the combination of principals that have existed for over 60 years.
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
called a System of Profound Knowledge, consisting of four
parts:
Appreciation of a system: understanding the overall processes involving suppliers, producers, and customers (or recipients) of goods and services (explained below);
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.
W. Edwards
Deming
Lean
Manufa
ctu
ring
Agile
Quality
Managem
ent
(Six
Sig
ma)Lean
Software
Dev.
4
Agile
PrincipalsCommunications
Simplicity
Feedback
Courage
Respect
Visibility
Honesty
Realism
Quality
Lean
PrincipalsOptimize the Whole
Eliminate Waste
Create Knowledge
Build Quality In
Defer Commitment
Deliver Fast
Respect People
5
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
6
Create Knowledge / Amplify Learning
Customer Feedback
Short Cycle Times
Refactoring
Code Review
Automated Test instead of documented
defects.
7
Build Quality In
Unit Test / TDD
Automated Acceptance Tests
Refactoring
Pattern Based Development
Continuous Integration
8
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.
9
Deliver Fast
Small Batch Sizes
Short Iterations
Feedback, Feedback, Feedback.
Close Customer Collaboration
Software Demos
10
Optimize the Whole
Manage the Value Stream
Look beyond the Development Team
Standardize the process
Efficiency vs. Effectiveness
11
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.
12
How Does Agile Fit?
13
The Agile Manifesto – Agile Principals
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.
“We are uncovering better ways of developing software... Through this work we have come to value:”
14
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.
15
Working Software > Comprehensive Documentation
Working Software requires just as
much documentation as the
customer needs.
No More & No Less.
16
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.
17
Responding to Change > Following a Plan
18
Agile PrincipalsSome of the principles behind the Agile Manifesto[6] are:
Our highest priority is to satisfy the customer through early and continuous deliveryof 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.
19
Typical Agile
Adoption
1. User Stories
2. Acceptance tests
3. Iterative Development
4. Burn Down Charts
5. Story Boards
6. Daily stand-ups
7. TDD / Unit Tests
8. Continuous integration
Simple Lean
Adoption
1. User Stories
2. Acceptance tests
3. Iterative Development
4. Burn Down Charts
5. Kanban Boards
6. Daily stand-ups
7. TDD / Unit Tests
8. Continuous integration
V.S.
20
Kanban
21
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
22
3 Rules
1. Strict Queue Limits
2. Pull Value Through
3. Make it Visible
Strict Queue Limits
Pull Value
Through
Make it Visible
Kanban
23
Example Development Boards
24
Example 2
25
Example 3
26
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
27
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
28
What Goes On A Card
29
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
30
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
31
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
32
Agile & Lean
33
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?)
34
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
35
Agile & Lean Together
36
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.
37
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.