Secrets of Scrum

Secrets of ScrumGertrud Bjrnvig & James CoplienGertrud & Cope

G&CRainstorm

G&CA. The VisionScrums inspiration draws on the same spirit as Alexanders patternsCommon ancient roots of patterns and ScrumLocal adaptation, self-organisation, and piecemeal growthExcellence: Kaizen mind and value, the Quality Without a NameLong-term stable forms rather than fashion or exigenciesMaking it your own by writing your own patterns

G&CThe Context

AlfredKroeber

1948

19931977

20012004

LaoTzu

500 BC

Ken Schwaber

1993

G&C

Six years later

G&C

Ademar Aguiar

Veli Pekka Eloranta

Mike Beedle

Gertrud Bjrnvig

Jens stergaard

Dina Friis

Ville Reijonen

Neil Harrison

Kiro Harada

Cesrio Ramos

Evan Leonard

Jim Coplien

Jeff Sutherland

Gabrielle Benefield

Lachlan Heasman

Alan OCallaghan

Joe Yoder

G&C

A Pattern: STAND-UP MEETING

G&CDEVELOPING IN PAIRSSoftware development is mistake-proneReviews are insufficientAllow, but dont force people to work in pairs

G&CPatterns: Time-proven formsTom Gilb: A term coined by Jim Coplien in 1995.Trygve Reenskaug: Anne Lise Skaar and I did a large (75000 lines Smalltalk code) project combining 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 and wrote 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 technique from P. J. Plauger who used it as a production programming technique at Whitesmiths Ltd., where I saw 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 (which had 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't afford to get very many of them Consequently, Plauger told the motley crew of programmers in our place that they should pair up and share the terminals; it simply reflected the fact that hardware was still more expensive than people.Jerry Weinberg: I learned to pair program (on paper--we didn't even have terminals back in the 1950s) in Los Angeles, from Bernie Dimsdale, who learned it from John von Neuman. I don't know if it 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 certainly have no involvement with it at all.

G&CWhat is a pattern language?No pattern stands alonePatterns refine other patternsThe basic building blocks come from real practice like Scrum, patterns are empiricalWe bring community together to build the languagesPatterns are discovered, not invented

G&C

ASequence

G&CThe notion of LanguageConsider the three sequences:A B D CA B C D FA E FEach sequence builds one of a set of related wholesWe can create a shorthand for the three sequences:This grammar is called a pattern language. Every pattern is part of a pattern languageABDEFC

G&CScrum as patterns from the Organizational Patterns book

G&C

G&C

Scrum is, in fact, very complex! Here is a breakdown of Scrum into the Organizational Patterns it comprises. This graph shows one set of paths to implementing Scrum in a low-risk way, one organizational pattern at a time. These patterns go to the deep structure of Scrum that make it work.

However, we can view Scrum from another perspective, which is closer to the process perspective more commonly adopted by process formalists and managers. That perspective is easier to understand but tends to hide the fact that Scrum is hard. Well start with the simpler description so we have a shared model of understanding and then will come back to some of the difficult points.

Product BacklogSprint BacklogVacation PBIRelease Staging LayersProduct RoadmapRelease RangeRelease PlanRunning Average VelocityFixed-Date PBIDefinition of DoneRegular Product IncrementChange for FreeValue StreamSprintEstimation PointsDaily Clean CodeEnabling SpecificationsMoney for NothingProduct Backlog ItemsAggregate VelocityRefined BacklogGranularity GradientROIDefinition of ReadySmall Items to EstimateHigh Value First

G&CB. Some Basic Scrum Patterns

G&CStable TeamsStakeholders want to know when the product is estimated to be delivered, so we want to optimize our ability to predict.Therefore,Keep teams stable and avoid shuffling people around between teams. Stable teams tend to get to know their capacity, which makes it possible for the business to have some predictability. Team members should be dedicated to a single team whenever possible.

G&CCross-Functional TeamOrganizations often organize around areas of competence: birds of a feather flock together. Yet, it is costly to coordinate these functions across team boundaries.Therefore: Teams should comprise all talent necessary to deliver Done functionality.

G&CFirewalls

an organization of developers has formed in a corporate or social context where they are scrutinized by peers, funders, customers, and other outsiders. Project implementors are often distracted by outsiders who feel a need to offer input and criticism. * * *Its important to placate stakeholders who feel a need to help by having access to low levels of the project, without distracting developers and others who are moving toward project completion. ...

Isolationism doesnt work: information flow is important. But communication overhead goes up non-linearly with the number of external collaborators.Many interruptions are noise.Maturity and progress are more highly correlated with being in control than being effectively controlled.

Therefore:Create a MANAGER ROLE, who shields other development personnel from interaction with external roles. The responsibility of this role is to keep the pests away.

G&C

G&CEnabling SpecificationUnexplored requirements cause unpleasant surprises.It's easy to throw requirements over the wall and say: "That requirement was covered." It's even easier in Scrum. Their user stories are enough. And the Agile culture encourages deferring decisions and a ready, at-hand on-site customer who can compensate for requirements lapses during development.Therefore: The Product Owner should deliver enabling specifications as a sign that he or she has done due diligence in exploring the requirements space. "Enabling specification" means that the specification is rich enough that someone reasonably skilled in the discipline can implement a solution without substantial subsequent clarification.Scrum secret:There are noUser Stories inScrum, and itsnot about writing!

G&CDefinition of Ready

G&C

Go to the Beach

Emergency ProcedureScrum strives to master uncertainty in a complex environment. Bad things can happenTherefore: Escalate quickly to the point of stopping the line, to assess status quo before moving forward

G&CEmergency ProcedureContext:Companies, teams, and individuals often find their efforts failing to deliver on time and the Sprint burndown shows that failure is virtually certain. Rapid identification of problems and quick response is fundamental to the spirit of agility. Causes of Sprint dysfunction are legion and their patterns is primarily focused on 1-3 below:Emergent requirementsTechnical problemsLoss of critical people or capabilitiesOverestimated capacity (use Yesterdays Weather)Unplanned interrupts (use Illegitimus non Interruptus)Previous work not done (use Definition of Done)Product owner changes backlog (use Product Owner)Management interference (use Involve the Managers)

G&CEmergency ProcedureEmergency Procedure: (do only as much as necessary)Change the way the work is done. Do something different.Get help, usually by offloading backlog to someone else.Reduce scopeAbort the sprint and replanInform management how release dates will be affected

G&CYesterdays WeatherGuessing when you will be done with a complex task is always a dicey propositionYet complex stochastic processes have norms that are dependable, on the averageTherefore: Use the last Sprint, or the trend of the most recent Sprints, to determine how much work to take into the next one.

G&CC. Some Scrum Secrets

G&CSpirit of the GameRules can be written, but spirit is part of culture that guides interactions and may only be discerned when ignored or violatedWe can give examples that are not in contradiction with the Scrum Guide (Sutherland & Schwaber, 2012) but neither are they in the spirit of the Agile Manifesto and its 16 principles. As Scrum is under the umbrella of these values we see how these examples break at least one principle. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."Therefore:When using Scrum there needs to be a focus on explicitly creating a culture in the organization where people know and follow the spirit of Scrum.

G&CDeveloper-Ordered WorkplanTherefore: Let the team self-organise to best optimise the chances of meeting the Sprint Goal

Scrum secret:The heart ofself-organisation!

G&CDaily Scrum?Whats it for?

Scrum Secret: Thepurpose of the DailyScrum is to re-planthe Sprint every day.

G&CExercise

G&CSwarmingWorking on too many things at once leads to radical reduction in the velocity of an individual, a team, or a company. It can cut velocity by 50% and sometimes reduce it to zero.Therefore:Focus maximum team effort on one item in the Sprint 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 no one can interrupt the Captain. As soon as the Captain is Done, whoever takes responsibility for the next priority backlog item is Captain.

G&CScrum Team: One mindNo testersNo DB peopleNo codersNo HCI people ideally.Minimize coordination between teams!

G&CHappiness MetricIn reflection and other self-improvement activities, there are generally many ideas for improvement. But you often dont know in advance which improvement activities will produce great benefits, and which will not.Therefore:Find out what one improvement will increase the happiness of the team the most, and implement that improvement in the next Sprint.

G&CScrumming the ScrumIdentify the single most important impediment at the Sprint Retrospective and remove it before the end of the next Sprint.

G&CWhack the MoleBugs can appear at any timeZero defect tolerance says you need to fix them eventually. They get in your way until you fix themTherefore: Fix bugs when they arise!

G&CDaily Clean CodeVelocity is limited because a team spends time dealing with too many bugs.However, keeping a bug list causes numerous problems In short, deferring the fixing of bugs until later is borrowing against your future velocity.Therefore:Fix all bugs in less than a day. Aim to have a completely clean base of code at the end of every day.

G&CDependencies FirstThe team orders theSprint Backlogto reflect known dependencies at the beginning of theSprint, but the variance in the effort necessary to realizePBIdelivery, and to re-plan due to Emergent Requirements, can push dependency resolution too late in theSprintand can thereby increase the risk that the dependency will causePBIs to be inadvertently dropped.Therefore:Make sure that all foreseen dependencies are in-hand by mid-Sprint; otherwise, abort theSprint.

G&CIllegitimus Non InterruptusAllot 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 to avoid disrupting production.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 by unplanned work coming into theSprintunexpectedly. If the team velocity averages 60 points, 20 points will be reserved for the interrupt buffer.All requests must go through theProduct Ownerfor triage. TheProduct Ownerwill give some items low priority if there is no perceived value relative to the business plan. Many other items will be pushed to subsequentSprintseven if they have immediate value. A few items are critical and must be done in the currentSprint, so they are put into the interrupt buffer by theProduct Owner.If the buffer starts to overflow, i.e. theProduct Ownerputs one point more than 20 points into theSprint, the team must automatically abort, theSprintmust be re-planned, and management is notified that dates will slip.

G&CA Scrum SecretKaizen mind is tough love!

G&CExercise!

G&C"" Oyatsu Jinja (Snack Shrine)The Team finds itself supporting occasional interruptions from the Product Owner, other teams, and other stakeholders, who need their attention. Yet the team should be focused during a SprintTherefore: Put some snacks near the team, where visitors can wait. The team can attend to the diversion according to priority and work loadCreates ba rather than just a chance encounter (like Water Cooler)

G&CTeams that Finish Early Accelerate FasterTeams often take too much work into a sprint and cannot finish it. Failure prevents the team from improving.Teams can be optimistic about their ability to finish requested features. But in doing so, they fail to give themselves time to reduce technical debt and sharpen their saws. Thus they are doomed to a persistently slow pace.Therefore:Take less work into a sprint.Maximize your probability of success by using the pattern Yesterdays Weather. Then implement Illegitimus non Interruptuswhich will systematically deal with any interruptions cause you to finish early.

G&CJeffs Secret Sauce for HyperproductivityHow 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)

G&CThis is a Pattern Language!The patterns work togetherThey form a whole

G&CD. Do this at home

G&CDoing patterns at homeUnderstanding the patterns foundations leads to a deeper appreciation for Scrum principlesTry this:A short introduction to patternsRead the Scrum patternsCome together once a month in community to review each others Scrum patternsUse it for your retrospective once in a whileIntroduce the patterns (see next slide)Get involved in the broader community

G&CIntroduce the patternsThe Fundamental Process:Find the weakest place in your organisationFind a pattern that can repair, or strengthen, that weakness every pattern is an act of repairTry the patternMeasure its effectiveness with mind and heartIf the system is less Whole, try another pattern

G&CMeasure its effectiveness with mind and heartTheres something deep going on hereAlexander calls it The Quality Without a Name or WholenessNeil and I could feel it in the great organisations we studied, and learned to recognise it in the geometry of the organisations.Both developing a sense for this geometry, and achieving the geometry, are career-long journeys

G&CExerciseWrite your OWN Scrum Pattern!Good organisations grow their own Pattern Language

G&CReferencesThe 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), pages 125-133, February 1993. Los Alamitos, California, IEEE Computer Press.Kroeber, Alfred. Culture, patterns and processes. New York: Harcourt, Brace and World, 1963 (1948).

G&C

G&C