ScrumBut Michael Hall Three Beacons mike@threebeacons.com 214.783.3936
Fundamental Tenets Of Scrum 2
Scrum Tenet 1: Empiricism Empiricism Make decisions based on observation and experimentation not theory, that is replace detailed up front planning and processes by just in time cycles by inspect and adapt. Inspect & adapt Iterative development Reflect for improvement Just-in-time planning Plan one sprint at a time 3
Scrum Principle 2: Self Organization Self Organization Allow the team to self manage and be autonomous, allow them to organize themselves around clear goals, objectives and constraints. Team members figure out how Start with what you know right now Team level commitment Team members choose their tasks Quality governed by definition of done Trust Transparency 4
Scrum Principle 3: Collaboration Collaboration Collaborate with the team, do not manage or direct them. Engaged customer Highly collaborative teams that commit Team is left alone during the sprint Committed (pigs) and interested (chickens) Teams are cross-functional Daily team synchronization Sprint progress tracked on sprint backlog / burndown chart 5
Scrum Principle 4: Prioritization Prioritization Work on the most important thing first, that is the things that add the most value, don t waste time working on things that do not add immediate value. Work items prioritized on a product backlog Business value Risk mitigation technical challenges Spikes to reduce uncertainty 6
Scrum Principle 5: Time Boxing Time Boxing Set time boxes and stick to them - do not extend them. This creates the rhythm that everyone can work to. Fixed iteration length Consistent heartbeat of delivery (Variable) Potentially shippable product increment Time-boxed project Sustainable pace Planning for sprint: 1 day (Typically Fixed) (Fixed) 7
Scrum Principle 6: Sashimi Sashimi Develop software in vertical slices, end to end. Do not develop horizontally as this creates large integration issues near the end of the project. Sashimi functional slices, end-toend Demo deliverables at end of sprint Emergent architecture Emergent design 8
ScrumBut 9
What is ScrumBut? ScrumBut is anything that goes against a fundamental tenet of Scrum. Not a laundry list of personal desires or complaints Generally described as We do Scrum, but Changing Scrum so that a problem is no longer visible Also called ScrumBut smells ScrumBut 10
ScrumBut - transparency 11
ScrumBut - definition ScrumBut [skruhmbut] noun. 1. A person engaged in only partially Agile project management or development methodologies 2. One who adopts only SOME tenets of the SCRUM methodology. 3. In general, one who uses the word but when answering the question Do you do SCRUM? 12
ScrumBut - syntax (Practice not followed) (Reason) (Workaround) We don t do daily standups, because we can t afford the 15 minutes, so we meet whenever we need to, usually once a week or so. 13
ScrumBut - analogy 14
ScrumBut - analogy 15
ScrumBut - pervasiveness T or F: it is fine to remain here. Most Scrum teams have some level of ScrumBut Likely that only 20% or less teams are pure Scrum 16
ScrumBut so what? Is ScrumBut bad? Is ScrumBut a normal result of evolving? Is ScrumBut an acceptable result of slowly introducing agile methods? Is ScrumBut another theoretical concept with no practical application by people who don t develop software every day? Scrum exposes organizational and behavioral challenges within the development team and the organization, and these will have to change in order to become more successful. 17
Nokia ScrumBut Test 18
Nokia ScrumBut Test Question 1: Iterations No iterations - 0 Iterations > 6 weeks - 1 Variable length < 6 weeks - 2 Fixed iteration length 6 weeks - 3 Fixed iteration length 5 weeks - 4 Fixed iteration 4 weeks or less 10 Question 2: Testing No dedicated QA - 0 Unit tested - 1 Feature tested - 5 Features tested as soon as completed - 7 Software passes acceptance testing - 8 Software is deployed 10 Question 3: Specification No requirements - 0 Big requirements documents - 1 Poor user stories - 4 Good requirements - 5 Good user stories - 7 Just enough, just in time specification - 8 Good user stories tied to specifications as needed 10 Question 4: Product Owner No Product Owner - 0 Product Owner who doesn t understand Scrum - 1 Product Owner who disrupts team - 2 Product Owner not involved with team - 2 Product owner with clear product backlog estimated by team before Sprint Planning meeting - 5 Product owner with release road map with dates based on team velocity - 8 Product owner who motivates team -10 Question 5: Product Backlog No Product Backlog - 0 Multiple Product Backlogs - 1 Single Product Backlog - 3 Product Backlog clearly specified and prioritized by ROI before Sprint Planning - 5 Product Owner has release plan based on Product Backlog - 7 Product Owner can measure ROI based on real revenue, cost per story point, or other metrics 10 Question 6: Estimates Product Backlog not estimated - 0 Estimates not produced by team - 1 Estimates not produced by planning poker - 5 Estimates produced by planning poker by team - 8 Estimate error < 10% - 10 19
Nokia ScrumBut Test Question 7: Burndown No burndown chart - 0 Burndown chart not updated by team - 1 Burndown chart in hours/days not accounting for work in progress - 2 Burndown chart only burns down when task in done - 4 Burndown only burns down when story is done - 5 Add 3 points if team knows velocity Add 2 point if Product Owner release plan based on known velocity Question 8: Team Management/Disruption External management disrupts team - 0 Product Owner disrupts team - 1 Product Owner or Scrum Master assigning tasks - 3 Scrum Team assigns tasks - 5 No outside disruptions, only Scrum roles 10 Question 9: Build Automation No build automation - 0 Continuous Integration build automated - 1 Nightly build automated - 3 Unit Tests run during nightly build - 5 Feature tests run during nightly build - 7 Deployment to other environments automated 10 Question 10: Daily Scrum No Daily Scrum meeting - 0 Daily Scrum meeting everyday - 1 Daily Scrum meeting same time, place - 3 Daily Scrum runs < 15 minutes - 5 Add 2 if reported Impediments are logged Add 2 if tasks are directly updated during meeting Add 1 if only Scrum Team are allowed to speak Add your scores up and divide by 10. A score of 8.0 or higher indicates you are using an optimal level of Scrum. 20
Nokia ScrumBut Test Gap analysis - Identify the areas where your score was less than the max - Improve these areas by changing culture, policies, organization, etc. - Don t change Scrum! 21
ScrumBut Examples 22
Exercise: ScrumBut 1 Is the following Scrum or ScrumBut? Sprints are planned for approximately 30 calendar days. They can go 5 or 6 weeks depending on what happens. 23
Exercise: ScrumBut 2 Is the following Scrum or ScrumBut? Iterations are always 3-weeks. 24
Exercise: ScrumBut 3 Is the following Scrum or ScrumBut? A few scrum team members may get pulled out of a sprint to do bug-fixing for another project. 25
Exercise: ScrumBut 4 Is the following Scrum or ScrumBut? We like to let the managers and directors speak to the team as part of the daily scrum. 26
Exercise: ScrumBut 5 Is the following Scrum or ScrumBut? We just use Excel for our product backlog instead of a tool. 27
Exercise: ScrumBut 6 Is the following Scrum or ScrumBut? At company ABC, we feel that our sustainable pace is 50 hours/week. 28
Exercise: ScrumBut 7 Is the following Scrum or ScrumBut? Standing is silly, so we do a sit-down daily scrum. 29
Exercise: ScrumBut 8 Is the following Scrum or ScrumBut? Sometimes a developer in a sprint goes off on his/her own and fixes some issues that have been longstanding. We like to encourage this type of initiative. 30
Exercise: ScrumBut 9 Is the following Scrum or ScrumBut? Our business analyst is our product owner. He/she helps plan the upcoming sprint, but does not really help the development team during the current sprint. 31
Exercise: ScrumBut 10 Is the following Scrum or ScrumBut? Most if not all of our acceptance testing is done on the last day or two of the sprint. This means we have no time to react to feedback. 32
Exercise: ScrumBut 11 Is the following Scrum or ScrumBut? We do release planning. Everyone knows that we would never ship to a customer except as a planned release several months down the road, so we don t worry about it until the time gets closer. 33
Exercise: ScrumBut 12 Is the following Scrum or ScrumBut? We do release planning. This lets us fix the content of each iteration leading up to the release. 34
Exercise: ScrumBut 13 Is the following Scrum or ScrumBut? We track defects in a tool. They do not become part of the product backlog. We work them in whenever we can. 35
ScrumBut - Personal Experience 36
ScrumBut Smells Team members pulled at VP s whim - Violates team left alone during sprint QA is separate organization and still requires a handoff - Violates teams are cross-functional Team members cover for someone not performing - Violates transparency / trust QA sashimi tests run in subsequent sprint - Violates potentially shippable product increment QA not involved in user story development/review - Violates teams are cross-functional QA not involved in release/sprint planning - Violates committed team 37
ScrumBut Smells ScrumMaster assigns tasks - Violates self-organization No demos at end of sprint - Violates inspect & adapt Daily Scrums held only when necessary due to overhead cost - Violates daily team synchronization Sprint cannot start until other groups do their job architecture, database, etc. - Violates start with what you know If the PO really wanted to ship early, we would need a week or two to package the release for shipment - Violates potentially shippable product increment 38
ScrumBut Smells We do regression testing in subsequent sprints - Violates potentially shippable product increment We don t use a definition of done - Violates quality governed by definition of done We don t hold a Sprint Retrospective - Violates inspect & adapt Our sprints are miniature waterfalls - Violates emergent design and most Scrum tenets We don t require developers to update the sprint backlog - Violates sprint backlog updated Our environment encourages individual performance over team performance - Violates team level commitment 39
ScrumBut Smells Demos use stubs and placeholder software - Violates potentially shippable product increment Teams are pressured to over-commit - Violates sustainable pace We cherry-pick the parts of Scrum we like - Violates original intent of Scrum We have a planning week in between each sprint - Violates sprint planning in 1 day We hold retrospectives but we don t emphasize their findings - Violates inspect & adapt 40
Conclusion 41
ScrumBut - conclusion Most companies have some level of ScrumBut It s not bad, but. it. - is non-optimal - can be inefficient - can hurt your business Think of it this way. it is.. An opportunity for improvement A way to get a leg up on your competition! Don t just accept it do something about it! 42
Exercise: Your Company Think of ways in which your company uses Scrum. Ask yourself: Q: is there any ScrumBut? Q: what fundamental tenet does it violate? Q: what can we do about it? 43
Good References 44
Questions? Agile Software Product Development Partner www.synerzip.com Hemant Elhence, hemant@synerzip.com 469.322.0349 www.threebeacons.com Short/Long term Agile coaching Facilitated improvement Agile Methods training: Scrum Team Training Agile / Scrum User Stories Requirements w/ Agility Product Owner Role ScrumMaster Role Etc. All courses can be delivered onsite at your location www.synerzip.com / www.threebeacons.com 2011 Michael Hall, mike@threebeacons.com 214.783.3936 45
Synerzip in a Nut-shell 1. Software development partner for small/mid-sized technology companies Exclusive focus on small/mid-sized technology companies By definition, all Synerzip work is the IP of its respective clients Deep experience in full SDLC design, dev, QA/testing, deployment Technology and industry domain agnostic 2. Dedicated team of high caliber software professionals Seamlessly extends client s local team, offering full transparency NOT just staff augmentation, but provide full mgmt support 3. Actually reduces risk of development/delivery Experienced team - uses appropriate level of engineering discipline Practices Agile development responsive, yet disciplined 4. Reduces cost dual-shore team, 50% cost advantage 5. Offers long term flexibility allows (facilitates) taking offshore team captive aka BOT option www.synerzip.com / www.threebeacons.com 2011 46
Synerzip Clients www.synerzip.com / www.threebeacons.com 2011 47
Thank You! Call Us for a Free Consultation! Agile Software Product Development Partner www.synerzip.com Hemant Elhence hemant@synerzip.com 469.322.0349 www.threebeacons.com Michael Hall mike@threebeacons.com 214.783.3936 www.synerzip.com / www.threebeacons.com 2011 48