small team scrum and kanban
Post on 16-May-2015
2.586 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related