Around 2001, Agile and Scrum exploded into the collective consciousness of software development as alternate methodologies for software development, in contrast to planning-heavy, sequential approaches, such as waterfall. While Agile was a general set of principles identifying what was important, Scrum was a specific approach to Agile that focused on time-limited activities by a specific set of roles in an iterative fashion. Since then, Scrum has become a favorite approach to software development at organizations ranging from tiny startups to multinational corporations.

I hear more and more people becoming critical of Scrum, and using that as a basis on which to conclude "agile" is a myth, lie, or clever deception. They complain about the strict requirements of Scrum, that they spend more time talking than coding, or that they are jumping through hoops just to check off boxes on someone's list. I'd argue that 1) Agile is not only Scrum, so any problem they have with Scrum is not with agile; 2) Scrum is not for every team or project; and 3) The problem with Scrum that prompts these complaints is when it's not agile anymore.

I’m often struck by how easily people confuse all the terms floating around in the Agile ecosystem. People think iterative is synonymous with Agile: it isn’t. People think testing is agile: it isn’t. People think Scrum is agile: it isn’t. These are all just process tools to achieve agile ideals, which are much more about a collaborative environment that helps people achieve their potential, focus on what’s important, and deliver results. While I'm going to make some points in defense of Scrum, the bigger thing I'd like to stress is that, whatever your opinion of Scrum, Agile is a distinct set of ideals that you probably still agree with.

While traditional Scrum is a common starting point, a truly agile team should be willing to change it to suit their needs if they discover it doesn’t meet them. Scrum essentially provides a list of the right conversations to have to make sure teams are accomplishing their real goals and reflecting on the process they use to do that, along with a process guide as a starting point. As teams move forward, that Scrum process should be tailored to their needs as they learn more each sprint. Ultimately, a team may end up with a process that doesn't resemble Scrum. Or the team may decide that Kanban is a better fit. These, and more, are perfectly legitimate goals of the Scrum starting point.

I suspect that a lot of the pain people associate with Scrum comes from strict enforcement of traditional Scrum on teams whose needs and realities aren't totally met by that process. We've seen an entire industry form around selling Agile, Scrum specifically, and this can result in strict adherence to standardized processes that don't meet the actual needs of teams. At FFW, we’ve found that Scrum is a great place to start, but that it really hits its stride when it is adapted to the needs of the project and team. I'd encourage those who are sour on Scrum to consider if it's really Scrum they have a problem with, or whether they have a problem with what results from strict application of Scrum-like processes that don't actually meet their needs.

Want to learn more about our process?                Contact us