ScrumPLoP 2016 Call for Participation

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.

Patterns of Scrum

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 in about two years. Conference submissions should be in pattern form. The conference prefers submissions in one of the standard pattern forms (in order of preference: Portland form, Alexandrian form, canonical form, and other forms) but encourages authors to use a form that best suits the goal of their pattern. Authors should strive to move beyond simple, isolated patterns to small pattern languages, perhaps by submitting one or two complete patterns complemented by patlets for supporting patterns.

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. 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.

Pattern Languages

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.

Submissions

Most submissions will follow the usual PLoP cycle. The deadlines of this cycle will be posted in the conference calendar. Most authors will be assigned a shepherd who will work with them through three iterations to refine the manuscript. Submissions will be accepted for review in a conference writers' workshop if approved by the conference committee, and if the authors agree to the submission guidelines. After the conference, you are expected to incorporate relevant feedback into your paper and to re-submit it before the posted deadline. The conference committee will make a separate decision about which final patterns will be collected into a published book.