You're Doing Scrum Wrong, and Here's How to Fix It

Eric Weiss explains the fallacies that might occur when you forget the founding principles of the Agile Manifesto and become too strict about your process, for example, Scrum. When you just rigidly follow the rules of Scrum, you divert from Agile Software Development to what Eric calls the “Assembly Line Scrum”:

The Assembly Line, or Mini-Waterfall model, focuses all of its energy on the estimation, measurement, and control of velocity. In this assembly line, the story point is the unit of production, and all systems and processes are designed to maximize productivity. In this model, a significant amount of overhead is invested in estimating tasks, logging work, developing burn-down charts and sprint reports, and providing status in the daily standups. To try new things and experiment with the process would introduce risk into the production line. To maximize feature output, there is little room to invest in automation, paying down technical debt, learning new technologies, improving documentation, or experimenting with the development process. If this sounds like you, and you aren’t meaningfully investing in continuous improvement, you’re doing Scrum all wrong.

The continues to explain the ceremonies of Scrum that make building blocks of the process:

The purpose of the sprint planning ceremony is to ensure that all high priority tasks are clearly defined and actionable, that clear success criteria are understood by the entire team, and to commit to a scope of work that will not be broken or altered during the course of the sprint.

For me, the daily standup is the most important ceremony of any Agile Development Process, because that’s where information flow openly between team members:

In Assembly Line Scrum, the daily standup is used to gather and up-to-the-minute status update so that the Scrum Master and Product Owner can update their status reports. This does nothing to improve the ability of the team to execute mid-cycle. In successful Scrum teams, the standup is reserved for communicating roadblocks.

If an engineer is missing a critical dependency or piece of information, is unclear about the objective or success criteria of a story, or is otherwise blocked, it is the team’s duty to help clear those roadblocks. If the engineer has no roadblocks and has a clear direction for the day, he or she can simply cede their time. The status can be easily observed in the sprint board itself. This is how you keep a stand up to 15 minutes and physically standing, by focusing on helping the engineers succeed, rather than trying to get up-to-the-minute status.

And finally, the retrospective that enabled the feedback loop into your team:

The retrospective is the single most important ceremony in the entire development process. If you are not performing a retrospective in earnest at the end of every sprint, where you identify what is working and not working in your process, and brainstorm and commit to trying new things, you are completely disregarding the principles of agile software development.