Scrum is Like Training Wheels for an Agile Mindset

In the last few years there has been a growing but steady backlash against Scrum and some its corollary concepts such as using story points to estimate work and make projections. As a proponent and practitioner of agile product development methodologies, this bothered me at first. But upon further reflection, I have come to welcome the questioning of the status quo as it gives us all a chance get back to the basics espoused in the Agile Manifesto. If you haven’t read it, or haven’t read it recently, I suggest you do so now (it’s actually very short).

Frameworks are useful insomuch as they provide structure that helps the practitioner internalize best practices. The Agile Manifesto is a list of principles, not a framework. Frameworks prescribe how to implement certain principles. They are methodological guardrails that keep us on track lest we wander off the path, as we distractible human beings are wont to do. Once the best practices are internalized, the structure of the framework can safely be de-emphasized or discarded altogether.

The Point of Scrum Ceremonies

Each ceremony (meeting) in Scrum points back to one or more best practices in the Agile Manifesto:

Sprint Planning

The team comes together to discuss the work in the next increment, ensuring alignment, roles, and expectations are set. Scrum or no Scrum, it should go without saying that this is useful and necessary. It needn’t be overblown or excessively lengthy, but it needs to happen. If not done as a Scrum ceremony before the kick-off of a sprint, it should be done ahead of whatever product development increment you use (phase, feature, milestone, etc).

“The best architectures, requirements, and designs emerge from self-organizing teams.”

Daily Standup

Everyone reports what they did, what they’ll do, and if they need help. There should be no question that frequent check-ins are beneficial to force issues to come to the surface and to promote peer accountability. If the goal is achieved in some other way, then great! For example, if team members are vocal about problems they encounter when they encounter them, and update their status asynchronously — then the daily standup has no use as its purpose has already been fulfilled.

“Business people and developers must work together daily throughout the project.”

Sprint Review

There should be relatively frequent check-ins on progress to demonstrate progress to stakeholders and course-correct as necessary. In Scrum, this happens at the end of the sprint. In lieu of the structure of a sprint, this could be at the end of whatever increment you track (phase, feature, milestone, etc). Just take care that the increment is not too large; the whole point here is to get timely feedback from stakeholders.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Sprint Retrospective

Teams need to talk about what’s going well and what’s not going so well. They need a safe zone away from stakeholders to discuss how they can improve as a team. Without this kind of regular introspection, process improvement becomes difficult and grievances fester until they boil over. Here again, the key is that it needs to happen somewhat regularly while accomplishments and failures are still fresh in team members’ minds. Without open discussion about these things, the team doesn’t learn and its growth is stunted.

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

The Articulated Snake

The concept of a time-boxed increment of work (sprint) forces iteration with regular feedback and reflection at natural inflection points in the product development process. There are pros and cons to this way of working. On the one hand, sprint boundaries may often seem arbitrary, especially with teams that never seem to deliver on their commitments and allow tasks to carry from sprint to sprint. On the other hand, not having that natural break in work to assess, get feedback, and potentially pivot can lead to development going in the wrong direction for too long before course-correction, potentially wasting time and resources toward building the wrong thing.

The best analogy I have come up with to illustrate the concept (and benefit) of sprints is the cheap children’s toy, the articulated snake. The overall structure of the whole is quite flexible, but it is comprised of interconnected pieces of hard plastic. We’ll equate the whole to a project or feature, while each piece is a sprint. Each link is a potential pivot point, giving the team opportunities to make adjustments to their trajectory as they go. However, each piece (sprint) itself is planned individually, and should only be significantly changed in extreme circumstances, which usually means scrapping the sprint entirely. This, I feel, is a reasonable compromise between the chaos of constantly shifting priorities vs. planning things in too much detail up front without the flexibility to pivot as new learnings are realized.

This pattern is as much of a benefit to the scrum master as it is to the developers on the team. Instead of chasing down team members to know how they are getting on – oftentimes arbitrarily shifting their concentration during focused work – the scrum master gets what they need in a short status meeting daily. Further, it is much easier for stakeholders to grok the concept of not disrupting a sprint with a new requirement. After all, the next potential pivot point is only a week or two away, and the team will have time to properly assess and discuss the new work. If instead the team’s work is simply a steady stream of tasks, the argument to not disrupt current work is much more difficult to make. You may successfully delay the disruption by allowing the interruption only after the completion of a discrete task, but nonetheless the new requirement will assuredly disrupt the team’s focus on a particular feature or other near-term goal.

Bowling Bumpers and Training Wheels

When I go bowling with my kids, they are fond of using bumpers (those bouncy barriers fixed to the sides of the lane). My goal is the same as theirs: to knock down as many pins as possible. If their bowling ball hits the side, the ball bounces back onto the lane. One way or another, the ball will end up at the end of the lane with a chance to knock down some pins. But if my bowling ball strays too far to the side, it ends up in the gutter, and I lose my chance to knock down pins on that throw.

It’s the same concept of training wheels on a bike. Training wheels are needed for a time to help the child learn how to balance. We typically don’t just give a kid a bicycle without training wheels and expect them to figure it out. They need to ramp up that balancing ability using a system that’s more forgiving when they make a mistake. (Yes, there are alternatives to training wheels, but the same concept holds true: the child safely ramps up their ability to balance before they can properly balance to ride a bike.)

Scrum is like using bumpers in bowling and or training wheels on bicycles. I don’t mean that in a derogatory way at all! Scrum forces a process that helps the team internalize agile best practices. Yes, it can go horribly wrong if the team actively fights against it, or worse still if the team implements the rules of the framework without assimilating its ethos. But on teams with junior developers, developers with poor communication, or developers who are new to agile concepts, it can be a godsend in terms of getting everyone into the rhythm of agile development, and thus realizing its benefits.

Product Development Utopia

Hypothetically, if such a team existed where everyone …

• is vocal the moment they bump into a blocker they need help with
• communicates daily with their team on their progress to hold themselves accountable
• consults all relevant parties in the process of planning how to tackle a problem
• frequently solicits feedback from stakeholders via the correct channels
• insists on periodically openly discussing what’s going well and not so well with the rest of the team
• is able to successfully prevent stakeholders from constantly shifting the team’s priorities ad-hoc

… then by all means, throw Scrum out the window. This utopia usually only exists when the team is small and comprised entirely of highly self-motivated, experienced, communicative developers working on greenfield projects – especially if the team members have worked with each other for some time. If this doesn’t describe your team and you eschew the structure of Scrum, then I’m highly skeptical that the team is reaping the benefits of an agile mindset.

So go ahead, use Kanban or something else. Just ensure that in doing so you are not also getting rid of the agile best practices behind the Scrum framework. Scrum will not make a poorly performing team perform better overnight, but I have seen it vastly improve teams that struggle with agile concepts over time. Make no mistake: implemented improperly, it can actually make a team worse off. But throwing it out without understanding and accounting for the sound principles behind it may be equally, if not more, damaging.