To sprint or not to sprint

man wearing white sweater and black shorts about to run
Photo by nappy on Pexels.com

I was recently tech lead on a 4-5 month project with some familiar team members and some new ones. The customers were internal users who have a fair amount of project experience. Early on, the project manager and I agreed to try and do it without sprints. Our reasons were diverse:

  • Work did not seem to fit neatly into sprints, so that the entire team could devote themselves to an achievable goal. Rather, each pair of developers seemed better served if they could take on a piece of work and drive that to a specific deadline of their own.
  • Our experience of sprints was that, while they had been extremely successful in previous projects we’d done, they were often time consuming in terms of meetings and overhead.
  • We had both been reading things on the internet and had decided that maybe sprints were an artificial cadence imposed on the team and we might be even better without them.

It was a disaster and very nearly destroyed the team’s morale and their trust in one another. That said, the project was successful in terms of its delivery.

What on Earth happened?

About three weeks into the project we started seeing issues relating to the system already in production. The more serious issues were incorporated into the project at the cost of some scope, as they were deemed more important than some of the requirements on the project.

Some of the bugs prevented testing from continuing until they had been fixed. These bugs were addressed as a priority but developers not working on the bugs would still produce other code, contributing to a growing backlog of items to be tested.

While this was going on, the developers noticed that the testers and UAT users were becoming increasingly frustrated and distrustful of us.

After many painful weeks, during which we mainly fixed bugs, we eventually conceded that one issue in particular could not be “fixed” and had to be planned out and reworked properly.

Eventually we held a retrospective. The UAT folk were not happy. The developers argued that we had worked very hard and felt unappreciated. We argued that we had fixed a lot of bugs and built a lot of features, that things were going okay because we had met our targets, but the testers voiced serious concerns about the backlog of feature tests still waiting to be run. The distrust seemed to have built up partly because the testers and UAT people felt that the developers had been doing things they didn’t know about.

We are in the process of rebuilding our project team now, repairing the damage we did. But what caused it?

What’s wrong with no sprints?

In short, nothing if you’re a team working at a level where you don’t need them anymore. However, if you aren’t working at that level yet, sprints give you a number of valuable things:

  • Sprints have regular planning meetings – opportunities to get buy in from the whole team for the work you will attempt in the sprint. Planning meetings also force you to discuss the work, quickly identifying mismatched perceptions and technical unknowns.
  • Sprints draw a fence around the work the team is doing, committing everyone to getting the work through dev and test and maybe even into live within the sprint. Nobody does anything outside the fence. This prevents “backlog fatigue” and ensures that nobody works on anything without the consent of the team.
  • Sprints force you to have a retrospective, even when you’re busy.
  • Finally, sprints are what a lot of people are used to. They’re familiar. Don’t scoff.

Where did we really go wrong?

That last point above is important. Everyone else on the project was used to sprints and they liked them.
When the PM and I decided to change things up we didn’t make enough effort to take everyone else along with us. We absolutely should have tried harder to communicate to everyone why we though no sprints was a better way, and obtained their permission to trial it.

Having decided to try no sprints, we should have thought harder about what we would lose and how to replace it. The benefit of sprint planning meetings and retrospectives is team communication. Without the regular cadence of sprints, it’s easy for communication to become chaotic and infrequent when times are tough and the team is busy.

A positive note

We’ve backed out our changes now and the damage doesn’t seem irreparable. Slowly, the team dynamic is returning to normality. For now, we all have a better appreciation of the value of our processes. It’ll take some effort to convince people to go without sprints again though!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s