Scaling Scrum in a very simple way

There are a lot of scaled agile frameworks out there. Some are big and complicated, whilst others are small and simple. Each one has pros and cons depending on a wide variety of factors, not least the maturity of the company and the knowledge/experience/skill of the people implementing it.

One framework in particular stands out to me as being universally applicable and useful across a wide variety of teams — Nexus. Anybody who is interested in scaling an agile process would benefit from reading The Nexus Guide, even if it’s just for some ideas and inspiration.

Nexus is the foundation of the diagram below, and at its heart is a balance of simplicity and process definition. Quite intentionally, the diagram only shows the key flows of information & product throughout the process, because while the concept is highly universal and applicable across many teams, specific details seldom are.

I would generally expect the practices that have worked well for a Scrum team to work well at scale in this model. Of course, as Nexus explains, some parts — such as backlog refinement — may benefit from being an event in their own right.

Simple Scaled Scrum

The diagram shows some key concepts:

One product should have just one Product Backlog (with just one Product Owner). Multiple teams can work off this single backlog, and the increment should be reviewed collectively across all teams, in just one Sprint Review. Why? Because there is one product and one Product Backlog, reviewing each team’s work in isolation wouldn’t be conducive to effective/appropriate inspection and adaption. Transparency would likely suffer and the process would inevitably become bloated as more meetings and handoffs attempt to compensate for shortcomings.

The individual teams, and the collective, both need their own retrospectives (which ideally should be held every Sprint). Individual teams need retrospectives for the same reasons that they do in any other non-scaled Scrum team, and because they are so dependant and integral to the wider goal and associated processes they benefit from having a formal opportunity to inspect and adapt these aspects as well. The groups should do this collectively, and most preferably without any exceptions — limiting this exercise to team leads or other representatives is in most cases a false economy. If people aren’t able to be involved, even if it just to listen to what’s going on, the group will struggle to self-organise and work effectively.

Low cost of entry to the Product Backlog. The Product Owner is responsible for the backlog, and so they may choose to apply a process around inbound items, to ensure that they are understood and of an acceptable standard (have the necessary attributes, etc.), but crucially this process needs to be simple. The refinement loop can be used to better prioritise items, and apply detail as necessary, etc. but the emphasis on this entire process is simplicity. If it isn't simple, it won't work. Did I mention simplicity is key?

It’s a particularly common pattern for scaled-processes to introduce unnecessary complication and even complexity around this process. This introduces waste, increases cycle time and greatly reduces transparency around the process as a whole. I’ve seen processes where there are six or seven distinct steps/hand-offs to get a simple PBI (like a bug, or action to resolve technical debt), onto a Product Backlog and prioritised. That's six or seven steps before a Scrum team has started their work on it; that's a lot of upfront investment which has potential to produce a lot of waste.

Communities of interest allow knowledge sharing and appropriate long term strategising. When you’ve got a lot of people working towards a common goal on a project, there should be an appropriate platform for people to get together, communicate and share their thoughts. Examples might include discussion about a new JavaScript framework that might be valuable to the team/product, or changes to the unit testing strategy in an effort to improve code quality, or reduce technical debt. They may also provide a platform for things like architectural discussions and strategic actions from both a product and technical perspective.

It is common in larger projects for more than one person to have an interest or stake in the Product. This is particularly true in larger companies. History has taught us that having multiple people responsible for the Product Backlog is a recipe for problems, so providing a recognised platform for people to discuss things outside of the Sprint Review could be useful to fulfil this desire/need. It is important to remember the purpose of the Sprint Review, and that groups such as this cannot and should not take its place.

A key attribute of ‘communities of interest’ is that they are both transparent and open; anybody with an interest should be welcome to be part of them. They should meet as often as necessary, which is probably at least once every couple of Sprints. They probably shouldn’t have any distinct or tangible output in their own right; they shouldn’t be part of a backlog refinement process for example, but their members may choose to act on the discussions and decisions at the appropriate events, such as in backlog refinement or at the Sprint Review.

The Sprint Review

A little over a year ago I spoke about Ineffective or long Sprint Planning sessions, and explained that ineffective Sprint Reviews were often an underlying cause. I'd like to dive into that a little more and explain what a good Sprint Review might look like.

"A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed." — it's a chance for the Scrum Team, stakeholders and other business people (invited by the Product Owner) to get together and take stock of the current situation.

Part of the Sprint Review is likely to take the form of some sort of demonstration of the work that has been done, which is the part that most teams overly-focus on (some even calling the whole event a "demo" rather than a review) — but there should be much more to a Review than that, and a lot more value available to teams should they wish to extract it.

The Scrum Guide describes the result of the Sprint Review as a "revised Product Backlog".

If you think of every Scrum event as an opportunity to inspect and adapt, we can see the Review as an opportunity to inspect several key things:

  • The Increment

  • The Product

  • The Market, including any competitors

  • The challenges/headwinds faced

  • What the best next-steps are

  • Stakeholder satisfaction

  • etc.

You may choose to adapt several things as a result, but it is primarily the Product Backlog that should be your focus. You can easily imagine why any of the things listed above could result in a change; if feature x is proving more challenging implement than expected, but a competitor has just released feature y, perhaps we want to change direction slightly in response to that. Stakeholder feedback can frequently prompt a re-ordering of backlog items to help maximise the value delivered sooner.

Without a well-functioning Sprint Review, some of these inspections may take place in other meetings, but there's a few problems with that approach:

  • One of the aims of Scrum is to reduce the need for other meetings, and thus reducing waste.

  • If some people aren't included in these discussions, what steps will be necessary to maintain appropriate transparency?

In all likelihood though, if the Sprint Review hasn’t been effective in providing the necessary inspection/adaption, it is unlikely that something else will — teams that omit part of the process tend not to compensate for it elsewhere. However, a common pattern is ‘process bloat’ where more and more processes & meetings are added to try and cover everything that needs to be covered. Before long, things that should become simple, like adding a new item to the product backlog or prioritising the reduction of technical debt require a series of meetings and handoffs. As well as being slow & wasteful, the greater risk is that work that needs to be done doesn’t get done because it’s simply too difficult to get it brought into scope.

The consequences of inadequate Reviews will vary, but it is a safe bet that they will be spread both far and wide. You can of course expect issues connected to all of the inspection points; poor awareness of market trends, unsatisfactory value being delivered to stakeholders, etc. but you should also expect issues with, for example, team morale as people feel in the dark and perhaps being pulled in different directions to what they expect.

My advice to teams is to leverage all that they can from frameworks like Scrum before trying to create their own solutions to problems; stand on the shoulders of giants and leverage their learning, rather than re-inventing the wheel. Exceptions to this are far less common than many believe.

Six phrases of agile doom

The words we choose, often communicate more than the words themselves

With this in mind, here’s six phrases that are often red flags when used in agile projects. Their use is more often than not a sign of underlying issues that will impede a team’s ability to truly perform.

1. “We’re doing what works for the team”

A noble expression which on the surface might seem to be exactly what agile is all about; responding to change and adapting to the circumstances.

But, does it work for the customer, or for the business, or for the stakeholders? What ‘works for the team’ might be building up large amounts of un-shippable work, or working on features that simply aren’t the stakeholders’ priorities.

Could something else work even better, but require a bit of effort? Doing ‘what works for the team’ is often synonymous with resisting change, or a lack of understanding of the landscape. It reminds me of being a child and trying to fix a relative’s computer when something is obviously wrong with it, but they resist change because they are comfortable with what they currently have, flawed as it may be.

Agile practices and techniques typically shine a very bright spotlight on problems. For example, Scrum won’t fix problems with weak product ownership, but it will make it very obvious. Many teams choose to switch the spotlight off rather than fixing the issue. If hiding from problems is what ‘works for the team’ then there are definitely significant problems underlying.

2. “We do [/don’t] do this because we’re agile”

“Agile” doesn’t tell teams what to do, so quite simply should never be used as justification for doing something. Yet, it often is.

“We’re agile, so we don’t write documentation”, or “agile says we should estimate user stories” and many other variations echo through the hallways of many companies, both large and small.

“Agile”, or more accurately the agile manifesto does outline some values and principles, and of course teams should use these to help guide them but they are not in themselves justification or reason.

3. “Sprint Demo”

What if the Sprint Review was an opportunity to do more than just inspect the increment? What if teams could also use this to look at the Product Backlog, and work with stakeholders to better understand what to do next? What if they could look at the market and see how it has changed, and make decisions based on that? What if the Development Team provided some insight into their work, which could then be understood by stakeholders and improvements to their interactions made as a consequence?

Good news, the Sprint Review is all of those things. Teams mustn’t miss this opportunity if they want to be successful.

4. “That’s an idealism”

While some companies release software to production many times a day (some do it many hundred or even thousands of times a day), others continue to insist that it simply isn’t possible for them to release more than once a quarter.

At its core, agile is all about ‘working software over comprehensive documentation’, and so it is little wonder that almost every agile practice that you come across is rooted in the real world, in real teams, doing real work, for real customers. They’re not born out of University research departments. So when people insist that it simply isn’t possible to deliver working software at least every Sprint, or that stakeholders will never be engaged with the team on a regular basis, their competitors continue to surge ahead.

5. “Our goal is to do the Sprint backlog”

If this is your thinking, just do continuous flow because you’re missing one of the most fundamental parts of Scrum. Sprint Goals represent the valuable increment that teams are working towards, and when the increment has value no greater than the sum of its component parts, Scrum is likely not an effective way to manage a complex project.

6. “Scrum says…”

Similar but still different to #2, this is a great indicator of a lack of knowledge and understanding of Scrum within a team.

There are times, of course, when a team or team-member needs to have the rules laid out in front of them, particularly if they are just beginning their agile journey (‘shu’ stage where simply following the rules is the best option), but generally speaking once a team starts to mature, teams are coached and guided through underlying principles, concepts and values. They should be committed to their decisions and to their process, which they are unlikely to be with purely a rulebook to guide them.

So, when teams choose to skip their Sprint Review, a good Scrum Master won’t simply open the Scrum Guide and recite that “a Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed”. Rather, they will explain why this event is valuable, and the potential consequences on the team’s ability to inspect & adapt, and on transparency, if it were to be skipped. They will also recognise that when a team is thinking about skipping something like the Sprint Review, it is probably a sign that the event isn’t working, and the root cause isn’t the event itself but rather something deeper: maybe it’s just being poorly run, or maybe — in the case of the Sprint Review — there are no stakeholders engaged with the project, or maybe the team simply cannot deliver a ‘done’ increment within the Sprint time box so there is nothing to review.


These phrases are not guarantees of problems, but they are often very good warning signs and allow for a very quick assessment of team health.