I’ve spent the last year working at a company that embraced Agile from the top-down.  I’ve been on a Scrum team as it transitioned from semi-chaos to self-organizing and back to complete-chaos.  I’ve seen Scrum at its best and at its worst.  During this year, I’ve made a few observations on Scrum, its strengths, and its weaknesses.  Read on, ye readers, to find out why I think Scrum fails.

[more]

Scrum Helps Build a Cohesive Team

This is the aspect of Scrum that I like the most: it really can foster team growth and create a strong, cohesive team that works well together.  I think it does this by providing focus for the team on a small set of stories that the team collectively commits to deliver within a sprint.  When implemented correctly, it breaks down silos and encourages collaboration amongst the team.  It’s no longer about what I can accomplish, it’s about what we can accomplish.

Scrum Does Not Match How The (Business) World Works

As I mentioned in the intro, for the last year I’ve been part of an organization that fully embraced Scrum from top to bottom.  Or at least it claimed to.  In reality, it was a constant battle to stay true to Agile principles and Scrum, a battle that the Agile-advocates frequently lost.  The reality is that business wants software to be an activity where you can say “I want X features in Y weeks for Z dollars.”  Anyone who has ever written a line of code knows that this thinking is a fallacy, yet despite the explosive growth of our industry, we’re still fighting that mindset.  Trying to stay true to Scrum principles in a world run by people with MBAs can be an infuriating experience. 

Scrum Can Lead To Lower-Quality Code

A common complaint that I’ve heard about Scrum and somewhat share is that the focus on meeting your commitment for the current sprint leads to short-term thinking and therefore low-quality code. While I do believe that’s certainly possible, and in fact very likely when dealing with the wrong type of product owner, I don’t think it’s a necessary evil when doing Scrum. Stick to a Definition of Done, and treat the health and quality of the application as a first-class citizen and not as something that can be sacrificed just to meet a commitment. Don’t be afraid to pull a story if you aren’t satisfied with the solution you’ve implemented. In the long-run, everyone will be better off. 

The focus on meeting a commitment isn’t the only way that Scrum can lead to low-quality code.  A scenario that bit my team several times was “hacking” together a “less than clean” solution for an early story with the plan to evolve the solution into a more elegant one as planned follow-up stories related to the same feature were played.  This would have been fine had our product owner remained committed to the sequence of stories.  Unfortunately, product direction frequently changed, and sequences were rarely completed, leaving some of our early, rough code in production to this day.  Technically, we delivered a solution that fit the bill for the story, but had we known that would have been the end, we probably would have invested time in crafting a more maintainable solution.  The moral of the story is that you must treat each story, even if its part of a larger epic, as if it’s truly complete when the story ends.  Stick to your Definition of Done even if you think you’ll be revisiting that area of the application again soon.

Scrum (And Agile) Is Not The Answer

Software development as an industry still has a lot of growing up to do.  Sure, we’ve come a long way over the last three decades or so, but I truly hope that we as an industry will continue to evolve and grow.  Scrum and Agile in general address some problems with software projects, but certainly not all of them.  There’s still an incorrect mindset regarding software projects that’s holding us back.  Until decision makers understand and accept that you cannot control features, resources, and delivery date at the same time, I believe the number of failed software projects and the number of failed attempts at implementing Agile will remain quite high.

To sum up how I feel about it, Scrum is the worst methodology for managing a software project… except for all the others. It’s the best methodology that I’ve been a part of so far, but I hope that in another five to ten years we talk about Scrum and Agile in the same negative way that we currently talk about Waterfall.