Patterns of Scrum: Keys to Understanding Effective Scrum- ming

1. Patterns of Scrum:Keys to Understanding Effective Scrum-ming Neil B. Harrison Utah Valley University

2. TalkMap • Who • And a bit of history • What we are doing • Creating a pattern language of Scrum • A few words about what patterns are … • Why • Why is the pattern language so important • Main Course (the patterns) • Some key Scrum patterns so far • What next, when, etc. • And how you can be involved

3. Cast of Characters • Jeff Sutherland • Jim Coplien – Organizational Pattern author, co-controller of Scrum Guide • Mike Beedle – Early co-developer of Scrum • Neil Harrison – Organizational Pattern author • AdemarAguiar, Gabrielle Benefield, Gertrude Bjørnvig, Veli-PekkaEloranta, Dina Friis, Dan Greening, Kiro Harada, Lachlan Heesman, Ville Mäkinen, Jens Østergaard

4. A Bit of History • Working together for over two years • Regular face-to-face workshops • Lots of Skype, Google docs, email, etc. • Organizational Patterns • Early organizational foundation of Scrum • 1993-2004 • Collected chiefly by Coplien and Harrison • Form the model for the Scrum patterns

5. A Few Words About Patterns… • What are Patterns? • 23 Rules for Object-Oriented Design, Right? • Um, no • A Pattern Is: • Something you build (and instructions how to build it) • A solution to a small problem of a complex system • A contributor to the quality of life • A Scrum/Organizational Pattern • Changes communication paths • Changes organizational culture

6. Solving Problems • Patterns are not rules to be blindly followed • Patterns solve problems at the deep, systemic level • Patterns explore: • The nature of the problem • The forces that interact that effect the problem (make it hard) • The solution: • Why it works • Under what conditions it works • The resulting context

7. Why Do we Need Scrum Patterns? • Scrum is: • Lightweight • Simple to Understand • Extremely difficult to master - Scrum Guide, p. 3

8. Simple to Understand …

9. Extremely Difficult to Master • Many teams do Scrum poorly • Or say they are doing Scrum, but aren’t • A (small) sample of war stories • Insanity in Sprints • Scrum Master as Thor’s Hammer • The Scrum Master in the Candy Store • A Fool with a Tool • One reason: • They follow the steps, but don’t know why • Understanding the Why is crucial

10. The Scrum Patterns Project • Identify the patterns of successful Scrum teams • Organize them into pattern languages • Will be published (goal: draft next Spring) • So far: • About 160 patterns identified • Drafts of many have been written • Over 50 workshopped (reviewed) and revised

11. Pattern Languages (so far) • Value Stream • Managing the value stream, including estimation, backlog, release planning, etc. • Process Improvement/Retrospective • How to improve, including reviews and retrospective patterns • Team • How the team is organized and works together. There is a Scrum Master sub-language • Product Organization • Especially Product Owner patterns • Scaling Scrum • Distributed Scrum • Change Management • Changing from a traditional to a Scrum organization • Scrum Core • Basic Scrum knowledge (status uncertain)

12. Organization Pattern Foundation • Patterns that form the organizational basis for Scrum • Many • Three examples follow • Note how they highlight the “why” … Note: The patterns are very abbreviated, which removes some of the “whys” 

13. Work Flows Inward ... an organization is in place and has been doing work long enough that it can introspect about its structure and workings. ... * * * An organization must seek a structure that best insures that the most authoritative roles make the decisions and carry out the work that adds value directly to the product. ... During software production, the work bottleneck of a system should be at the center of its communication and control structure. If the communication center of the organization generates more work than it does work, then organization performance can become unpredictable and sporadic... Therefore: Work should be generated by stakeholders, especially Customers, filter through supporting roles, and be carried out by implementation experts at the center. You should not put managers at the center of the communication grid: they will become overloaded and make decisions that are less well-considered, and they will make decisions that do not take day-to-day dynamics into account. ... Problem Problem Insight The “Why”

14. Stand-Up Meeting Insight: it’s not just about making assignments

15. Firewalls A Key role for the Scrum Master …an organization of developers has formed in a corporate or social context where they are scrutinized by peers, funders, customers, and other “outsiders.” Project implementers are often distracted by outsiders who feel a need to offer input and criticism. * * * It’s 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 doesn’t 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.” Insights (forces) that show inherent conflict

16. Scrum Master Patterns • It’s not just running the meetings! • Patterns identified so far: • ScrumMaster • Catalyst • Cheerleader • Coach • DoneMaster • Firewall • Knight of the Mirrors • Sheepdog • Product Owner Trainer

17. Hyperproductive Teams? Jeff Sutherland is putting together a small pattern language that captures the essence of a hyperproductive team: • How do you get started? (Stable team) • How do you successfully pull the backlog into a sprint? (Yesterday’s Weather) • How do you get stuff done? (Get Something Done) • How do you deal with interruptions during the sprint? (Illigitimus non Interruptus) • How do get defect free at the end of the sprint? (Daily Clean Code) • How do you ensure you continuously improve? (Scrumming the Scrum) • How do you get teams to have fun? (Happiness Metric) • How do you become hyperproductive? (Teams that Finish Early Accelerate Faster)

18. Stable Teams In order to run a business based on software development we need some level of predictability. With everything in flux we may decide to “fix” the wrong thing to have this predictability … Predictability and productivity are two mantras in software development. Manage by numbers, a third mantra, is used to support the first two. To optimize productivity and predictability we create the numbers to manage – estimates for tasks, resources allocated to projects to maximize utilization and project plans to schedule the estimates … Having good estimates and a strong project manager ensures predictability … Resource utilization leads to multi-tasking with people distributed across several teams. But the numbers, this is a good result … but will lead to difficulties for the individual who must context switch between teams … Therefore: Keep teams stable and avoid shuffling people between teams. Stable teams get to know their capacity, which makes it possible for the business to have some predictability. … Stable teams get to know each other … When the team knows its capacity it can improve … the only way that a team can get to know their velocity is by being the same team members over a longer period of time … Stable teams create pressure on the pipeline of work. Work will now need to be structured to fit with the teams, rather than teams structured to fit with – or crises. This will, in turn, highlight capability issues that occur within the organization … Insight: a temptation, with consequences explained

19. Daily Clean Code As a team develops the product, bugs are invariably detected. The usual tendency is to write bug reports and put them on a bug list, where they will be fixed at the appropriate time. But this leads to several problems which cause the velocity of the team to bog down. ✥      ✥      ✥ Velocity is limited because a team spends time dealing with too many bugs. It is natural to want to keep a list of bugs. But keeping a bug list causes numerous problems: • Each bug has to be handled at least twice, once when it arrives, and later when it is fixed. • The longer a bug sits before it is fixed, the greater chance there is of losing information about the bug, how to reproduce it, and how to fix it. • Bug lists tend to grow. If they get large, the lowest priority bugs will never get fixed. Therefore: Fix all bugs in less than a day. Have a completely clean base of code at the end of every day. • It reduces the overhead of handling bugs. • It eliminates two separate lists of work to do, making it easier for the team to focus. • It keeps the code clean. Developers won’t be basing code on top of bugs. • It eliminates the need for the periodic “bugathon” or “bug bash”, where the team stops what they are doing to spend time cleaning up the code. From Jeff: Use of this pattern has resulted in a doubling of productivity

20. Illigitimus Non Interruptus Scrum teams are often interrupted during a sprint by changing priorities or problems. The Scrum team is a critical resource for creating new software and maintaining old software. This makes them a central resource to serve the needs of everyone in the company. Often poor product ownership allows competing priorities in a company to reach a Scrum team. Some teams have even been bribed to work on features not in the companies product backlog. Therefore: 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 to avoid disrupting production. • The team creates a buffer for unexpected items based on historical data. •  All requests must go through the Product Owner for triage. •  If the buffer starts to overflow, the team must abort, and management is notified that dates will slip. These rules will invariably cause individuals to self-organize to avoid blowing up a sprint as no individual wants to be seen as the direct cause of sprint failure. Even better, the buffer will tend to never be full, allowing the team to finish early and pull forward from the backlog and/or work on removing impediments. See: Teams That Finish Early, Accelerate Faster. Counter-intuitively, this does not cause critical problems to be hidden or unresolved, The product owner will put any critical items on the backlog. The team will typically double velocity and get twice as much done in future sprints.

21. Scrumming the Scrum Only a small minority of Scrum teams achieve the hyperproductive state. This is because most teams fail to identify and remove impediments. Their software is not done, their backlog is not ready, and the team does not self-organize to improve performance. Therefore: Identify the single most important impediment at the Sprint Retrospective and remove it before the end of the next sprint. To remove it, put it in the Sprint backlog as a user story with acceptance tests that will determine when it is done. Then evaluate the state of the story in the Sprint Review like any other task. Focusing attention on the top priority impediment will have the side effect that the team will self-organize to remove other high priority impediments as well, without losing focus on the highest priority impediment. This pattern assures continuously increasing velocity or sustainable high-level velocity … Hugo Heitz: “They need to put the kaizen in the backlog. They need to Scrum the Scrum. They need to use Scrum to make Scrum better.” Removing the top priority impediment should yield immediate velocity improvement. If not, the team has not properly analyzed system dynamics and understood the root cause of the primary dysfunction.

22. Participation • www.scrumplop.org • (click on “Pattern Spreadsheet”) • Feel free to give comments, even on so-called published patterns. • Do you have patterns you want to write? • Do you want to participate in reviewing patterns, or attending ScrumTulipPLoP? • Contact us: • neil.harrison@uvu.edu(Neil Harrison) • jcoplien@gmail.com (Jim Coplien)

23. Authors • Scrum Diagram: • Mike Cohn, Mountain Goat Software • Work Flows Inward, Stand Up Meeting, Firewalls: • Jim Coplien and Neil Harrison • Stable Teams: • Gertrude Bjørnvig and Lachlan Heasman • Daily Clean Code: • Jeff Sutherland and Neil Harrison • Illigitimus non Interruptus: • Jeff Sutherland • Scrumming the Scrum: • Jeff Sutherland