Agile Patterns

An agile pattern is a documented solution to a problem that recurs across teams, written so another team can apply it. This is a formal body of work rather than a loose collection of tips: the Scrum community has published a pattern language describing named patterns such as Sprint, Refinement, Scrum of Scrums and Co-location, each capturing a problem, the forces around it, and a solution that has worked repeatedly.

Key Highlights

• Patterns are not best practices. A pattern names a specific problem and the conditions under which a specific solution works.
• The idea comes from architecture and software design, where pattern languages were used to capture reusable solutions.
• Scrum has a published pattern language, developed by the community over many years, describing patterns that make up the framework and extend it.
• Every pattern has a context. Applying one outside its context is the most common way they fail.
• Anti patterns are the complement: recurring solutions that look sensible and reliably make things worse.
• The value of learning patterns is recognition. You stop solving a problem from scratch that many teams have already solved.

What a Pattern Actually Is

The word gets used loosely, so it is worth being precise.

A pattern has four parts. A recurring problem, the context in which it appears, the forces that make it difficult, and a solution that resolves those forces. Anything missing one of those is a practice or a tip rather than a pattern.

The distinction matters because it changes how you apply one. A best practice says do this. A pattern says when you find yourself in this situation, with these competing pressures, this has worked, and here is why. The second is considerably more useful, because it tells you when the advice stops applying.

The idea originates in architecture, where Christopher Alexander documented patterns in building design, and moved into software through the design patterns movement. The Scrum community adopted the same approach, producing a pattern language for Scrum itself.

If you are working through the framework these patterns describe, our free CSM practice test takes a few minutes.

The Scrum Pattern Language

Worth knowing this exists, because most writing on agile patterns does not mention it.

The Scrum community has published a pattern language covering the framework and the practices around it. It treats Scrum itself as a set of patterns rather than as a fixed process, which is a genuinely different way of reading the framework: the Sprint is a pattern, refinement is a pattern, and so is the Scrum of Scrums.

Named patterns in that body of work include the Sprint, Refinement, Scrum of Scrums, Co-location and Pivot, among many others. Each is documented with the problem it addresses and the conditions under which it works.

Two things follow from this framing.

Scrum is assembled rather than monolithic. Reading the framework as a set of patterns explains why some parts are non negotiable and others are conventions. The patterns that constitute Scrum are load bearing; the ones around it are optional.

Extension has a grammar. A team adding a practice is adding a pattern, and the question is what problem it solves and whether that problem exists here. That is a better filter than whether other teams do it.

The Scrum of Scrums is a good example. It is a documented pattern for coordinating multiple teams, with a specific problem and specific conditions. Teams that adopt it without the problem it addresses get a recurring meeting and no benefit.

Patterns Worth Knowing

Six that come up constantly, described as problem and solution rather than as advice.

Small batches. Problem: large batches delay feedback, concentrate risk and deliver nothing until complete. Solution: reduce the size of work items so feedback arrives sooner and risk spreads. This underlies most of agile and is covered in our guide to agile software development.

Refinement. Problem: items reach planning unclear, so planning becomes discovery. Solution: clarify and size items continuously ahead of the Sprint, covered in our guide to backlog refinement.

Timeboxing. Problem: discussion expands to fill available time and decisions get deferred. Solution: fix the duration in advance so the group must reach a conclusion, which our guide to timeboxing in agile covers with the rules that make it work.

Definition of Done. Problem: finished means different things to different people, so quality varies and disputes arise late. Solution: an explicit shared standard applied to every item, as covered in our guide to the Definition of Done.

Co-location. Problem: communication cost rises with distance, and incidental conversation disappears. Solution: place the team together where possible. Worth noting this pattern has been under pressure since distributed working became normal, which is a good illustration of context changing.

Vision or goal. Problem: teams optimise locally without a shared aim. Solution: an explicit goal at the level above the work, which in Scrum appears as the Product Goal and the Sprint Goal.

Each has a problem you can recognise. That is the test of whether something is genuinely a pattern.

Anti Patterns

The complement, and frequently more useful than the patterns themselves.

An anti pattern is a recurring solution that appears reasonable and reliably makes things worse. They are worth studying because they are attractive: nobody adopts an anti pattern knowing it is one.

Common examples.

The status Daily Scrum. Problem it seems to solve: the manager wants visibility. Why it fails: the event becomes reporting rather than coordination, and the Developers stop planning together.

The permanent epic. Problem it seems to solve: related work needs grouping. Why it fails: scope expands indefinitely, nothing ever closes, and progress becomes unmeasurable.

Velocity as a target. Problem it seems to solve: management wants a productivity measure. Why it fails: points are self reported and relative, so the number inflates while delivery does not.

Scrum Master as secretary. Problem it seems to solve: someone needs to update the board and chase status. Why it fails: the accountability is capability building, and the administrative version of the role produces dependency.

Testing at the end of the Sprint. Problem it seems to solve: build first, verify after. Why it fails: recreates the phase gate that iterations remove, with a shorter runway.

Our guide to Scrum Master anti patterns covers the role specific ones in more depth. The general lesson is that anti patterns persist because each one solves a real, immediate problem while creating a larger one further out.

Context Is the Whole Thing

The most important idea about patterns and the one most often lost.

A pattern is a solution within a context. Remove the context and it becomes a rule, and rules applied where they do not fit produce exactly the ceremony people complain about.

Three illustrations.

Co-location. A genuine pattern with strong evidence behind it, developed when distributed work was rare and expensive. Applying it as a rule now, to a team hired remotely across three time zones, is not honouring the pattern. The underlying force, communication cost rising with distance, still applies; the solution has to change.

Daily Scrum at fifteen minutes. Works for a team of seven doing interdependent work. A team of three sitting together and talking constantly may find the event genuinely redundant, and the pattern's problem, coordination across a group, is weaker for them.

Scrum of Scrums. Solves coordination across multiple teams. A single team adopting it has adopted a solution to a problem it does not have.

The discipline is to ask what problem this solves and whether we have it. That question converts a pattern from a rule into a tool, and it is the difference between a team that has adopted practices thoughtfully and one that has accumulated them.

Applying a Pattern Properly

A worked example, because the difference between using a pattern and copying a practice is easier to show than to describe.

The situation. A team of eight keeps missing its Sprint Goal. Items are finished late, several carry over each Sprint, and planning has become pessimistic because nobody believes the forecast.

The wrong move. Adopt a practice another team uses. Someone suggests work in progress limits because a neighbouring team found them helpful. It gets introduced, the team now has a rule about how many items can be in progress, and the underlying problem is untouched.

The pattern approach. Start with the problem. Why are items finishing late? The team looks and finds that items are large, so each takes most of the Sprint, and any surprise consumes the remaining slack. That is a recognisable problem with a documented solution: reduce batch size.

Applying small batches means splitting items so several fit in a Sprint rather than one or two. The team tries it. Carryover drops, because a surprise now affects one small item rather than the whole Sprint.

What the pattern gave them that the practice would not. A reason. The team can explain why they split items, so when someone later suggests a large item is fine just this once, they can say what it will cost. A rule adopted without its problem gets abandoned the first time it is inconvenient.

The follow on. With smaller items the team finds several are now blocked waiting for review, which is a different problem, and work in progress limits genuinely address it. The practice that would have been wrong first is right second, because now the problem exists.

That sequence is the whole method. Name the problem, find the pattern that addresses it, apply it, then look at what the new situation is. Teams that adopt practices in the order other teams present them frequently install the third solution before the first problem.

Using Patterns Without Turning Them Into Rules

Four practical habits.

Name the problem before the solution. When someone proposes a practice, ask what problem it addresses. If nobody can state it clearly, the practice is being adopted because other teams do it.

Check the context matches. Patterns are documented with the conditions under which they work. A pattern developed for co-located teams of nine may need adapting for a distributed team of four.

Expect to remove some. A practice that solved a problem two years ago may be solving nothing now. Removing it is a legitimate improvement, and teams rarely do it because removal feels riskier than accumulation.

Watch for the anti pattern version. Most patterns have a degraded form that looks similar. Refinement that becomes documentation review, a Retrospective that becomes a status update, a Definition of Done that becomes a checklist nobody applies.

That last one is where a Scrum Master earns their place. Recognising that a practice has quietly become its own anti pattern requires knowing what the practice was for, which is a substantial part of what CSM Certification Training covers.

Why Pattern Thinking Helps a Scrum Master

The framing has a specific use in the role beyond general interest.

It makes practices defensible. A Scrum Master asked why the team holds a Retrospective can say the framework requires it, which is weak, or can describe the problem it solves, which is not. The second survives a sceptical stakeholder and the first does not.

It makes removal possible. Teams accumulate practices and rarely shed them, because dropping something feels risky. Pattern thinking gives a test: what problem did this address, and do we still have it. That converts removal from a judgement call into an answerable question.

It resolves the customisation argument. Every team eventually asks whether it can change something. Pattern thinking answers properly. You can change the solution if you understand the forces it was resolving and address them another way. You cannot simply delete it and hope, which is what most customisation actually is.

It explains resistance. When a team pushes back on a practice, the useful question is which force it is not resolving for them. Frequently the pattern was designed for a context they are not in, and the resistance is accurate rather than obstructive.

This is also why understanding what each event exists to produce matters more than knowing the mechanics of running it. A Scrum Master who knows the timeboxes can run the framework. One who knows the problems each part solves can adapt it without breaking it, which is the distinction CSM Certification Training is built around.

Patterns Beyond Scrum

Brief context, since the idea did not originate here and is broader than one framework.

Pattern languages exist across software design, organisational design and architecture. The common structure is the same everywhere: a recurring problem, a context, competing forces, and a solution that resolves them.

That shared structure is why the approach transfers. A team can document its own patterns, and the discipline of writing one is valuable regardless of whether anyone else reads it. Stating the problem, the context and the forces forces a clarity that best practice documents rarely achieve.

Two things worth knowing if you go looking.

Not everything called a pattern is one. A great deal of writing labels a list of tips as patterns. The test is whether each entry names a problem and the conditions under which the solution applies.

Older patterns need context checks. Some were documented when co-located teams, quarterly releases and manual testing were normal. The forces they describe frequently still apply while the solutions need updating, which is a feature of the format rather than a flaw in it.

Starting Without Reading Anything

For a team that finds the idea useful and does not want to study a pattern catalogue, a way in that costs nothing.

Write down three practices you follow. Anything: the Daily Scrum, a work in progress limit, a code review rule.

For each, state the problem it solves. One sentence. If nobody can, that is the finding.

For each, state when it would not apply. Also one sentence. This is the part that turns a rule back into a pattern, because it forces the context to the surface.

Do it in a Retrospective, once. Twenty minutes, and most teams discover at least one practice nobody can justify and one they had never articulated properly.

The exercise works because it uses the pattern structure without requiring anyone to learn it. Problem, solution, context. A team that can state all three for its practices has effectively documented its own patterns, and the ones where it cannot are the candidates for removal.

That is also the most useful thing to do with pattern thinking generally. Not learning a catalogue, but developing the habit of asking what problem this solves, which converts every practice from something you follow into something you chose.

Closing Thoughts

The useful shift in thinking about agile patterns is from what should we do to what problem do we have. Patterns are answers, and an answer without its question is just a rule someone is following.

That framing also explains the most common complaint about agile, which is that it becomes ceremony. A team running practices whose problems it cannot name has collected rules. The same practices, adopted because the problem was recognised, feel entirely different from the inside.

The other thing worth carrying is that anti patterns are frequently more instructive than patterns. Nobody adopts one deliberately, which means every anti pattern is a solution that looked correct at the time. Learning to recognise the attractive wrong answer is a faster route to good judgement than memorising the right ones.

If you are the person making these calls for a team, CSM Certification Training covers what each part of the framework exists to solve, which is the knowledge any of these judgements depends on. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to check your grounding.