ScrumPLoP is a PLoP® conference. It will be a gathering of experienced Scrum practitioners, assembled with the goal of contributing to the body of pattern literature with proven practices. If you don't yet know what a PLoP conference is, read about what a PLoP is.
The community does work at a PLoP. To "present" a paper means to submit it to the conference for review within the conference's community of trust, so that the author can improve the work on its journey to public influence. Each day will feature several writers' workshops where the work of the conference takes place. In between time, there will be plenty of opportunity for socializing, walks in the woods, and sitting around the fireplace in the evening.
Scrum is just a framework; it doesn't tell you what to do. It captures the recurring structures and patterns important to the success of enterprises that build product. In fact, some parts of Scrum (and more broadly, of agile in general) were influenced by early pattern work. However, because it is just a framework, most Scrum literature distances itself from specific practices germane to any specific application discipline such as, for example, software development. Scrum has been around long enough (since ca. 1993) that we have enough experiences that we can reflect and collect practices that have earned our confidence. We will gather those practices in community, and deliver the results to the community.
We have already identified patterns closely linked to the Scrum framework (http://www.scrumorgpatterns.com). We suspect that there are more — in the areas of Scrum organizations, in the management of the Product Backlog, and in other Scrum structures. Your experience can help us identify and collect those patterns as a community.
The goal is to produce a book of Scrum pattern languages. Conference submissions should be in pattern form. The conference prefers submissions in one of the standard pattern forms (in order of preference: Alexandrian form, Portland form, canonical form, and other forms). Authors should strive to move beyond simple, isolated patterns to small pattern languages, or to link small sets of patterns into the previously published Scrum patterns. Authors may also submit one or two complete patterns complemented by patlets for supporting patterns.
A pattern, simplistically put, is a solution to a problem in a context. In the same sense that a Scrum effort always builds something, a pattern always builds something. What we "build" may be a team, or a gathering of people at an event, or part of a value stream. We will be seeking such patterns at ScrumPLoP: real solutions to common problems that arise in different contexts.
Solution
A pattern presents a proven broad solution. While reading a pattern, a designer gains the inspiration to know exactly what to build. The pattern inspires the form of the solution; the designer creatively tailors the form into a specific structure. A pattern gains its readers' confidence through substantiation, argumentation, and literary devices. A good pattern is a convincing piece of literature, grounded in experience and substantiation. Ideally, a pattern has three citable prior uses or formally can be proven to have worth. It is not a research postulate: it must have both broad substantiation and broad applicability.
Problem
Patterns solve problems. A problem is a statement of the difference between the current state and a desired state. It often takes many solutions to address a complex problem, and a given pattern may solve may problems. However, each pattern balances a set of tradeoffs called forces in a way that allows the system to come to terms with itself. Pattern problems are easily recognized, and are concrete enough that there is no doubt whether a given system has the given problem or not.
Context
There are many different forms in Scrum. A Product Backlog has form; so might a Sprint Backlog. There is form in the relationships between team roles. Use your imagination. As we create these forms (as we build a product, or a backlog, or a Scrum team, or an enterprise based on Scrum) we apply one pattern at a time. The state of one of these formed entities at any point in its evolution defines a Context in which problems might arise, and to which solutions might be applied.
Sequences
Sequences are stories about the growth of a system through a successive application of patterns. A good pattern language usually is supported by one or more sequences.
Over time, you experience sequence after sequence and can start to identify what patterns must be present before another pattern can be applied. You can describe that precedence in a graph. The graph, including its patterns, is called a pattern language. A patten language is a description of the overall form of a family of systems.
No pattern exists in isolation. No pattern exists apart from its context in a pattern language. The goal of ScrumPLoP is to build a pattern language. That doesn't mean that we exclude individual patterns, but patterns must be able to fit into what will be a small number of pattern languages that emerge over the next two years. We encourage authors to submit pattern language fragments or sequences to help us in this goal.
This year, we are accepting new submissions to grow the body of Scrum patterns. We have a particular interest in areas that deepen parts of the Scrum framework, such as:
Product Owner and Product Owner Team patterns
Patterns relating the the Scrum Team's relationship to the broader enterprise
Patterns related to broad techniques such as set-based design, end-user engagement, ...
Patterns that support Scrum team education and learning
Patterns related to interaction between the Scrum Team and the end-user and market constituency during deployment (eliminating DevOps organizations)
We will build on the cohesive Community of Trust we have been building since 2010 but look to expand the community with fresh ideas from a crowd of first-time attendees.