Cesario Ramos — January 19, 2020 In my first article, I explained what Scrum Patterns are and why they could be useful for you in your transformation. The second article explained how to select the Scrum Patterns from the Pattern Languages.
In this 3rd article, I build on the previous two articles and give an example of how to use the two Pattern Languages to develop your pattern sequence.
How To Create Your Pattern Sequences?
A pattern sequence is the order of patterns in which the organization wants to transform. Organizations create their sequence by selecting the patterns that are most appropriate in their context.
But how can you determine the context? And how do you handle the relationships between the patterns?
Handling the Pattern Relationships
There are two relationships between patterns.
- A pattern can be an alternative to another pattern. Alternative patterns refine a common larger pattern.
- A pattern refines another pattern. The refinement relationship defines a dependency between patterns.
For example: In the graphic below, you can see that Sprint Burndown Chart, Scrum Board, and (January 20, 2020)’s Weather refine Sprint Backlog —a dependency relation. Before applying the Sprint Burndown Chart, I recommended using the Sprint Backlog first.
Also, the patterns Sprint Burndown Chart, Scrum Board, and (January 20, 2020)’s Weather are alternatives to each other —You can try any of those after Sprint Backlog.
For example, these are some valid sequences that are generated by the graphic above:
- Sprint Backlog -> Sprint Burndown Chart -> Scrum Board
- Sprint Backlog -> Sprint Burndown Chart -> (January 20, 2020)’s Weather -> Scrum Board
- Sprint Backlog -> Sprint Burndown Chart -> Information Radiator -> Scrum Board
Finding the context at one of my customers
As mentioned above, you need to understand your current context to selects patterns and form a sequence. A way to determine that is to perform Go-See sessions and help the organization and teams understand it. Below you can find a small part of Go-See results from working with a customer and that we to understand the current context.
The team’s conclusions:
- In lots of the Scrum events like Sprint Planning, the team lead asks most of the questions; there is a poor shared understanding of the work to do.
- We do not break the stories down, a lot of work remains hidden during the Sprint, and this gives us unpleasant surprises. Also, team members find it hard to help each other during the Sprint.
- There are no acceptance criteria for the stories, and the teams do not understand what to achieve.
- There is no clear goal for the Sprints. Sprint Planning is about ‘fixing 50% of the errors’, and the team is not involved in deciding on this plan.
- Unclear what the improvement actions are, what problem we want to solve, and how we know that the problem is solved.
- Work is not transparent to team members or Product Owner. For example, a team member spends three weeks on test suite updates, and we just discovered this at Sprint Review.
This excerpt portraits some of the contexts in which the teams operate.
Select The Patterns
In a workshop, the team selected the following patterns to try:
- try Definition Of Done
- try Sprint Goal
- try Dependencies First
- try Enabling Specification
- try Swarming
- try Definition Of Ready
- try Visible Status
- try Release Plan
- try Refined Product Backlog
The next step is to create a sequence to decide which pattern to start.
Create the Patterns Sequences
Using the languages, we came up with the following possible sequences:
The orange-colored patterns are from the Value Stream language; the Swarming pattern —the blue one— is from the Product Organization language. The initial context of Swarming expects Sprint Goal to be adopted, that is why it is positioned after Sprint Goal.
The team started with the sequence: Refined Product Backlog -> Definition Of Done -> Testable Improvements..
Apply one pattern at a time
A sequence is your best guess on how to improve the organization at the moment in time. When you adopt a pattern, you will learn if it works or not. If it works, you keep it; if not, you backtrack and try another. The basic process is as follows:
- Find your current context
- Choose the pattern in that context that will most strengthen the Whole
- Apply the pattern
- If it makes the system more Whole, then recognize your new context and go to step 2
- If not, undo the pattern and try another at Step 2 instead.
Keep an experimental mindset, be ready to learn and adjust, and understand that there is no “best” sequence. A sequence shows a path, but the teams have to do the walking and discover how to implement it.
Create Your Own Pattern Language and Share
You can find the patterns in this post at scrumbook.org. If you decide to make use of the patterns, I look very much forward to your experience. You can create your own sequences, augment with your patterns, and create a language that works in your organization.
I am looking forward to your experience and contribution.
Business & Finance Articles on Business 2 Community
(62)
