In Praise of ScrumPLOP

It seems like there's a bit of Scrum-hate going on. As if something is fundamentally wrong with it. As if the proponents of Scrum are out of their minds.

Personally, I love XP and believe that Modern Agile, mob programming, and #no-estimates are all awesome and should be taken seriously. I also believe that Scrum still offers value. What folks are usually hating on are actually very bad implementations of Scrum. Arlo Belshee calls Scrum "the gateway drug to Agile." Obviously, there's a whole lot more to Agile than Scrum alone (something like 40+ practices at last count.) Don't just hate Scrum because it's the most popular kid in the school. Granted, some criticism is valid and can be tackled in a civil manner. Perhaps it should be directed at the perpetrators of bad Scrum and not a wholesale "Scrum makes me dumb" manner.

Agile got popular because of Scrum and because there are some extremely smart people behind it. However, like one of my friends says, one of the worst things that can happen to a good thing is that it gets popular. And what he meant was that people gloss over the details and don't understand the "why;" they simply start using something just because everyone else is.

Part of it stems from folks taking a two-day course and an open book exam and becoming "masters" of Scrum. There's a lack of understanding of the "why" behind Scrum. I'd like to propose a resource to bridge this gap in understanding.

Meet ScrumPLoP.org

ScrumPLoP stands for Scrum Pattern Languages of Programs. Here's their mission:

Alistair Cockburn describes software development as a cooperative game. Scrum provides one set of rules for one such way of playing the game. The Scrum Guide is the official rule book. However, the Scrum Guide doesn't tell you the rationale behind Scrum as a whole, or behind many of its successful practices. Those rationales come out of experience, community, and the insights of its founders and inventors. The ScrumPLoP mission is to build a body of pattern literature around those communities, describing those insights, so we can easily share them with the Scrum and Agile communities.

Arriving at a Common Language

Pattern languages are not new. However, many of the modern interpretations can be traced back to the work done by Christopher Alexander and his 1977 book A Pattern Language. Although his focus was on buildings and not software, his work paved the way to much of the work that led to the famous Gang of Four book Design Patterns. Software patterns have existed since the late 80s and provide the essential benefit of a common terminology for a particular scenario. In other words, a singleton design pattern signifies the use of single object so all developers familiar with single design pattern will make use of single object and they can tell each other that the program is following a singleton pattern. (Don't worry if you didn't understand the previous sentence. Design patterns are contextual for communities of practice.)

What is a Design Pattern?

A design pattern is a "named solution" to a problem in a context. It is reusable design knowledge and is object-oriented. The name is important because it allows designers to refer to it.

It's important to note that there is no standard for patterns. There are multiple publications and multiple forms of description. Most designers will refer to the Gang of Four (GoF) patterns.

Scrum as a Pattern Language

Scrum itself is a pattern language with ceremonies and artifacts that exist to create a framework. The graphic below shows the Scrum Pattern Language Lattice (Coplien = yellow, Scrum=blue.)

ScrumPLoP in a Nutshell

ScrumPLoP offers rationales and experiences in a pattern form, allows the community a large to submit patterns, and has annual conferences to review and publish those patterns.

Where to start?

Jeff Sutherland (the co-founder of Scrum) has authored some of the most-used Scrum patterns, including the following nine to get teams to lift-off from a strong foundation:

1.  How do you get started? (Stable Teams)

2.  How do you successfully pull backlog items into a Sprint? (Yesterday's Weather)

3.  How do you get stuff done? (Swarming: One-Piece Continuous Flow)

4.  How do you deal with interruptions during the Sprint? (Illegitimus non Interruptus)

5.  How do make sure you’re defect free at the end of the Sprint? (Daily Clean Code)

6.  How do you deal with surprises? (Emergency Procedure)

7.  How do you ensure you continuously improve? (Scrumming the Scrum)

8.  How do you get teams to have fun? (Happiness Metric)

9.  How do you become hyperproductive? (Teams that finish early accelerate faster)

All of these patterns are aimed at increasing productivity and improving the team’s relationships with each other and with the work. This is a living library and every year more patterns get added.

But wait... there's more

As the saying goes, you can master anything with study and practice.

I'll leave you with the following quote on the concept of "Perfect," just to give you something to think about.

“In software development, ‘perfect’ is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories.” - Kent Beck