agile lean kanban in the real world

Agile Lean Kanban in the Real World

../Video/Comlexity_EricBerlow_2010.mp4

../Video/Comlexity_EricBerlow_2010.mp4

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

Lean Agile Overview


Case Study

Copyright © 2016 Russell Pannone. All rights reserved.

Lean Thinking

Lean Agile Overview


Case Study

Lean Agile Overview


Lean principles originate from the lean manufacturing approach also known as 'just-in-time production‘ as pioneered by Toyota that transformed the car manufacturer's approach to building vehicles

The Lean "house" shown here depicts the elements of a lean system

Lean Thinking

Explicit permission granted by Scaled Agile, Inc. © 2008 - 2016 Scaled Agile, Inc. and Leffingwell, LLCCopyright © 2016 Russell Pannone. All rights reserved.

Value Delivery in Weeks versus Months

Weeks

VS


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

MonthsIn 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

The Triple Constraint

Dynamic System Development MethodSource: http://www.dsdm.org


Lean Thinking

Explicit permission granted by Scaled Agile, Inc. © 2008 - 2016 Scaled Agile, Inc. and Leffingwell, LLC



Respect for People

One needs to feel one’s work has meaning

Excited to jump out of bed in the morning and belonging to a team with a mission that matters

Centralized Coordination

Decentralized Control

Self-directing and self-organizing teams

Culture fosters improvement, continual mastery, and growth

Lean Thinking



10

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


11

Traditional Waterfall Process



waterfall.pdf

waterfall.pdf

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 Ries in his book The Lean Startup.


Lean Thinking



Continual Product Improvement

“Iterating” builds an “Increment” of the product, verifies & validates it, then slowly builds up quality delivering

“Value” incrementally

Build For Some Requirements

Initial set of Requirements, input to the initial iteration.

Build For Some More Requirements

Build For Some More Requirements

ProductIncrement

ProductIncrement

ProductIncrement

VAL

UE

VAL

UE

VAL

UE


Continual Process Improvement

ACTActions to continually

improve process performance

PLANEstablishment of

the objectives and processes

DOImplementation of

the processes

CHECKMonitoring

measurements of processes and products, and

reporting the results


Lean Thinking



8 Principles of Lean Agile Leadership

Lean

Agile

Principles

12

3

45

6

7

8Build high-performing teams

Implement software development flow

Unlock the intrinsic motivation of knowledge workers

Take an economic view of the full value chain

Embrace the Agile Manifesto

Develop people, not things

Own the system of which you speak

Decentralize control


The Kanban Method Overview

Lean Agile Overview


Case Study


http://net1.ist.psu.edu/chu/wcm/vc/toyota1.gif

Kanban is 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. Implement Feedback Loops

6. Improve Collaboratively, Evolve Experimentally (using models and scientific methods)


Visualize


Limit Work-in-Progress

../Courses/Video/Lucys_Famous_Chocolate_Scene.mp4

../Courses/Video/Lucys_Famous_Chocolate_Scene.mp4

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

PolicyCopyright © 2016 Russell Pannone. All rights reserved.

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

Kanban Method

Overview

Case StudyCase Study

• This real life example covers how a newly formed

Infrastructure group applied a 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.

• This team was 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 the

Team Integration

Environment

Purpose

System Testing

1st testing 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 sprintsRussell: 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 daysRussell: 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 mix of planned and unplanned (event driven) work

•Better visibility into what the team is doing and needs to do next

•See if Kanban Work-In-Process limits will help improve team effectiveness.

•See if measuring and optimizing Cycle Time will help improve our effectiveness

Goal


• Backlog: 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

• Accepted: A celebration of recently completed work. Clear out every two weeks

• Expedite: Emergencies (Yellow Cards)- may exceed the WIP limits

Initial cut: Infrastructure Kanban Board

Backlog (3-8)

Ready(Tasked)

(3-8)

PendingExternal

Dependency

(8)

In Progress

(6)

Done Accepted

Expedite


• When you are available but WIP limit is reached, 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 WIP 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 is something broke and are Yellow-Card expedites. Hopefully rare.

Explicit policies


• Continuous Planning: No Sprint Planning / Sprint Closing Meetings

• Product Owner prioritizes the Backlog and keeps the 8 slots in Product 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 refinement daily

• Time box Research stories

• Track event driven work as Tasks

• Keep the Kanban board and VersionOne in-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/ArtifactsProduct backlogSprint backlogiteration

board mapped on the process board mapped on the process

Events

daily Scrumsprint planningsprint reviewsprint retrospective

none requireddaily Scrumother Scrum related events if needed

Prioritization Part of backlog grooming. Done by POOut 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)

PODepends 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

RolesProduct 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 backlogprioritized 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

Documents