Saving your Scrum: Testing is not an end of Sprint activity

Let’s start with the harsh reality.

Most ‘Scrum Teams’ are actually mini-waterfall teams.

They have a ‘sprint’ in which they work through a fixed backlog of items, with programmers writing code in the early days of the sprint, and testers who check that work at the end of the sprint.

This is not only an incredibly inefficient use of time that leaves people bored and frustrated, it’s also antithetical to the ideas on which Scrum is built.

So to be absolutely clear, this setup is a dysfunction. One we should be actively trying to fix if we ever want to unlock the benefits of Scrum.

What does good look like?

So if this setup (which is so common) actually equates to dysfunction, what should a proper Scrum team look like?

Firstly, we know that a Scrum team should be cross-functional.
Now, this does not mean that everyone should do everything. You generally can’t have (and don’t want) a team full of generalists who can do everything at once.

Expertise in analysis, coding and testing is absolutely expected (and desirable).

Cross functional does mean that the team has all the skills needed to deliver value, and ideally that everyone in the team has some understanding of all the key activities.
We don’t want black holes of knowledge, or sub teams throwing work over a fence. We want everyone to understand the end-to-end process to delivering value, at least well enough that they can identify and help to remove impediments.

So let’s put this into an example:

Team Ignis has been building their software product for many sprints. They’ve just planned the work for the sprint, and they understand the work and it’s complexity. This means that the ‘test’ specialists and the ‘code’ specialists are not confused as to what they each think about the work, or what they intend to do with it.

This team does not spend day 1 writing code in isolation, ready to throw it to the testers. Instead, they pair up.

Tester and Coder sit together and discuss how the work might function, where it’s failure points are, and how it’s likely to be tested. This way, when it starts to be built, we already know what we’re aiming for. We might use Test Driven and/or Behaviour Driven development to put some structure around this process, but ultimately both developers (The test specialist, and the coding specialist) are working together to define how the new feature will behave so they have a shared understanding of the work.

Now, coding can begin, and the test specialist remains there, with enough understanding of the process that they can at minimum behave as a rubber duck, or ideally, can actively contribute to discussion of the functionality as it’s being built.

When both are happy that the feature meets its acceptance criteria and the basic tests are passing, it can be tested in a more robust fashion. The Coder will not move on to something new, but continue to work with the tester as they check the quality of the new functionality. This means a minimal delay in asking questions, or resolving problems.

This means that if there’s an issue, we don’t need to raise a bug or go through a complex admin checklist. We can talk about it, fix it, and continue.

The goal here is to get the new feature completed as soon as possible, so it can be deployed and (ideally) released.

But what about?!

Over the years, I’ve seen many teams who work in this way.
I’ve also heard many teams recoil in horror at the thought.

“But the testers and developers can’t work together! Then they might not do their jobs properly because they trust each other.”

“You can’t fix something without raising a jira ticket! How will we know the testers are doing their job?”

“You can’t just deploy something that the team has just built. What if it’s catastrophically broken?”

And you know what, these are good questions.
When you’re used to working in a mini-waterfall., these are difficult problems that it took teams time to solve.

But they can be solved.

When you’re no longer using an adversarial relationship between developers and testers, you instead need to develop trust and accountability.

When you’re no longer raising tickets mid-sprint, but solving issues as they arise, you need to foster collaboration and communication.

When you’re deploying work as soon as the team is happy with it, you need a robust automated pipeline.

These are not show-stopping problems. They are challenges to overcome.

So how do we get there?

The hard part is not recognising this idea, but implementing it.

The truth is, we have to be willing to watch things get harder, before they get easier.

Teams who are used to working in a mini-waterfall way, throwing coded work over the fence to testers, probably aren’t going to jump straight into a high-trust, collaborative way of working.

But there are some things you can do to get there.

First, talk as a team. Discuss the benefits of changing the way you work, and tie these to the problems you’ve been talking about in retrospectives. Look at this as an experiment.

Next, introduce some process changes to encourage this way of working. Pairing by default, or WIP limits that are half of your team size, are both great ways to get started.

Reflect on your Definition of Done, and how you’re capturing acceptance criteria (if at all) to make sure the team can focus on delivering value, not just their piece of the puzzle.

Finally, reflect on how it’s going daily. Yes, the retro is a designated space to inspect and adapt, but it’s not your only chance.

Be sure to talk every day about the challenges to working collaboratively to get work done, and make small changes to make it easier.

Just try not to fall into the trap of reverting to what you know when things get hard.

You will have periods where it feels awkward. You will have difficult conversations. You will sometimes feel less personally productive.

But long term, if you keep it up, and keep reflecting, you’ll build a team that generates value, end-to-end, from day one of your sprint. You’ll become more effective, and in my experience, have a lot more fun in the process.

If you don’t believe me, go ahead and try proving me wrong. I’d love to hear why it didn’t work, and what you learned from it.