The document discusses the use of agile frameworks, specifically Scrum and Kanban, for small teams in software development, highlighting their principles, roles, and meeting structures. It presents lessons learned from two projects within an IT department, emphasizing the importance of Scrum education and effective communication to achieve project goals. Key takeaways include the need for careful planning, realistic commitments, and the benefits of conflict resolution in enhancing team collaboration.

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