SMALL TEAM SCRUM & KANBANUsing Agile Frameworks to Produce Software at IGSP

Roadmap

Overview of agile Overview of scrum and kanban Application to real projects Lessons for small teams

Agile Frameworks

What is agile anyway?

Agile Values: Individuals and interactions over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Respond to change over following a plan

What is scrum about?

Scrum is about:• Empiricism• Self-

organization• Rhythm• Collaboration

Scrum: the basics

Roles Meetings Artifacts

Roles

Development team Product Owner Scrum Master

Meetings

Sprint planning Daily scrum Sprint review Sprint retrospective

Scrum cycles

Artifacts

Product backlog Sprint backlog

User stories

Scrum board Burndown chart

Scrum board

Burndown chart

Why use scrum?

Can make work more satisfying for developers

Can increase developer efficiency Non-developers can more easily have

insight into a software project May make hiring easier With testing, increases production of

cleaner software

What are the costs of scrum? Takes effort Need a scrum master Some time must be spent in meetings New terminology and concepts must be

learned Change!

What is Kanban?

Visualize work Break work down in to smaller pieces Those smaller pieces are put on cards The cards are placed on the kanban board The board usually has at least three columns:

To do, doing, done Limit work in progress (WIP) – the work in the

doing column - so developers don’t get overloaded

Measure “lead time” – the average time it takes to complete an item from beginning to end

Kanban Board

Why use kanban?

Adds structure with relatively little overhead

Can be used by small teams Can be used by even one person Does not need scrum master

Why not just use a list?

Why not? The list becomes the “list from hell” Some items never get done

People do not like the feeling of uncompleted work that is expected to be done

Project frameworks compared They vary in how prescriptive they are:

XP (extreme programming) has about 13 core practices,

Scrum has about ten Kanban has about three “Just do it” has one

The less prescriptive a framework is, the more adaptive it is

Project frameworks compared Which one is best? The least restrictive?

It depends. consider: Size of team Level of commitment Type of work

Examples: Operations projects do not do well in scrum Epic, complex problems do not do well in

kanban

Story of Two Projects

Context: what is lGSP?

Institute for Genomic Science and Policy IGSP-IT: A small IT department

Support research Support administration

Two developer team

Real life stories

Two projects, two stories The core shop Mapping the molecules

The Core Shop

Core Shop: context

Known quantity Discrete modules of work Relatively unambiguous work A series of relatively small, related

projects

Core Shop: Type of work

Rails apps with oracle backend Apps allow clients to select services Many projects were add-ons to existing

functionality Relatively simple Scope was restricted

What happened

This was our first scrum project We did not execute scrum perfectly but

we did produce working software The PO bought in right away, in part

because she was similarities between scrum and SOP’s used in her lab

We over and under estimated and committed

What worked?

Educating the PO about scrum happened very early

Projects often had similarities, such as very similar database structures

We produced tangible results early on Pair programming ensured that knowledge

did not stay with only one developer The developers worked hard to fulfill their

commitments

Mapping the Molecules

Mapping the Molecules: context Software was directly research related –

not administrative Project was very large – an epic Project was complex Scope was wide Because of that there was ambiguity

More context

PO was very skeptical about scrum There was pressure outside of IGSP and

Duke (funding) A prototype had been produced before

use of scrum

Type of work

Rails with oracle backend Would eventually be open to public Users would get meaningful data related

to their research Users would be able to calibrate and

compare complex instrument output Many unknown processes: “and then this

happens…”

What happened

Did not have early education on scrum Needed a sprint zero, which we did not

know existed Sprint zero is an increment of time before tasks can

worked on

Because of this, got behind our goals Status was not communicated effectively Did not produce enough tangible work

early on

What we would differently next time

Scrum education up front Let the PO prioritize stories right away Determine the ambiguity of a project

and consider a sprint zero Consider the size of the project when

committing Communicate quickly and clearly

What we are doing now

Using a facilitator with the PO who is not a developer and is not on the PO team as a proxy

Estimating very carefully Taking on realistic amounts of work Communicating more quickly Project is progressing well

Small team scrum: Lessons Learned

Lessons learned

There is very little buffer with a small team Consider having contingency plans

Think about your scrum overhead Try to minimize non-coding time

Lessons learned

Get better at estimation as quickly as possible

Do not over commit Communicate good and bad events

quickly Listen to your teams frustrations Conflict is good in scrum it can help you

figure out what is wrong – but conflict needs to be resolved

It can work – with effort

Thank You

Mark DeLong, IGSP-IT Director Darrin Mann and Darin London,

Developers

Acknowledgements

Photos can be found at:

www.flickr.com/photos/library_of_congress/

The scrum cycle diagram is a wikimedia commons file from:

http://en.wikipedia.org/wiki/File:Scrum_process.svg

The dog metaphor for WIP came from:

Personal Kanban: Mapping Work | Navigating Life by Jim Benson and Tonianne DeMaria Barry

The prescriptive/adaptive comparison came from:

Kanban and Scrum: Making the Best of Both by Henrik Kniberg and Mattias Skarin

Questions? Comments?

david.daniel@duke.edu