Agile & Lean & Kanban in the Real World

Agile Lean Kanban in the Real World
Outline
1. Lean Agile Overview
2. Kanban Method Overview
3. Case Study
Lean Agile Overview
Kanban Method Overview
Case Study
Copyright © 2014 Russell Pannone. All rights reserved.

Lean Thinking
Lean Agile Overview
Case Study

Lean Thinking
Explicit permission granted by Scaled Agile, Inc. © 2008 -2014 Scaled Agile, Inc. and Leffingwell, LLC

Value Delivery
In Traditional projects:
•Value is only delivered at the completion of last Phase of the Project
•Real value cannot be recognized during the majority of the development process
•Maximum value is achieved at product launch
In Agile projects:
•Each iteration delivers incremental functionality intended to continuously reflect the customer chosen direction for the product
•Customer realizes value as early as the completion of the first iteration
•Frequent integration at the end of each iteration ensures product quality early in the product lifecycle
Months
Weeks
VS

The Triple Constraint
Dynamic System Development Method
Source: http://www.dsdm.org

Develop individuals and teams; they build products
Empower teams to continuously improve
Build partnerships based on trust and mutual respect
Respect

Kaizen in Japanese means continuous improvement
Humanizes the workplace
Eliminates overly hard work (muri)
Teach people how to perform experiments on their work using the scientific method
Learn to spot and eliminate waste
In all, a humanized approach to workers and to increasing productivity
Kaizen

12
Seven Principles of Lean Software Development
1.Eliminate Waste
2.Amplify Learning
3.Delay Commitment
4.Deliver Fast
5.Empower the team
6.Build Quality In
7.Optimize the Whole

13
Traditional Waterfall Process
Explicit permission granted by Scaled Agile, Inc. © 2008 -2014 Scaled Agile, Inc. and Leffingwell, LLC

Empirical Process
Ideas
Build
Product
Measure
Data
Learn
Build It
Deploy It
Measure It
Think It
Study It
Tweak It
Image based on lean startup mentality as popularized by Eric Riesin his book The Lean Startup.

8 Principles of Lean Agile Leadership
Lean
Agile
Principles12345678Build high-performing teamsImplement software development flowUnlock the intrinsic motivation of knowledge workersTake an economic view of the full value chainEmbrace the Agile ManifestoDevelop people, not thingsOwn the system of which you speakDecentralize control

The Kanban Method Overview
Lean Agile Overview
Case Study
http://net1.ist.psu.edu/chu/wcm/vc/toyota1.gif
Kanbanis a Japanese word that literally means sign card or sign board

Kanban Method –Core Practices for successful adoption
1.Visualize
2.Limit Work-in-Progress
3.Manage Flow
4.Make Policies Explicit
5.ImplementFeedback Loops
6.ImproveCollaboratively, Evolve Experimentally (using models and scientific methods)

Visualize

WIP Limits
Each activity can only have so many work items
Work items are pulled into next state only when there is space

Make Policies Explicit
Policy

Sample Kanban Board

•Lead time measures the arrival rate. Lead time clock starts when the request is made and ends at delivery. Lead time is what the customer sees.
•Lead Time is measured by elapsed time (minutes, hours, etc.)
*Wikipedia
Ticket
Created
Lead Time
Manage Flow –Lead Time

•Cycle Time measures the completion rate
•Cycle time clock starts when work begins on the request and ends when the item is ready for delivery.
•WIP = 100 work items in progress
•Throughput = 2 work items per week
•Cycle Time = 100 / 2 = 50 weeks
This means that the Cycle Time to clear out all of this WIP is going to be 50 weeks, or roughly one year.
Ticket
Live
Ticket
Created
Start
Work
Cycle Time
Manage Flow –Cycle Time

Lead time clock starts when the request is made and ends at delivery.
Cycle time clock starts when work begins on the request and ends when the item is ready for delivery.
Ticket
Live
Ticket
Created
Start
Work
Lead Time
Cycle Time
Summary -Lead Time and Cycle Time

Infrastructure Team Kanban Experiment
Lean Agile Overview
Case Study
•This real life example covers how a newly formed Infrastructure group applied hybrid of Lean Agile and Kanban within an American multinational corporation that is engaged in the design, development, manufacturing and worldwide marketing and selling of footwear, apparel, equipment, accessories and services.
•As part of a $700K three year strategic program enabling Company ABC’s mission to create, transform and lead the marketplace with new organizational skills, processes and tools.
From
To
Sales functional focus
Enterprise solutions
Independent fixes
Integrated environment of people, process & technology
Unstable Sales 1.0 tools
Robust Sales 2.0 ecosystem

Setting Up, Supporting and Maintaining a
Continuous Integration Environment
Local
Workstation
DEV
QA
STAGE
PROD
Purpose
Design & Code
Purpose
Support Development
This is theTeam Integration Environment
Purpose
System Testing
1sttesting outside of Dev. Team
Demos
Purpose
Final Qualification in PROD-like environment
Purpose
Live & accessible to End Users
Generate Sales
Gate to DEV
•Commit to Source Control
•Compile
•Unit Test
•Analysis (Sonar)
•Component Test
•Package
•Deployment and Configuration Automation
Gate to QA
•Automated Functional Test (eg. Sauce)
Gate to STAGE
•Manual Acceptance Test
•Manual PCI scans
Gate to PROD
•Automated Performance Test
•Auto. Security Test (PCI Compliance)
•UAT
•PMO/Release Man. Approval
•Business Approval
Go live criteria
•Technical Validation
•Business Validation

Their Reality -Most of their work is event driven
Russell: How are things going now that you are being agile and using Scrum?
Carol: On this Program we’ve finally gone all-out being Agile and Scrum!
Russell: So how’s it going?
Carol: Well, it’s a lot better overall than what we had before...
Russell: ...but?
Carol: ... but we are a support & maintenance team.
Russell: yes, and?
Carol: Well, we love the whole thing about setting priorities in a product backlog, self- organizing teams, daily scrums, retrospectives, etc....
Russell: So what’s the problem?
Carol: We keep failing our sprints
Russell: Why?
Carol: Because we find it hard to commit to a 2 week plan. Sprints don’t make too much sense to us, we just work on whatever is most urgent for today. Should we do 1 week iterations perhaps?
Russell: Could you commit to 1 week of work? Will you be allowed to focus and work in peace for 1 week?

Their Reality
Carol: Not really, we get issues popping up on a daily basis. Maybe if we did 1 day sprints...
Russell: Do your issues take less than a day to fix?
Carol: No, they sometimes take several days
Russell: So 1-day sprints wouldn’t work either. Have you considered ditching sprints entirely?
Carol: Well, frankly, we would like that. But isn’t that against Scrum?
Russell: One size does not fit all. You choose when and how to be agile or use Scrum.
Carol: So what should we do then?
Russell: Have you heard of Lean Software Development and the Kanban Method?
Carol: What’s that? What’s the difference between that and Scrum? And I really like the rest of Scrum though, do I have to switch now?
Russell: No, you can combine the techniques! Lets collaborate on how.
Carol: Great where do we start?

•Experiment with a process that better fits our mixof planned and unplanned (event driven) work
•Better visibilityinto what the team is doing and needs to donext
•See if Kanban Work-in-process limitswill help improve team effectiveness.
•See if measuring and optimizing cycle timewill help improve our effectiveness
Goal

•Backlog: (State=Future) Product Owner’s next 8 things for team to address. Max=8 Min=3. This state should *never* run out
•Ready: Tasked-out stories ready to be worked. Max=8 Min=3.
•Pending External Dependency: Blocked due to dependency on a ticket, meeting, info, etc.
•Done: No limit because only Product Owner works on this state.
•Accepted: A celebration of recently completed work. Clear out every two weeks.
•Expedite: Emergencies (Yellow Cards)-may exceed the Work-in-progress limits
Initial cut: Infrastructure Kanban Board
Backlog
(3-8)
Ready
(Tasked)
(3-8)
Pending
External Dependency
(8)
In Progress
(6)
Done
Accepted
Expedite

•When you are available but In Progress is full, instead of starting something, can you collaborate to get something Done?
•If not confer with the rest of the team and then go ahead and exceed the Work-In-Progress limit if that’s the only way to do valuable work. We hope that will be rare.
•If you identify the need to issue a ticket, setup a meeting, request information, etc. Initiate that request during Task-out and put the card in Pending External Dependency. That gives us a head-start on things that require waiting. Put a sticky on the card to identify the dependency.
•Use the process to the team’s benefit –but the process should not prevent you from doing the right thing.
•Help someone requests turn into quick-planned stories, grouped into a Consulting epic.
•Emergency something broke are Yellow-Card expedites. Hopefully rare.
Explicit policies

•Continuous Planning: No Sprint Planning / Sprint Closing Meetings
•Product Owner prioritizes the Backlog and keeps the 3 slots in (Top of) Backlog column full.
•The Team tasks out stories when a slot is available in the Ready column.
•WIP Limits: When a Work-In-Progress limit is reached, help someone finish something instead of starting something new (as much as possible).
•Less Splitting: No need to artificially split a story to make it fit-in-a-sprint. However still a good idea to deliver value in small, manageable chunks.
•VersionOne: New status Pending for (Pending External Dependency).
•Cycle Time: Measuring and optimizing cycle time how fast can we get tasks done.
•Consulting Stories: Help someone consulting (> 1 hour) –create a story and work with Product owner to plan it in right away Kanban-style.
What changes

•Daily Stand Up
•Product Owner prioritizes backlog
•Retrospectives every two weeks
•Product Owner backlog grooming daily
•Time box Research stories
•Track event driven work as Tasks
•Keep the Kanban board and VersionOnein-sync
What stays the same

•What is the right Work-in-process limit (if any) for Pending External Dependency column?
•If you are Interrupted from In Progress work, should that card come out of the column? Where should it go? How does it re-start?
Need to figure out

Scrum
Kanban
Scrumban
Board/Artifacts
Product backlog
Sprint backlog
iteration
board mapped on the process
board mapped on the process
Events
daily Scrumsprint planningsprint reviewsprint retrospective
none required
daily Scrumother Scrum related events if needed
Prioritization
Part of backlog grooming. Done by PO
Out of the process. There should be a prioritized backlog.
Out of the process. There should be a prioritized backlog.
Who feeds the work in progress (brings new work)
PO
Depends on defined roles and necessities
Depends on defined roles and necessities
Iterations
yes (sprints)
no (continuous flow)
not mandatory (continuous flow); could have sprints
Estimations
yes (in ideal days or story points)
no (similar work size items) (a)
no (similar work size items) (a)
Teams
recommended cross functional
cross functional or specialized
cross functional or specialized
Roles
Product OwnerScrum MasterTeam
as needed
Team + as needed
Teamwork
collaborative
based on pull approach
based on pull approach
WIP
planned for the duration of the sprint
controlled by workflow state
controlled by workflow state
changes to work scope
should wait for next sprint
added as needed (JIT)
added as needed (JIT)
Product backlog
prioritized list of user stories (estimated)
no (JIT)
no (JIT)
Impediments
addressed immediately
addressed immediately (b)
addressed immediately (b)
When does it fit?
Product developmentSmall value adding increments development possibleRequirements are in good shape
Support/maintenance work (operational level)
Product development
(a) team needs to comment on non-fitting work items in order to ensure readiness
(b) stop the line approach; teams should swarm to solve the impediment
http://www.ontheagilepath.net/2013/09/scrum-kanban-scrumban-fast-overview-and.html

Agile & Lean & Kanban in the Real World - A Case Study

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Agile & Lean & Kanban in the Real World - A Case Study

Similaire à Agile & Lean & Kanban in the Real World - A Case Study (20)

Plus de Russell Pannone

Plus de Russell Pannone (20)

Dernier

Dernier (20)

Agile & Lean & Kanban in the Real World - A Case Study