Can agile frameworks help small development teams? After looking at some agile basics, I examine two projects where a small development team used scrum. Agile can be used by small teams to their advantage with commitment and some work.

1. SMALL TEAM SCRUM &
KANBAN
Using Agile Frameworks to Produce Software at
IGSP

2. Roadmap
 Overview of agile
 Overview ofscrum and kanban
 Application to real projects
 Lessons for small teams

3. Agile Frameworks

4. 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

5. What is scrum about?
Scrum is about:
•Empiricism
•Self-organization
•Rhythm
•Collaboration

6. Scrum: the basics
 Roles
 Meetings
 Artifacts

7. Roles
 Development team
 Product Owner
 Scrum Master

8. Meetings
 Sprint planning
 Daily scrum
 Sprint review
 Sprint retrospective

9. Scrum cycles

10. Artifacts
 Product backlog
 Sprint backlog
 User stories
 Scrum board
 Burndown chart

11. Scrum board

12. Burndown chart

13. 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

14. 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!

15. 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

16. Kanban Board

17. 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

18. Why not just use a list?
 Why not?
 Thelist 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

19. 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

20. Project frameworks compared
 Which one is best? The least restrictive? It
depends. consider:
 Sizeof 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

21. Story of Two Projects

22. Context: what is lGSP?
 Institute for Genomic Science and Policy
 IGSP-IT: A small IT department
 Support research
 Support administration
 Two developer team

23. Real life stories
 Two projects, two stories
 Thecore shop
 Mapping the molecules

24. The Core Shop

25. Core Shop: context
 Known quantity
 Discrete modules of work
 Relatively unambiguous work
 A series of relatively small, related projects

26. 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

27. Whathappened
 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

28. 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

29. Mapping the Molecules

30. 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

31. 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

32. 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…”

33. 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

34. 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

35. 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

36. Small team scrum: Lessons Learned

37. 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

38. 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

39. It can work – with effort

40. Thank You
 Mark DeLong, IGSP-IT Director
 Darrin Mann and Darin London, Developers

41. 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
TonianneDeMaria Barry
The prescriptive/adaptive comparison came from:
Kanban and Scrum: Making the Best of Both by HenrikKniberg and MattiasSkarin

42. Questions? Comments?
 david.daniel@duke.edu