At some point, every technical leader faces the challenge of deciding on the best project management framework for their development team. The options are somewhat limited if reinventing the wheel isn’t on your agenda (I’m looking at you, Google) with the usual suspects — Agile, Waterfall, Kanban, and Scrum.

Today, let’s take a detailed look at SCRUM. This project management framework, developed by Jeff Sutherland, is centered around the concept of sprints — short, focused periods of work aimed at completing specific tasks within a larger project. Unlike what its name might suggest, “Scrum” isn’t an acronym. It’s borrowed from rugby, referring to a team strategy to restart play.

So why is Scrum so bad?

At its heart, Scrum is all about being results-driven — a concept that sounds fantastic on paper. The idea of delivering results as fast as possible is attractive to most. However, this is where the complexity of sprints comes into play. Sprints in Scrum require careful balancing, almost like a Goldilocks scenario, to make the framework work.If sprints are too short, it’s a compromise on quality. Engineers may feel overwhelmed by the relentless pace, leading to burnout. This not only affects morale but also makes gauging team performance a challenge. On the flip side, if your sprints are too long, congratulations — you’re doing Waterfall with extra steps, and again, measuring and adjusting team performance becomes equally challenging.

Generated By DALL-E

It’s important to acknowledge that Scrum can be highly effective when it’s tailored to fit the specific needs of a project and team. The key lies in finding a balanced sprint length that supports quality development, maintains a sustainable pace, and allows for meaningful performance assessment. However, this often means focusing intensely on one project at a time, whereas a more straightforward approach might be available.

Implement Kanban

Let’s put aside for a moment the fact that ‘Kanban’ is Japanese for “billboard” — which, between us, I find ridiculously cool. When done right, Kanban zeroes in on each engineer’s responsibility to deliver results. And when you combine this with a top-notch testing and automation system — take Wix, for example, a company that nails this approach — you’ve got a constant, steady stream of features rolling out. This keeps the product team and their customers happy and gives engineers the breathing room they need for research, development, and testing. The upshot? A noticeable drop in burnout rates.The most notable advantage, however, lies in the approach to project management. Unlike the constant need to adjust sprint lengths for new projects in other frameworks, Kanban encourages engineers to take ownership of their features, delivering consistent results across various projects and team compositions. This shift away from rigid scheduling towards a more adaptable and continuous delivery model offers a refreshing change in the dynamics of project management.

What about estimation?

By using scrum methodology, you know precisely the features set we will end up with at the end of the sprint, which is valid to an extent. But when we start looking into some numbers and statistics, we find pretty quickly that:

1. Engineers and their managers could be better at estimating their work. The book “Peopleware” dives deep into this in their chapter “Parkinson’s Law: Revisited.” They highlight a study by Michael Lawrence and Ross Jeffery from the University of New South Wales. They were able to quantify the productivity of an engineer in comparison to those who estimated the feature in which they were able to determine that going over a task with NO ESTIMATION produced a higher productivity score. Who would’ve thought?

2. Estimation is heavily coupled with the feature urgency but does not dictate the completion time. The book Mythical Man-Month has a good analogy to a chef trying to fry an omelet for a patron — “An omelet promised in two minutes may appear to be progressing nicely, but when it has not set in two minutes, the customer has two choices — wait or eat it raw.”

3. On average, 20–30 percent of engineers’ work involves correcting mistakes. We can factor this into our original estimations by applying a buffer. While it’s a noble attempt to manage those mistakes, it is usually shadowed by the next point.

4. Most of us are just not productive for 8 hours a day. You might want to think that we do. Still, if you consider the time you need to switch content, the breaks you take throughout the day, and the casual chit-chat with your teammates, most people are productive for about half of that. The top performers can go to 6 hours a day, which eats up all of the buffers we allotted anyway.

It’s either not feasible to consistently meet all features set for a given sprint or become so lenient about the sprint contents, which by then doesn’t make sense doing scrum at all.

So, is Kanban the answer to all of my problems?

The short answer is yes… but also no. Let me explain.When considering a project management framework, you should consider your team size, team composition, product needs, and other variables; for example, if you are a team building a cool new video game, you should probably go with waterfall (or do what everyone does which is developing an MVP in a sprint and then release it as an “early access” for the full retail price but I digress); or if you are a small startup with 1–2 engineers you might want to skip a project management framework altogether and just communicate with each other.There is no right or wrong way; if scrum truly works for you and your team, use it to achieve big things because, in the end, it boils down to the people who are working diligently by your side to solve a complex problem, delivering a feature for a customer or pushing the envelope for a common goal. If you let good people achieve great things, the project management framework will become an afterthought.

Hello! I’m Kevin, an engineering manager with a deep passion for building, mentoring, and nurturing teams and individual contributors. If you’ve enjoyed reading this and thought, “Kevin would be a great fit for our team,” your instincts are spot-on. I’m currently on the lookout for my next exciting career opportunity. I’d love to connect and discuss potential collaborations if you believe I’d be a good match for your company. Feel free to reach out to me on LinkedIn — https://www.linkedin.com/in/kevinedry/.

Let’s explore what we can achieve together!

Sources:

• Peopleware — https://www.amazon.com/Peopleware-Productive-Projects-Tom-DeMarco/dp/0932633439

• The Mythical Man-Month — https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

• What is Scrum? — https://www.scrum.org/resources/what-scrum-module