1. Secrets of ScrumGertrud Bjrnvig & James CoplienGertrud & Cope

2. Rainstorm 3. A. The Vision Scrums inspiration draws on the same spirit as Alexanderspatterns Common ancient roots of patterns and Scrum Local adaptation, self-organisation, and piecemeal growth Excellence: Kaizen mind and value, the Quality Without a Name Long-term stable forms rather than fashion or exigencies Making it your own by writing your own patterns 4. The ContextAlfredKroeber19481993197720012004LaoTzu500 BCKen Schwaber1993 5. Six years later 6. Ademar AguiarVeli Pekka ElorantaMike BeedleDina FriisGertrud BjrnvigJens stergaardEvan LeonardVille ReijonenNeil HarrisonKiro HaradaCesrio RamosJim CoplienJeff SutherlandLachlan HeasmanGabrielle BenefieldAlan OCallaghanJoe Yoder 7. A Pattern: STAND-UP MEETING 8. DEVELOPING IN PAIRS Softwaredevelopment ismistake-prone Reviews areinsufficientAllow, but dontforce people towork in pairs 9. Patterns: Time-proven forms Tom Gilb: A term coined by Jim Coplien in 1995. Trygve Reenskaug: Anne Lise Skaar and I did a large (75000 lines Smalltalk code) projectcombining literate programming and pair programming in the middle to late 80ties. Larry Constantine: My name comes up in connection with pair programming because I taught andwrote about the practice ("The Benefits of Visibility" Computer Language Magazine 9, 2, 1992)years before the advent of agile, but I most decidedly did not invent it. I learned about the techniquefrom P. J. Plauger who used it as a production programming technique at Whitesmiths Ltd., where Isaw it in 1978 or 1979 being used to code C compilers for the PDP-11. Ed Yourdon: PJ Plauger was instrumental in persuading me to get UNIX in our company (whichhad a $10,000 license fee at the time, a sum of money which Plauger lent the company, interest-free!).And even the dumb typewriter-like terminals at the time cost about $3,000 -- so we couldn'tafford to get very many of them Consequently, Plauger told the motley crew of programmers inour place that they should pair up and share the terminals; it simply reflected the fact thathardware was still more expensive than people. Jerry Weinberg: I learned to pair program (on paper--we didn't even have terminals back in the1950s) in Los Angeles, from Bernie Dimsdale, who learned it from John von Neuman. I don't know ifit has any history before then, but that's way back to Aberdeen Proving Grounds in the 40s. Ed Yourdon again: It's gonna go all the way back to Charles Babbage, or Lady Lovelace! Brian Kernighan: I have no recollection of any of the history of pair programming, and I certainlyhave no involvement with it at all. 10. What is a pattern language? No pattern stands alone Patterns refine other patterns The basic building blocks come from real practice like Scrum, patterns are empirical We bring community together to build thelanguages Patterns are discovered, not invented 11. ASequence 12. The notion of Language Consider the three sequences: A B D C A B C D F A E F Each sequence builds one of a set of related wholes We can create a shorthand for the three sequences: This grammar is calleda pattern language.Every pattern is part ofa pattern languageABDEFC 13. Product BacklogProductRoadmapSprint BacklogRefined BacklogVacation PBIRelease StagingLayersRelease PlanRelease RangeRunning AverageVelocityFixed-Date PBIDefinition ofDoneRegular ProductIncrementChange for FreeValue StreamSprintEstimationPointsDaily CleanCodeEnablingSpecificationsMoney forNothingProduct BacklogItemsAggregateVelocityGranularityGradientROIDefinition ofReadySmall Items toEstimateHigh Value First 14. B. Some Basic ScrumPatterns 15. STABLE TEAMS Stakeholders want to know when theproduct is estimated to be delivered, sowe want to optimize our ability to predict. Therefore, Keep teams stable and avoid shufflingpeople around between teams. Stableteams tend to get to know their capacity,which makes it possible for the businessto have some predictability. Teammembers should be dedicated to a singleteam whenever possible. 16. CROSS-FUNCTIONALTEAM Organizations often organizearound areas of competence:birds of a feather flocktogether. Yet, it is costly tocoordinate these functionsacross team boundaries. Therefore: Teams shouldcomprise all talent necessaryto deliver Done functionality. 17. G&CFIREWALLSan organization of developers has formed in a corporate or socialcontext where they are scrutinized by peers, funders, customers, andother outsiders. Project implementors are often distracted by outsiderswho feel a need to offer input and criticism.* * *Its important to placate stakeholders who feel a need to help byhaving access to low levels of the project, without distractingdevelopers and others who are moving toward project completion. ...Isolationism doesnt work: information flow is important. Butcommunication overhead goes up non-linearly with the number ofexternal collaborators.Many interruptions are noise.Maturity and progress are more highly correlated with being in controlthan being effectively controlled.Therefore:Create a MANAGER ROLE, who shields other development personnel frominteraction with external roles. The responsibility of this role is to keepthe pests away. 18. ENABLING SPECIFICATION Unexplored requirements cause unpleasantsurprises. It's easy to throw requirements over the wall and say:"That requirement was covered." It's even easier inScrum. Their user stories are enough. And the Agileculture encourages deferring decisions and a ready,at-hand on-site customer who can compensate forrequirements lapses during development. Therefore: The Product Owner should deliverenabling specifications as a sign that he or shehas done due diligence in exploring therequirements space. "Enabling specification" meansthat the specification is rich enough that someonereasonably skilled in the discipline can implement asolution without substantial subsequent clarification.Scrum secret:There are noUser Stories inScrum, and itsnot about writing! 19. DEFINITION OF READY 20. EMERGENCY PROCEDURE Scrum strives to masteruncertainty in a complexenvironment. Bad things canhappen Therefore: Escalate quickly to thepoint of stopping the line, toassess status quo before movingforward 21. EMERGENCY PROCEDUREContext:Companies, teams, and individuals often find their efforts failing to deliveron time and the Sprint burndown shows that failure is virtually certain.Rapid identification of problems and quick response is fundamental to thespirit of agility. Causes of Sprint dysfunction are legion and their patternsis primarily focused on 1-3 below:1. Emergent requirements2. Technical problems3. Loss of critical people or capabilities4. Overestimated capacity (use YESTERDAYS WEATHER)5. Unplanned interrupts (use ILLEGITIMUS NON INTERRUPTUS)6. Previous work not done (use DEFINITION OF DONE)7. Product owner changes backlog (use PRODUCT OWNER)8. Management interference (use INVOLVE THE MANAGERS) 22. EMERGENCY PROCEDURE Emergency Procedure: (do only as much as necessary)1. Change the way the work is done. Do somethingdifferent.2. Get help, usually by offloading backlog to someoneelse.3. Reduce scope4. Abort the sprint and replan5. Inform management how release dates will be affected 23. YESTERDAYS WEATHER Guessing when you will be done with acomplex task is always a diceyproposition Yet complex stochastic processes havenorms that are dependable, on theaverage Therefore: Use the last Sprint, or thetrend of the most recent Sprints, todetermine how much work to take intothe next one. 24. C. Some ScrumSecrets 25. SPIRIT OF THE GAME Rules can be written, but spirit is part of culture that guidesinteractions and may only be discerned when ignored orviolated We can give examples that are not in contradiction with theScrum Guide (Sutherland & Schwaber, 2012) but neither arethey in the spirit of the Agile Manifesto and its 16 principles.As Scrum is under the umbrella of these values we see howthese examples break at least one principle. "Build projectsaround motivated individuals. Give them the environment andsupport they need, and trust them to get the job done." Therefore: When using Scrum there needs to be a focus on explicitlycreating a culture in the organization where people know andfollow the spirit of Scrum. 26. DEVELOPER-ORDERED WORKPLANScrum secret:The heart ofself-organisation! Therefore: Let the team self-organise to bestoptimise the chances of meeting the Sprint Goal 27. DAILY SCRUM? Whats it for?Scrum Secret: Thepurpose of the DailyScrum is to re-planthe Sprint every day. 28. Exercise 29. SWARMING Working on too many things at once leads to radicalreduction in the velocity of an individual, a team, ora company. It can cut velocity by 50% andsometimes reduce it to zero. Therefore: Focus maximum team effort on one item in theSprint Backlog and get it done as soon as possible.Whoever takes this item is Captain of the team.Everyone must help the Captain if they can and noone can interrupt the Captain. As soon as theCaptain is Done, whoever takes responsibility forthe next priority backlog item is Captain. 30. Scrum Team: One mind No testers No DB people No coders No HCI people ideally. Minimize coordination between teams! 31. HAPPINESS METRIC In reflection and other self-improvementactivities, there are generally manyideas for improvement. But you oftendont know in advance whichimprovement activities will produce greatbenefits, and which will not. Therefore: Find out what one improvement willincrease the happiness of the team themost, and implement that improvementin the next Sprint. 32. SCRUMMING THE SCRUM Identify the single most important impediment atthe Sprint Retrospective and remove it before theend of the next Sprint. 33. WHACK THE MOLE Bugs can appear at any time Zero defect tolerance says youneed to fix them eventually.They get in your way until you fixthem Therefore: Fix bugs when theyarise! 34. DEPENDENCIES FIRST The team orders the Sprint Backlog to reflectknown dependencies at the beginning ofthe Sprint, but the variance in the effortnecessary to realize PBI delivery, and to re-plandue to Emergent Requirements, canpush dependency resolution too late inthe Sprint and can thereby increase the riskthat the dependency will cause PBIs to beinadvertently dropped. Therefore: Make sure that all foreseen dependencies arein-hand by mid-Sprint; otherwise, abortthe Sprint. 35. ILLEGITIMUS NONINTERRUPTUS Allot time for interrupts and do not allow the time to be exceeded. Set up three simple rules that will cause the company to self-organize toavoid disrupting production.1. The team creates a buffer for unexpected items based on historical data.For example, 30% of the team's work on the average is caused byunplanned work coming into the Sprint unexpectedly. If the team velocityaverages 60 points, 20 points will be reserved for the interrupt buffer.2. All requests must go through the Product Owner for triage. The ProductOwner will give some items low priority if there is no perceived valuerelative to the business plan. Many other items will be pushed tosubsequent Sprints even if they have immediate value. A few items arecritical and must be done in the current Sprint, so they are put into theinterrupt buffer by the Product Owner.3. If the buffer starts to overflow, i.e. the Product Owner puts one point morethan 20 points into the Sprint, the team must automatically abort,the Sprint must be re-planned, and management is notified that dates willslip. 36. A Scrum Secret Kaizen mind is tough love! 37. Exercise! 38. "" Oyatsu Jinja (SnackShrine) The Team finds itself supporting occasionalinterruptions from the Product Owner, otherteams, and other stakeholders, who needtheir attention. Yet the team should befocused during a Sprint Therefore: Put some snacks near the team,where visitors can wait. The team can attendto the diversion according to priority andwork load Creates ba rather than just a chanceencounter (like WATER COOLER) 39. TEAMS THAT FINISH EARLYACCELERATE FASTER Teams often take too much work into a sprint and cannotfinish it. Failure prevents the team from improving. Teams can be optimistic about their ability to finishrequested features. But in doing so, they fail to givethemselves time to reduce technical debt and sharpentheir saws. Thus they are doomed to a persistently slowpace. Therefore: Take less work into a sprint. Maximize your probability of success by using the patternYESTERDAYS WEATHER. Then implement ILLEGITIMUS NONINTERRUPTUS which will systematically deal with anyinterruptions cause you to finish early. 40. Jeffs Secret Sauce forHyperproductivity How do you get started? (STABLE TEAMS) How do you successfully pull backlog items into a Sprint? (YESTERDAY'S WEATHER) How do you get stuff done? (SWARMING: ONE-PIECE CONTINUOUS FLOW) How do you deal with interruptions during the Sprint? (ILLEGITIMUS NON INTERRUPTUS) How do get defect free at the end of the Sprint? (DAILY CLEAN CODE) How do you deal with surprises? (EMERGENCY PROCEDURE) How do you ensure you continuously improve? (SCRUMMING THE SCRUM) How do you get teams to have fun? (HAPPINESS METRIC) How do you get hyperproductive? (TEAMS THAT FINISH EARLY ACCELERATE FASTER) 41. This is a Pattern Language! The patterns work together They form a whole 42. D. Do this at home 43. Doing patterns at home Understanding the patterns foundations leads to a deeper appreciation forScrum principles Try this:1. A short introduction to patterns2. Read the Scrum patterns3. Come together once a month in community to review each others Scrumpatterns4. Use it for your retrospective once in a while5. Introduce the patterns (see next slide)6. Get involved in the broader community 44. Introduce the patterns The Fundamental Process:1. Find the weakest place in your organisation2. Find a pattern that can repair, or strengthen, thatweakness every pattern is an act of repair3. Try the pattern4. Measure its effectiveness with mind and heart5. If the system is less Whole, try another pattern 45. Measure its effectivenesswith mind and heart Theres something deep going on here Alexander calls it The Quality Without a Name orWholeness Neil and I could feel it in the great organisationswe studied, and learned to recognise it in thegeometry of the organisations. Both developing a sense for this geometry, andachieving the geometry, are career-long journeys 46. Exercise Write your OWN Scrum Pattern! Good organisations grow their own PatternLanguage 47. References The ScrumPLoP site: http://www.scrumplop.org. The Original Organizational Patterns, http://orgpatterns.wikispaces.com. Scrum as based on those patterns, http://www.scrumorgpatterns.com. Coplien &Harrison, Organizational Patterns of Agile Software Development, Prentice-Hall, 2004. Alexander, A Pattern Language, Oxford, 1977. Alexander, The Timeless Way of Building, 1979. Beedle and Schwaber, Agile Software Development with Scrum, Addison-Wesley, Reading, MA,2001. Brendan G. Cain and James O. Coplien. A Role-Based Empirical Process Modeling Environment.In Proceedings of Second International Conference on the Software Process (ICSP-2), pages125-133, February 1993. Los Alamitos, California, IEEE Computer Press. Kroeber, Alfred. Culture, patterns and processes. New York: Harcourt, Brace and World, 1963(1948).