Choosing the Right...

1

1 Copyright 2011 Gerard MeszarosCAMUG 2011 – LSSC 2011

Choosing the Right Agile/Lean/Kanban Board

Gerard Meszaros

[email protected]


Product & I.T.

I.T.

EmbeddedTelecom

My Background

Gerard Meszaros

[email protected]

•Software developer

•Development manager

•Project Manager

•Software architect

•OOA/OOD Mentor

•Requirements (Use Case) Mentor

•XP/TDD Mentor

•Agile PM Mentor

•Test Automation Consultant & Trainer

•Lean/Agile Coach/Consultant

80’s

-----

90’s

-----

00’s

2


Agenda

• Motivation

– Why We Use Visual Boards

• Elements & Styles of Visual Boards

– Scrum, XP, Kanban Boards

– Multiple vs. Nested Boards

• Designing a Visual Board

– Dry Run of LSSC 2011 Presentation

• Wrapup


Two Views of Same Info

• x

Design

Requirement Init Study HLD

Module

Design Code

Module

Test

Integ.

Test IVV Finished

DR1.1.1 x x x x

DR1.1.2 x x x x

DR1.1.3 x x x x

DR1.2.1 x x x x x

DR1.2.2 x x x x

DR1.2.3 x x x x

DR1.2.4 x x x x x x x x

DR1.3.1 x x x x

DR1.3.2 x x x x

Developer Commitments

AA BB CC DD EE FF GG HH

28-Nov

29-Nov

30-Nov

1-Dec

2-Dec

3-Dec

4-Dec Cmt1

5-Dec Cmt2

6-Dec Cmt3

7-Dec

8-Dec

9-Dec Cmt4

10-Dec

11-Dec

12-Dec

13-Dec

14-Dec

3


Planning & Status Board

Design

Requirement Init StudyHLD

Module

Design Code

Dev.

Test

Integ.

Test

IVV

TestFinished

DR1.1.1 x x x x

DR1.1.2 x x x x

DR1.1.3 x x x x

DR1.2.1 x x x x x

DR1.2.2 x x x x

DR1.2.3 x x x x


DR1.3.1 x x x x

DR1.3.2 x x x x


Typical Scrum Board

• At Beginning of a Sprint:Todo In Progress To Verify Accepted

Story 1

Story 2

Story 3

Story 4

4


Typical Scrum Board

• Halfway thru a Sprint:Todo In Progress To Verify Accepted

Story 1

Story 2

Story 3

Story 4

What does this tell us?


Typical Scrum Board

• Halfway thru a Sprint:Todo In Progress To Verify Accepted

Story 1

Story 2

Story 3

Story 4

Is this better? Why?

5


Why We Use Visual Boards

• Understand Team Behavior

– Mini-Waterfall vs.

– Swarming or Limiting Work-In-Progress

• Understand the current status of the work

• How much work is left?

• Who is working on what?

• What is ready for the business to verify? etc.


Story Tasks Story

Sprint

Backlog

ToDo In

Progress

Done To Verify Accepted

A Typical XP Task Board

• At Beginning of Sprint:

Story 1 Task 1Task 2Task 3




6


Story Tasks Story

Sprint

Backlog

ToDo In

Progress



• At Middle of Sprint:






Story Tasks Story

Sprint

Backlog

ToDo In

Progress



• At Middle of Sprint:

Story 1Task 1Task 2Task 3




7


Why We Use Visual Boards

• Understand Team Behavior

– Mini-Waterfall vs.

– Swarming or Limiting Work-In-Progress

• Understand the current status of the work

• How much work is left?

• Who is working on what?

• What is ready for the business to verify? etc.

• See all the work planned for the iteration

– Tasks behind the deliverables

• Choose the next thing to work on

• Enables self-organization

• Influence Team Behavior


Limitations of XP/Scrum Task Boards

• Current Iteration Only

– Separate Release Backlog

• Policies are implicit

– No explicit limits on Work-In-Progress

• Resources are assumed homogeneous

– Board doesn’t distinguish between specializations

How Can We Address These Shortfalls?

8


Agenda

• Motivation







• Wrapup


Building a Kanban Board

• Start with a Scrum Board:

Todo In Progress To Verify Accepted

Story 1

Story 2

Story 3

Story 4

9



• Identify Work and Buffers


We always have an Input Buffer and an Output Buffer

InputBuffer

Buffer?Work Work?

Story 1

Story 2

Story 3

Story 4

OutputBuffer



• Add Buffers as needed

Todo In Progress To Verify In Test Accepted

Buffers improve flow

InputBuffer

BufferWork WorkOutputBuffer

Story 1

Story 2

Story 3

Story 4

10



• Make Implicit Policies Explicit:

Note: A WIP Limit of 1 Forces “Swarming”

(4)

Todo

(1)

In Progress

(2)

To Verify

(1)

In Test Accepted

Story 1

Story 2

Story 3

Story 4

Input Limit

Dev Limit

Test Limit

To Test Limit

GGM52



• Another way to draw this board

Development Verification

(4)

Todo

(1)

In Progress

(2)

To Verify

(1)

In Test Accepted

Each Specialty has an Input Buffer limit and a WIP limit

SpecialtySpecialty

Story 1

Story 2

Story 3

Story 4

InputBuffer

WorkInputBuffer

Work

GGM52 Consider mving "Add Buffers" hereGerard Meszaros, 2/7/2011

11


Agenda

• Motivation








Other Techniques

• Multiple Boards

– Different Views of Same Information

– For different groups (Upstream, Downstream)

– Big Picture (e.g. Release) vs Detail (Iteration)

• Nesting Boards

– XP Task Board (Stories + Tasks)

12


Two Views of Same Info

• x

Design

Requirement Init Study HLD

Module

Design Code

Module

Test

Integ.

Test IVV Finished

DR1.1.1 x x x x

DR1.1.2 x x x x

DR1.1.3 x x x x

DR1.2.1 x x x x x

DR1.2.2 x x x x

DR1.2.3 x x x x


DR1.3.1 x x x x

DR1.3.2 x x x x



28-Nov

29-Nov

30-Nov

1-Dec

2-Dec

3-Dec

4-Dec Cmt1

5-Dec Cmt2

6-Dec Cmt3

7-Dec

8-Dec

9-Dec Cmt4

10-Dec

11-Dec

12-Dec

13-Dec

14-Dec


Mini-Waterfall Board (Status)

Design

Requirement Init StudyHLD

Module

Design Code

Dev.

Test

Integ.

Test

IVV

TestFinished

DR1.1.1 x x x x

DR1.1.2 x x x x

DR1.1.3 x x x x

DR1.2.1 x x x x x

DR1.2.2 x x x x

DR1.2.3 x x x x


DR1.3.1 x x x x

DR1.3.2 x x x x

13


Mini-Waterfall Board (Commitments)



28-Nov

29-Nov

30-Nov

1-Dec

2-Dec

3-Dec

4-Dec Cmt1

5-Dec Cmt2

6-Dec Cmt3

7-Dec

8-Dec

9-Dec Cmt4

10-Dec

11-Dec

12-Dec

13-Dec

14-Dec


Multiple Boards – Upstream + Downstream

• Separately located groups each have own board

• One group feeds work to the other

Todo

Collect

Reqts Analyse

Write Req’t

Doc To Dev’t

Ftr.1

Ftr.2

Ftr.3

Ftr.4

SE Board:

14


Multiple Boards – Upstream + Downstream

• Separately located groups each have own board

• One group feeds work to the other


Ftr.1

Ftr.2

Ftr.3

Ftr.4

Dev Board:

Todo

Collect

Reqts Analyse

Write Req’t

Doc To Dev’t

Ftr.1

Ftr.2

Ftr.3

Ftr.4

SE Board:


Multiple Boards – Release + Sprint

Story Priority Estimate Value Rank Sprint

Story 1 H L H 1 S.1

Story 2 M S M 2 S.1

Story 3 M M H 3 S.1

Story 4 L S S 4 S.2

Story 5 L L M 5 S.2

Story 6 M M H 3 S.3

Story 7 L S S 4 S.3

15


• Stories picked for sprint are moved to Sprint board

Multiple Boards – Release + Sprint


Story 1

Story 2

Story 3

Story 4

Sprint 1 Stories:

Story Priority Estimate Value Rank Sprint

Story 1 H L H 1 S.1

Story 2 M S M 2 S.1

Story 3 M M H 3 S.1

Story 4 L S S 4 S.2

Story 5 L L M 5 S.2

Story 6 M M H 3 S.3

Story 7 L S S 4 S.3


Multiple Boards – Sprint + Task(Velocity)

Todo

(1) In

Progress To Verify Accepted

Story 1

Story 2

Story 3

Story 4

16


Multiple Boards – Sprint + Task

• Story moved into “In-Progress” triggers task breakdown

• Last Task Done triggers moving Story into “To Verify”

ToDo In Progress Done

Task 1

Task 2

Task 3

Task 4

(Velocity)

Todo

(1) In

Progress To Verify Accepted

Story 1

Story 2

Story 3

Story 4


• With Just-in-time Task Breakdown:Story

(Velocity)

Sprint BacklogDevelopment Tasks (2)

To Verify AcceptedToDo Progress Done

Nested Boards – Sprint + Task


Story 2Task 1Task 2

Task 3

Story 3

Story 4

17


• With Just-in-time Task Breakdown:Story

(Velocity)

Sprint BacklogDevelopment Tasks (2)






Story 4


• Make Task Breakdown Policy ExplicitStory

(velocity)

Sprint

Backlog

(1) Task

Break-

down

Development Tasks (2)






Story 4

18


Agenda

• Motivation







• Wrapup


Managing and Visualizing Non-linear Workflows using a

Kanban Matrix

Gerard Meszaros

[email protected]

19


Agenda

• My Book Project

– Background

– Issues & Attempts

– The Matrix Solution

– Summary of Benefits

• Other Applications

– Team Matrix

• Bridging Development Styles

– Waterfall Matrix

– Incremental Matrix


My Book Project

• Working on 2nd Draft

• Content largely nailed down

– 19 Test Smells

– 69 Test Patterns

– 14 Introductory Narratives

– Several hundreds terms, references, etc.

• Stored in ~400 xml files

• Lots of small edits to be made

• Many edits applied to all/most files

20


Examples of Edits to be Made:

• Change all occurences of “you” to “we”

– E.g. “you should” becomes “we should”

• Address any TODO’s in each file

• Ensure all Patterns

– have a Problem heading

– have a Sketch

– have a Motivating Code Sample

– have at least one Solution Code Sample

• Ensure all Related Patterns:

– use same style of sketch

– use related code sample

• Ensure Causes and Variations are separated


1st Attempt: XP Task Board• Task per Edit per File. Work on one task (edit) at a time

• Finish one file(Chapter) before moving on to next

• Implicit WIP limits of 1 Story & 1 Task in progress

Edits

Chapter

Backlog

ToDo In

Progress

Done Chapter

Done

Chapter1

Chapter2Edit1Edit2Edit3

Edit1Edit2Edit3

Edit1Edit2Edit3

Edit1Edit2Edit3

Chapter4

Chapter3

GGM49

GGM49 Consider animating Tasks and StoriesGerard Meszaros, 2/7/2011

21


Issues Encountered:

• What to do when New Work Emerges:

– Discover another Edit (kind of work)

– What happens to “done” files? When to decide?

Edits

Chapter

Backlog

ToDo In

Progress

Done Chapter

Done

Chapter1

Chapter2Edit1Edit2Edit3

Edit1Edit2Edit3

Edit1Edit2Edit3

Edit1Edit2Edit3

Chapter4

Chapter3

Edit4

Edit4

Edit4

Edit4

?

GGM51


Issues Encountered:

• What is the right size of work for One Piece Flow?

– All Edits to one file? (Usually too big, defocused)

– One edit to one file? (Usually too small)

– One edit applied to all files? (Often too big)

• How to Visualize “How Much Work Left?”

– Backlog largely hidden

– %Done = “Sum % done (for each file)” not easy to see

XP-Style Task Board clearly not working

GGM50

GGM51 Need to remove blank column once format is finalizedGerard Meszaros, 2/7/2011

Slide 42

GGM50 Could duplicate previous diagaram and annotate with these issues.Gerard Meszaros, 2/7/2011

22


Alternatives Considered

• Column per resource

– Not useful given only 1 person

– Doesn’t convey progress

• Row per Chapter, Standard Checklist

– Too hard to keep track of what’s done per chapter

– Especially when new edits added to task list

• Task Card per Edit per Chapter

– Too much overhead creating stacks of task cards

– Too many “edit task” cards to put into single cell

– Easy to miss/lose “edits task” cards


Enter The Matrix

• Changed columns to represent individual edits

– Initially about 10 edit types

Chapter Edit.1 Edit.2 Edit.3 Edit.4

Narr.1 Done Done Done Done


Narr.n Done Done Yes Yes

Smell.1 Yes Yes Yes Yes


Smell.n Yes Yes Yes Yes

Pattern.1 Yes Yes Yes Yes


Pattern.n Yes Yes Yes Yes

– Tried to define column order as workflow

Legend:

Yes Needed

Done Work done

23


Visualizing Progress

• Changed colour of cell in progress to Yellow

– Changed it to green when finished




Narr.n Done Done Yes







Legend:

Yes Needed

In Progress

Done Work done


Discovering New Work











Legend:

Yes Needed

In Progress

Done Work done

24



• Simply added a new column

Chapter Edit.1 Edit.2 Edit.3 Edit.4 Edit.5










• Messed up “column order as workflow”

– Do I address new items on all previously finished rows? (Implicitly makes MRF edit highest priority!!)

Legend:

Yes Needed

In Progress

Done Work done



• Simply added a new column

– Left it blank until I had time to investigate which files

Chapter Edit.1 Edit.2 Edit.3 Edit.4 Edit.5

Narr.1 Done Done Done Done No





Smell.n Yes Yes Yes Yes Yes




– Filled in Yes or No whenever I discovered the answer

Legend:

Unknown (TBD)

No Not Needed

Yes Needed

In Progress

Done Work done

25


Issues

• “Column order as workflow” didn’t work well

– Didn’t reflect how I wanted to work

– Some edits needed high energy -> best tackled when fresh.

– Other edits were pure mindless drudgery -> required less energy

– Some edits didn’t apply to some files


Right-Sizing Work

• Keep tasks small by picking work based on time availability & energy

– Several cells in same row (file) when changes were small

Chapter Edit.1 Edit.2 Edit.3 Edit.n



Narr.n Yes Yes Yes Yes




Pattern.1 Yes



26


Right-Sizing Work



– Several cells in same column (kind of edit) when ensuring consistency between files








Pattern.1 Yes Yes Yes




Right-Sizing Work



– Several cells in same column (kind of edit) when ensuring consistency between files

– Single cell when limited time or large kind of work











• Proved to be a very effective means ofwork levelling and managing WIP

27


Agenda

• My Book Project

– Background

– Issues & Attempts

– The Matrix Solution

– Summary of Benefits

• Other Applications

– Team Matrix

• Bridging Development Styles

– Waterfall Matrix

– Incremental Matrix


Other Applications – Team Matrix

4-person writing team at MSFT

• Each Chapter/Major Topic was a row

• Writing/Reviewing/Editing Activities and Standard Sections as columns

– Number of columns grew as project progressed

• People put initials into cell when they took on work

28



Bridging Development Styles

• Agile (XP) development project of SAP-based quoting application

• System Integration required work in SAP (several modules), Customer SADB, PeopleSoft and Messaging Middleware.

SAPQuoting PeopleSoft

CRMSAPCustomer

Quotations

CustomerSADB

Customer Customer

SAPMessaging

MercatorMessagingmessage

Each Colour is a Different Specialty!!

GGM47

GGM47 Gerard Meszaros, 1/24/2011

29


Bridging Development Styles

• Highly-specialized resources

– Used to working in BDUF (waterfall) style

– Seconded to Agile project

• Business wanted

– more visibility than afforded by waterfall

– Risk reduction through earlier integration

• Waterfall-minded resources said “impossible”

GGM48


Visualizing the Work

• Defined all the integration test scenarios

GGM48 Gerard Meszaros, 1/24/2011

30



Scenario SAP

HLD

CRM

HLD

MOM

HLD

SAP

Coding

CRM

Coding

MOD

Coding

Integration

Testing

Acceptance

Testing

New Customer Req

New Customer ACK

New Customer NACK

Edit Customer

Edit Customer ACK

New Quote

Edit Quote


• Built matrix of scenarios vs waterfall steps

Note: Some Specialties omitted due to space





• Initial Project Plan would have unfolded like:Scenario SAP

HLD

CRM

HLD

MOM

HLD

SAP

Coding

CRM

Coding

MOD

Coding

Integration

Testing

Acceptance

Testing

New Customer Req

New Customer ACK

New Customer NACK

Edit Customer

Edit Customer ACK

New Quote

Edit Quote


31



Scenario SAP

HLD

CRM

HLD

MOM

HLD

SAP

Coding

CRM

Coding

MOD

Coding

Integration

Testing

Acceptance

Testing

New Customer Req

New Customer ACK

New Customer NACK

Edit Customer

Edit Customer ACK

New Quote

Edit Quote



• Initial Project Plan would have unfolded like:





• Initial Project Plan would have unfolded like:

• The Business wanted Risk reduction through earlier integration


Scenario SAP

HLD

CRM

HLD

MOM

HLD

SAP

Coding

CRM

Coding

MOD

Coding

Integration

Testing

Acceptance

Testing

New Customer Req

New Customer ACK

New Customer NACK

Edit Customer

Edit Customer ACK

New Quote

Edit Quote

32


Evolving to Incremental Dev’t

• We asked resources to focus on initial scenario “New Customer Request” as a Proof of Concept

Scenario SAP

HLD

CRM

HLD

MOM

HLD

SAP

Coding

CRM

Coding

MOD

Coding

Integration

Testing

Acceptance

Testing

New Customer Req

New Customer ACK

New Customer NACK

Edit Customer

Edit Customer ACK

New Quote

Edit Quote




• Once that was demonstrated, it became clear that we could work one test case at a time

Scenario SAP

HLD

CRM

HLD

MOM

HLD

SAP

Coding

CRM

Coding

MOD

Coding

Integration

Testing

Acceptance

Testing

New Customer Req

New Customer ACK

New Customer NACK

Edit Customer

Edit Customer ACK

New Quote

Edit Quote

33



Scenario SAP

HLD

CRM

HLD

MOM

HLD

SAP

Coding

CRM

Coding

MOD

Coding

Integration

Testing

Acceptance

Testing

New Customer Req

New Customer ACK

New Customer NACK

Edit Customer

Edit Customer ACK

New Quote

Edit Quote






• And the Business LOVED the visibility


Scenario SAP

HLD

CRM

HLD

MOM

HLD

SAP

Coding

CRM

Coding

MOD

Coding

Integration

Testing

Acceptance

Testing

New Customer Req

New Customer ACK

New Customer NACK

Edit Customer

Edit Customer ACK

New Quote

Edit Quote

34


Tools Used

• Big Visible Wall Chart

– My Book Project (initially)

– MS Book Team Project (initially)

– Integration Project (printed from Excel)

• MS Excel Spreadsheet

– My Book Project (later)

– MS Book Team Project (later)

– Integration Project (for printing wall chart)


When to Use Kanban Matrix

• Workflow is non-linear

– Activities can happen in parallel or any order

• Work types are expected to change over time

– More task types added

• Need to see All the Work (Big Picture)

– Not just the work in progress but all work done and left

35


References

• Kanban: Kanban, Successful Evolutionary Change for Your Technology Business

– By: David J Anderson

– http://Tour2010.xunitpatterns.com


Agenda

• Motivation







• Wrapup

36


So How Do You Design Your Board?

• Decide what you want to use the board for:

– Conveying Status

– Influencing Behavior

• Decide what information is important for you

– Product Backlog

– Iteration Backlog

– Work Breakdown

• Model your workflow

– Steps, parallel activities, buffers

• Pick a Basic Board Style to Represent the Info

• Try it Out and Adapt as Needed

– Status of Work

– WIP Limits


Thank You!Gerard Meszaros

[email protected]

http://www.xunitpatterns.com

These Slides: http://Camug2011Slides.gerardmeszaros.com

Call me when you:

• Want to transition to Agile or Lean

• Want to do Agile or Lean better

• Want to teach developers how to test

• Need help with test automation strategy

• Want to improve your test automation

Jolt Productivity Award winner - Technical Books

Upcoming xunitTraining.com:

Testing for Developers:April 19-20 Calgary

http://testingguidance.codeplex.com/

Choosing the Right...

Documents

Transcript of Choosing the Right...