Intro to Agile: Scrum vs. Kanban

Intro to Agile
(Scrum & Kanban)
by Craig L. Jones
cjones@picsauditing.com
© Craig L. Jones, 2011-13. All rights reserved.

32 Years Software Development
14 Years Agile
(mostly XP, Scrum, & Kanban)
CSM & Scrum Coach
Recovering Over-engineer-er
http://tech.picsauditing.com

Agile
Scrum
Kaizen
Scrumban
Le a n
Kanban
XP

Late 40's (Japan & Europe) Late '90's (Global)
Agile
XP
Scrum DSDM
Crystal Clear
RUPkanban
Kaizen
Six Sigma
BSC
TQM
Lean
ISO 9000
CMM
Kanban
Drum-Buffer-Rope
MRP
CONWIP
Scrum
ScrumBan

Scrum
Rugby term for “huddle” – refers to the “Daily
Scrum” (stand-up meeting)

Scrum Team
● One Product Owner (representing many
stakeholders)
● One Scrum Master
●
Many Developers (7 ± 2)

Product Owner
● Represents all of the stakeholders - “a single,
wringable neck”
● Understands the big picture and the value each
story brings to it
● Considered the hardest job in the company (if
done well)

Scrum Master
● Coaches everyone on the Scrum process
● Facilitates the ceremonies
● Stats Tracker
● Impediment Unblocker
● Half-time job (if done well)
● Might also Scrum Master a second team, or
● Might also be a Developer
● Must NOT also be the PO

Developer
● Cross-Functional (anyone devoted to the
product development)
● Programmers (front end, back end, database)
● Designers (UX, packaging, industrial)
● Writers (tech, copy)
● Artists
● Testers (SDET, ad-hoc, certification)

Scrum “Ceremonies”
● Backlog Grooming (ongoing)
● Sprint planning (first 5% of the Sprint time; thus
2-8 hours)
● Daily Scrums (15 min)
● Sprint Demo (1-2 hours)
● Retrospective (<1 hour)

Scrum Artifacts
● Vision & Mission Statements
● Product Backlog
● Definition of Ready
● Definition of Done
● Sprint Backlog
● Burndown Charts
● Burnup Charts
● Velocity Record

Definition of Ready / Done
● Service Level Agreements for
inbound/outbound work.
● Ready: Guarantees made to the team before a
ticket is placed in the “Ready” column for them
to pick up and process
● Done: Guarantees made by the team when a
ticket is completed.
● Done: Most importantly lists what's not done
(e.g. internationalization/localization).

Sprint Planning
● Story 1 (13 pts)
● Story 2 (3 pts)
● Story 3 (8 pts)
● Story 6 (3 pts)
● Story 7
● Story 8
● Story 9
● Story 10
● Story 11
● Story 12
● Story 12 (1 pt)
● Story 9 (5 pts)
● Story 2 (3 pts)
Prioritized Product Backlog Sprint Backlog
During Sprint planning, the developers suggest that,
even though Story 12 is not highly valued by the PO,
it's a quick win (1 point) and something everyone can
rally around. They also suggest that Story 9 is high risk
and ought to be tackled early. The PO agrees.
All other things being equal, Stories 1 & 2 are pulled
from the top of the prioritized backlog.

A Scrum Board
Ready Test DoneDevDesignStory
White = Story (4x6 cards and blue masking tape)
Yellow = Sub-Task (3x3 Post-It note)

A Scrum Board

A Scrum Board
Stories stay in the left column
while tasks progress to the right

Product Backlog
● Epics
● User Stories
● Technical Stories
● Bug Tickets
– or –
● Epics
● Features
– User Stories
– Technical Stories
– Bug Tickets

Product Backlog
● Portfolio of Epics (18 month horizon)
● Program of Features (9 month horizon)
● Roadmap of Stories (3 month horizon)

Story Template
As a _______________________,
I want ______________________
so that ______________________
“As an administrator, I want a way to
control which users can perform which
tasks, via roles and permissions, so
that we can pass a Sarbanes Oxley
audit.”

Acceptance Test
Given _______ and _______
When _______ and _______
Then _______ and _______
Given that I am logged in as an
administrator, when I create a user John,
and I create a role Clerk, and I assign the
ReconcileReport permission to the Clerk
role, and I make John a Clerk, then John
should be able to log in and print the
Reoncile Report.

INVEST = Well-Written Stories
● Independent
● Negotiable
● Valuable
● Estimable
● Small
● Testable

INVEST = Well-Written Stories
Small vs. Independent
______
As small as possible, yet still has
intrinsic value

Kanban means “Sign Board”
Kanban is an element of just-in-time (JIT)
production, as invented by Taiichi Ohno for
Toyota in the late 1940's – based on studies of
inventory systems used in supermarkets
at the time.

kanban card = “signal card”
“kanban” with a lower-case “K”

kanban card = “signal card”

“Kanban” System
“Kanban” with a Capital “K” refers to a system
(framework) for tracking work in progress.
“Signal” Cards Work Cards

Kanban & Scrum Share...
● Easy to Learn the Basics
● Big, Visible Charts
● Regular Cadence
● Retrospectives (“Inspect & Adapt”)
● Cross-Functional Collaboration
● Maximizing Value (by Eliminating Waste)
● Early Feedback
● Formal Definitions of Ready/Done

Kanban vs. Scrum
● It's all just “Work”
● Steady “Flow” by
Limiting Work in
Progress (“WIP”)
● Measure Cycle Time
& Throughput
● “Pull” System
● Stories, Epics &
Tasks
● Incremental Delivery
via (2 week) Sprints
● Measure Velocity
● Sprint Planning/
Negotiating

How to Choose?
Kanban:
● Operations Work
● Software
Maintenance Work
● Coming from Rigid
Legacy Methods
(Waterfall)
● Compartmentalized,
Siloed Teams
Scrum:
● Greenfield Project
● Many Stakeholders
● Must Coordinate
Around a “Roadmap”
● Lots of Epic Stories

A Simple Kanban Board
Ready Doing Done
No distinction between Stories and
Subtasks. They are all just Tasks.

Ready Doing Done
Vertical “Lanes”

Ready Doing Done
“Sub Lanes”

Ready Doing Done
Horizontal “Swim Lanes”
!

Ready (3) Doing (3) Done
“WIP Limits”

A Software Dev Kanban Board
Ready (6) Test (5) Done
Example of a team workflow with
progressive steps (by different handlers)
Dev (3)Design (3)

An Event-Planning Kanban Board
Ready (6) Finalize
(5)
Done
Example of a (one-person) workflow with
phases – nothing to do with engineering work
Short
List (3)
Research
(3)

The Broader Picture
Ready (3) Doing (3) DoneBacklog Reflect

A Typical Kanban Board for
Software Development
Ready (6) Test (5) DoneDev (3)Design (3)

“Pulling” Kanban Cards
Sub-lanes show when steps are
completed (ready to be pulled)
Dev (3)Design (3)
Available to be pulled
Still in progress

Why Limit Ready Column?
● Enforces delaying decisions until last
responsible moment
● It's how the Product Owner “negotiates” with the
team – PO (representing stakeholders) decides
what, Team decides in what order (by pull)
● Work is tracked according to the time it enters
the Ready column until it lands in the Done
column (“lead time”). A ready limit makes that
meaningful.

Highlighting Priorities
!
Some options: Notation symbols on the cards, color
coding of the cards, sub-lanes, or a combination thereof.
Dev (3)Design (3)
!
B A

Differentiating Work
Feature (value to customer)
Dev (3)Design (3)
! !
Infrastructure (value to team)
For example...

Flagging Impediments
Impeded
Dev (3)Design (3)
! !

Flagging Impediments
Impeded
Dev (3)Design (3)
! !
Impeded work is still WIP-limited

What About Story Size?
It doesn't seem to matter. Kanban case studies, so far,
indicate that it's much more lucrative to be concerned
with idle time between activity than the activity time itself.
Dev (3)Design (3)
Adjust them? Denote them? Track them?

Kanban Analysis Types
● By reflecting on outlier stories
● By looking for patterns on the Kanban Board
● By tracking cycle time
● By tracking flow

Reflecting on Outlier Stories
_
Backlog Reflect
___
_
_
__
Outlier: Work with Extra-Long, or Extra-Short Cycle Time
.

Reflecting on Outlier Stories
_
Backlog Reflect
☹
☺
___
_
_
__
Outlier: Work that was Particularly Pleasant or Unpleasant
.

Possible Actions: Outliers
● Is it a problem/opportunity?
● Dig deep (“5 Whys?”) to get from the
proximate cause to the root cause
● How might the delay have been mitigated?
● Retool &/or Retrain
● Definition of Ready issue?
Definition of Done issue?

Development Bottleneck
Step-completed still counts in WIP Limit
Dev (3)Design (3)

Testing Bottleneck
Step-completed still counts in WIP Limit
Dev (3)Design (3)

Design Bottleneck

Possible Actions: Bottlenecks
Note: Occasional bottlenecks are good. They interject
welcomed slack time. What you want is a roughly even
distribution of slack time across the functions. If not, then ...
● Cross-functional “swarming”
● Add manpower
● Retool &/or Retrain
● (DO NOT just increase WIP Limits)

Recurring Impediments
Impeded
Dev (3)Design (3)
! !

Possible Actions: Impediments
● Revise the Definition of Ready – Don't start the
work until you know it won't be impeded that
way
● Reassign responsibility for impediment-causing
work to the Team (i.e. make the external
resource join the team)
● (Rarely) revise the Definition of Done to exclude
the impeded work (i.e. pushing responsibility for
that part off the Team)

Tracking Cycle Times
Born Begin WIP Done

Cycle Time

Lead Time

Counting Flow
3 1 5 2

Cumulative Flow Diagram
Done
Test
Dev
Design

Actions: Encroaching Channels
This is basically early detection for
bottlenecks, so...
● (Same actions as Bottlenecks)

Control Chart
X-axis: One column per story completed
Trend line
(running
average)
Y-axis: Lead time
(subtract Begin date
from Done date)

Possible Actions: Wavy Trendline
Can the hiccups be explained? If not, then...
● Smaller stories
● Reduce the WIP limits (yes, reduce)
● Attend to impediments
● Remove distractions

Take-Aways
All of the various Agile Methodologies attempt to...
1. Eliminate waste. They “Maximize the work not done.”
2. Only provide a framework. You must “Inspect & Adapt”
3. Only illuminate problems. There is no silver bullet.
4. Boost communication. When stakeholders and
developers are on the same page, the methodology has
done its job.

Intro to Agile: Scrum vs. Kanban

More Related Content

What's hot (20)

Similar to Intro to Agile: Scrum vs. Kanban (20)

Recently uploaded (20)

Intro to Agile: Scrum vs. Kanban