“Scrum is a light-weight process framework which is simple to understand but difficult to master.”
The above statement is a well-established mantra of Agile practitioners, consultants and evangelists. It is true, but it is of no value in itself.
Scrum patterns build on the framework with practical solutions to problems in different contexts. They can be seen as templates for corrective responses to negative Agile practices. Each pattern also contains a description of the reasons why the proposed solution should work. It can be said that this is a collection of experiences written down as replicable solutions to organisational problems.
Let’s learn about the background to their creation and a couple of important patterns.
FRAMEWORK?
Because Scrum does not provide concrete answers, its users tend to fill in the gaps with their own assumptions and approximations, which are often not in the spirit of Agile. Because of its simplicity, it is easy to imagine that implementing Scrum in an organisation requires only a few simple changes in the way things are done. As a result, many treat it as a list of instructions rather than transformational recommendations. Scrum patterns
Scrum enables Transparency, which gives teams and their members insight into the way they are currently working (Inspection). This information is the basis on which teams then start to think about improvements (Adaptation).
It is no coincidence that Transparency, Inspection and Adaptation are the pillars of the Scrum framework. More broadly, this applies to any cyclical development approach (Kanban, DSDM, RUP, Scrumban, XP, Crystal,…), not just Scrum.
AGILE TRANSFORMATION
The culture of an organisation is expressed in habits. And they are hard to change. Agile transformation is not easy, as it requires a change of both habits and culture.
The transition from a hierarchical organisation to a group of autonomous teams can be stressful for many reasons:
- Developers need to start thinking about broader organisational and product aspects than they have done so far.
- Managers may experience the transition as a loss of authority, position and decision-making power/opportunity, which is now mostly delegated to autonomous teams.
- The new way of working is the antithesis of the status quo and philosophy, summed up in the phrase: “We have always done it this way. Let’s just tweak the existing system a little “.
- …
The resulting tensions within the organisation often prevent serious Agile initiatives.
Even once a transformation has started, it often conflicts with the existing organisational structure. Negative practices emerge in terms of:
- The Sales Director asks the teams for assurance that the fixed release scope will be ready by a specific date. As this target is unlikely to be realistic, this will lead to teams being overloaded and the quality of the product being lowered.
- The Development Manager requests daily progress reports from the teams. This communicates to members (1) a lack of confidence in their abilities, (2) a waste of time on non-value-added work instead of focusing on the effectiveness of the work, and (3) a desire to be in control instead of allowing team autonomy.
- Management’s own perception of the higher value of some members leads them to use individual productivity metrics to reward them, which leads to gaming of the metrics and lowers the level of cooperation between team members and between teams.
- Management is constantly changing the composition of the teams to better “adapt” them to the demands of the current Sprint. This prevents teams from progressing beyond the Tuckman stages and becoming truly effective.
In the land of the blind, the one-eyed is king
The consequence of a hierarchical mindset is that any leader in the organisation can assert their authority and demand changes in the Scrum implementation by arguing that: “He/She knows something that others have overlooked.“. Anyhow:The changes I have requested are not against the Scrum Guide anyway!“. This may be true and technically applies to all the deviations described above – they do not conflict with the Scrum Guide – if it is treated as a list of instructions. But they can be deeply at odds with the values and principles of the Agile philosophy.
As Scrum is part of Agile, similar actions are consequently contrary to Scrum, even though they are not explicitly discouraged in the Scrum Guide.
SPIRIT OF THE GAME
Scrum operates with autonomous and self-organising teams. There is no hierarchy within teams.
The organisation consciously creates a culture that follows the spirit of Scrum in its implementation. Culture is reflected in habits. By deliberately changing habits, the culture of the organisation will gradually change. The reverse approach does not work.
On this journey, it is crucial that the organisation has competent Scrum Masters and Product Owners, and that the team members support each other and work together in the spirit of the Scrum values.
PATTERNS - THE SPIRIT OF SCRUM
The patterns are ways of working that are in the spirit of Scrum. They answer specific questions that the Scrum framework, because of its framework structure, intentionally doesn’t address.
Scrum Patterns are a long-standing project of the Agile Community, which is in constant development and can be found at https://sites.google.com/a/scrumplop.org/published-patterns/home. *
There are currently over 200 published patterns, covering all aspects of Scrum. Some are general, others situational. Some are positive, others point to the emergence of anti-patterns in an organisation. Some are only appropriate for a specific situation, others we can choose to ignore.
Coming from the community, their common feature is that they offer a practical perspective on Scrum and its implementation.
We have already seen the first pattern. It’s called Spirit of the game. It is the overarching pattern of all the others. Let’s get to know a couple more.
* Links in the table on the pattern homepage sometimes don’t work. This doesn’t mean that the pattern you are looking for does not exist. You can find its name using the search function.
SWARMING
Within Sprint, working on multiple PBIs (Product Backlog Item) at the same time, increases WIP (Work In Progress) and consequently reduces the flow of PBIs through the development cycle (Throughput). In addition, working individually on PBIs reduces information sharing between team members.
The solution is swarming, where the whole team is developing one PBI at a time. If the PBIs are smaller, the team can be split into sub-groups, each developing its own PBI.
Swarming pattern assumption:
The whole team should focus on one PBI. The team leader (captain) is the one who originally took responsibility for the PBI. All team members assist the captain. For the next PBI, the captain is someone else from the team.
By implementing this pattern, the team moves closer to the Lean ideal of one-piece-flow. The pattern has been successfully used by Cisco in its development.
More about the sample here.
ILLEGITIMUS NON-INTERRUPTUS (formerly: INTERRUPT BUFFER)
Unfortunately, the reality of development work is that unplanned work often creeps into development. Usually this is the fault of an undefined product stewardship, where the Product Owner does not have enough authority to redirect the flow of new requirements to the Product Backlog.
The assumption of the Illegitimus Non-Interruptus model:
We reserve part of the team’s capacity as a buffer for unplanned work. When the buffer “fills up”, Sprint is automatically terminated and re-planned. The Product Owner informs the management that the planned release date will be delayed.
The size of the buffer is determined on the basis of experience with unplanned work from previous Sprints.
Management must be aware of and approve the model. The pattern will result in self-organisation by stakeholders who often pass requests to the team. They will start to prioritise and forward requests through the Product Owner, because they don’t want to be named as the ones who blocked the whole Sprint.
More about the sample here.
EMERGENCY PROCEDURE
To reduce the amount of unplanned work, the Interrupt Buffer pattern is often combined with the Emergency Procedure pattern.
Emergency Procedure pattern assumption:
When a team realises that it will not reach its Sprint goal due to changing requirements, loss of members or unexpected technical problems during the Sprint, one or more emergency procedures tailored to the specific problem may be used.
Possible emergency procedures:
- Team seeks external or internal help
- Team changes the way it works.
- Reduction of scopea
- Informing management how the changes will affect the release date
- Sprint interruption and re-planning
- …
The Emergency Procedure pattern is the equivalent of the Lean Andon cord used in Toyota production to stop a conveyor belt and help immediately solve the problem at hand before it spreads further down the system.
This is of course conditional on transparency about the existence of the problem and a willingness to take immediate corrective action. Emergency procedure is activated by the Scrum Master.
More about the sample here.
YESTERDAY'S WEATHER
It is in the nature of a successful team, and the individuals within it tend to set themselves ever-higher goals. Maybe as a challenge to themselves, or maybe because they expect some newfound approach/technology to give them a higher Velocity. Such challenges may bring positive changes, but they are generally not sustainable in the long run. This is why we do not want them to become the norm. The team’s primary goal is to reduce the variation of Sprint Velocity through improving its own processes and thus improve the quality of planning. Increasing the average Velocity is only a secondary objective. Provided, of course, that the Definition of Done does not suffer as a result.
Yesterday’s Weather assumption:
If we have a stable team and equal Sprint lengths, we can consider that the best indicator of the team’s capacity in the next Sprint is the velocity of the previous Sprint.
This pattern is in stark contrast to the claim that Velocity is not an indicator of a team’s future productivity. In some situations, however, this pattern can be useful. As I wrote above. Not all patterns are necessarily relevant to our specific situation. Some may even be sub-optimal.
More about the pattern here.
OTHER PATTERNS
On patterns page, it may be a bit difficult to find a suitable one among more than 200. It helps that they are organised by theme.
I would like to mention a few more patterns that are worth looking at:
USING PATTERNS IN SCALING FRAMEWORKS
Scrum patterns are useful in guiding single-team development initiatives, but in Scaled Agile, their implementation is virtually essential. For Scrum@Scale certification, patterns are one of the exam topics.
In the context of Scaled Agile, for example, LeSS and the Scrum@Scale framework provide the coordination structure, and patterns are the elements that ensure efficiency.
In the table below, I’ve written down eight patterns that lead us evolutionarily to efficiency and predictability in scaled development.
