Small team scrum and kanban


Published on

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.

Published in: Technology
1 Comment
  • This is a good explanation of both methods - thank you. I personally have been preferring Kanban for a while now, but I know Scrum can work in the right circumstances too. Would love to recommed a follow-up read on the subject: - I've been finding many a useful tip in there for years. Thanks for sharing the presentation!
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Framework vs. methodologyMethodology is more restrictiveFramework allows more decisions to be made by team
  • This says we value one thing over another, not that we don’t values the second thing at allFor the most part, agile values make more sense for small teams then traditional waterfall valuesAgile is a general philosophy, under agile there are several frameworks. We will cover two today: scrum and kanban
  • Empiricism = inspect & adapt and record keepingself-organization = developers decide how to do stuff, no micromanagement Rhythm = getting all team members in a predictable cycleCollaboration = working as a team, among developers, and devs with othersSelf-organization and collaboration are crucial with small teams.
  • Like “separation of powers” in the constitutionDevs = do the work and they decide how it is done and which tools are usedPO = Tells the team what needs to be done and what things are most importantSM = makes sure scrum is running well, runs meetings
  • Sprint = an increment of time form one to four weeks, often two weeksSprint planning is when the team decides what work will be done in the upcoming sprint (PO, Dev, SM)Daily scrum is where dev team reviews work of past day and commits to today's work and flags obstacles (devs, SM) – no more than 15 minutes!Review is where team looks a work done during sprint (PO, dev, SM, all interested stakeholders)Dev team looks at what worked well and what didn’t (devs, SM)
  • Sprint backlog is a subset of product backlogDaily scrum is a smaller iteration inside the larger sprint iteration – all involve inspection and adaptionWhat is missing is that the adaptations are used in the next sprint, so there should be an arrow form software back to product backlog
  • Product backlog = all work that has been requested by PO that is not done yetSprint backlog = all work to be done in current sprint, a subset of the product backlogUser story = description of feature from user perspective: “as a customer I can access and change the calendar so that I can schedule services” = as a user, I can do some action in order to achieve the desired result. In scrum, you are always breaking bigger things down into smaller things: prod backlog -> sprint backlog -> tasks on scrumboard
  • Movement is from left to right.At a glance, you can see how much work is done, what stories have more work done or lessAre these stories doing well? Depends when in the sprint you are looking at them.
  • Here you have the context of when in the sprint you are looking at stories and workYou must get to zero at the end of the sprint to make your commitmentsYou want to be as close to the red line as you can beHow is this team doing?
  • Explain capacityIllustrate WIP with dog storyCan be used by operations, sysadmins, etcDies not give a definition of kanban
  • Tasks are moved from left to rightPen is for tasks that are on holdNo time boxes required, but you can add them
  • For example, I use kanban for my dba and scrum master work and for personal to-dos
  • Consider citing to source
  • Research = computational and storage resources, bioinformatics knowledgeAdministration = for service providers, keeping track of services and paymentsSeven person department
  • The shop = allows clients to arrange services, providers to track services and get paidMapping = supports research directly allowing interpretation of complex information and data
  • This was our first scrum project!
  • Define scrum zero
  • Consider group work photo here
  • Small team scrum and kanban

    1. 1. SMALL TEAM SCRUM &KANBANUsing Agile Frameworks to Produce Software atIGSP
    2. 2. Roadmap Overview of agile Overview ofscrum and kanban Application to real projects Lessons for small teams
    3. 3. Agile Frameworks
    4. 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. 5. What is scrum about? Scrum is about: •Empiricism •Self-organization •Rhythm •Collaboration
    6. 6. Scrum: the basics Roles Meetings Artifacts
    7. 7. Roles Development team Product Owner Scrum Master
    8. 8. Meetings Sprint planning Daily scrum Sprint review Sprint retrospective
    9. 9. Scrum cycles
    10. 10. Artifacts Product backlog Sprint backlog  User stories Scrum board Burndown chart
    11. 11. Scrum board
    12. 12. Burndown chart
    13. 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. 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. 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. 16. Kanban Board
    17. 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. 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. 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. 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. 21. Story of Two Projects
    22. 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. 23. Real life stories Two projects, two stories  Thecore shop  Mapping the molecules
    24. 24. The Core Shop
    25. 25. Core Shop: context Known quantity Discrete modules of work Relatively unambiguous work A series of relatively small, related projects
    26. 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. 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. 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. 29. Mapping the Molecules
    30. 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. 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. 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. 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. 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. 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. 36. Small team scrum: Lessons Learned
    37. 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. 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. 39. It can work – with effort
    40. 40. Thank You Mark DeLong, IGSP-IT Director Darrin Mann and Darin London, Developers
    41. 41. AcknowledgementsPhotos can be found scrum cycle diagram is a wikimedia commons file from: dog metaphor for WIP came from:Personal Kanban: Mapping Work | Navigating Life by Jim Benson and TonianneDeMaria BarryThe prescriptive/adaptive comparison came from:Kanban and Scrum: Making the Best of Both by HenrikKniberg and MattiasSkarin
    42. 42. Questions? Comments?