Scrum: A Review After Two Years

If you’d told me a few years ago that I’d be adopting scrum, I wouldn’t have believed you. Isn’t this what they do at boring corporates? Don’t scrum teams end up with tons of technical debt? How much does a certification you earn in a two-day workshop really mean? Shouldn’t we be focusing on people instead? I had so many concerns and preconceptions about what scrum was and what it encouraged.

Now, after two years of use, my opinions about the framework have shifted. While I think there are valid reasons for the kind of suspicions I had, I don’t think there is anything wrong with the framework itself. I’ll review some of my original concerns below, but first let’s look at the context in which we adopted Scrum.

A Quick History

As a small team at a small start-up, we initially focused on having good technical practices and following good management principles. We were a three-person team at the start, and I focused heavily on finding the right balance between building new features and managing tech debt. Right at the beginning, we only did stand-up meetings and 1-on-1s. Pretty soon, we also started doing retrospectives every two weeks.

Then, the company started growing quickly, so we decided that it could be a good idea to adopt a framework. This would come with the benefit that people start with some shared knowledge. Additionally, we’d been growing our processes incrementally. By adopting a framework we could potentially end up quicker where we were headed anyway.

A colleague suggested reading the “Scrum” book by Jeff Sutherland. I kept an open mind, read it, was pleasantly surprised, and was convinced enough to give it a shot. The week after we decided to try it out, but with the mindset that we wouldn’t do anything without understanding it. Without understanding the thinking behind a process, it loses much of its value and becomes a recipe for bureaucracy.

Overall, we were happy with the results and kept using it indefinitely. Now, after two years, I can review a few of my original concerns.

Concern 1: Doesn’t promote technical excellence

I don’t remember exactly where I first got this idea form, but the “Flaccid Scrum” blog post by Martin Fowler summarizes it quite well. It seems like many teams that adopt Scrum end up with a lot of technical debt. For some reason they don’t pay enough attention to the internal software quality.

As Fowler mentions, Scrum itself doesn’t promote any specific technical practices, so it’s up to the team to make sure those are there. In our case we were already pair programming, doing test-driven development, and deploying via a CI pipeline. Those practices, and continued discussion about these topics, helped us keep technical debt under control.

In my opinion, this is why it’s important that whoever picks up the scrum master role not only has good people skills but also has a strong enough technical background, like a tech lead or an engineering manager. They must have a good understanding of the impact on tech debt and must give the engineers ample opportunity to voice their concerns. The sprints and their sprint goals encourage people to be really focused on meeting those goals, but you must make sure that this doesn’t erode the internal software quality over time.

Concern 2: Certifications earned in two-day workshops

If you are thinking about adopting Scrum, and you then think that sending someone off to a two-day workshop is enough to make your organization “agile”, you’re going to have a bad time. These certifications create a wrong expectation about competence.

I think for these kinds of projects to be successful, you need people who have a good understanding of processes, communication, and technical practices. You can’t learn all of those in just one workshop. The workshop might be useful, but you’re going to need a lot more than a two-day workshop to make a significant improvement. In fact, you’ll probably be improving your processes for a long time, or even indefinitely.

Read more books. Set clear expectations about the fact that this will be “imperfect” for a long time, but you’ll continually improve. Don’t use “it’s not agile” or “because they said so in the workshop” as arguments. Instead, explain more clearly why you think something isn’t a good idea. Make sure you have at least one clear action item coming out of the retrospective, and follow-up on them in the next one.

I did go onto a Scrum workshop eventually, and exchanging ideas with the agile coach leading the workshop was useful, but it’s important to have the right expectations.

Concern 3: Isn’t the competence of the team members more important anyway?

I think Tom DeMarco and Tim Lister had it right in Peopleware when they said: “The final outcome of any effort is more a function of who does the work than of how the work is done.”

If you aren’t able to hire the right people, to figure out their strengths, to unlock their potential, to give them enough autonomy so they can develop themselves, then whatever framework you adopt is going to have a negligible effect. People aren’t like cogs in a machine that you can fit into a bunch of teams and procedures. This is why I think the 1-on-1 meeting is the most important one there is.

However, this is not an either-or matter. Process matters too. Hiring the best and wasting their talent on ineffective processes would be most unfortunate. Without good processes, we’re less likely to collaborate effectively, build the right thing, or reach our potential. A good process allows the team to become larger than the sum of its parts. Scrum can be a way to help you achieve those better processes.

Just remember, teams can succeed with good people and without Scrum. The reverse is less likely to be true. Mind you that Scrum and valuing people are not opposed. It’s just that, too often, teams adopt Scrum and mostly focus on the practices and procedures, rather than the principles behind them.

Conclusion

In the end, I don’t think the Scrum framework itself has any major issues like I originally suspected. If you are currently struggling and you adopt it, you won’t be any worse off by using it. It just won’t make you automatically better unless you have a deeper understanding of the principles behind it.

I also don’t think there’s one framework that’s the best either. During my last job I regularly had meetings with people who lead teams using Kanban, Shape Up, or something custom. The ideas and discussions we had were immensely valuable, and I’ve borrowed ideas from all of them. In the end, it’s all about having a happy high-functioning team that’s able to handle the inherent complexities of software and its unintended consequences. Scrum is just one of the tools you could use.