Your SlideShare is downloading. ×
0
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Small team scrum and kanban
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Small team scrum and kanban

2,682

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 …

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
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,682
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 1. SMALL TEAM SCRUM &KANBANUsing Agile Frameworks to Produce Software atIGSP
    • 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. AcknowledgementsPhotos 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.svgThe 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. Questions? Comments? david.daniel@duke.edu

    ×