Just When Things Were Getting Good: Problems I’ve Seen with Scrum Adoption

I received my ScrumMaster certificate in 2013, and spent two solid years living the Scrum life. The simple, iterative approach really appealed to many of our teams, and I found it to be incredibly effective in handling rapidly changing objectives without the usual detriment rapid shifts bring to team efficiency.

However, I was continually surprised by the lack of patience stakeholders had with the process. Meetings and communication with management quickly became infused with frustration, and in the end projects and even teams were scrapped because the decision-makers had lost faith in our ability to deliver. Each time this happened I was shocked; transparency is a core tenant of Agile, so how could you be a participant and still be surprised by any part of it?

After a lot of analysis and reflection, I’ve realized just how different Agile is from what people are used to and are expecting, and that it requires

Most people’s experience is with waterfall; it’s how most things get done and generally puts out a product within the standard deviation of the initial ask. The downside is that while the output generally matches the input, in many cases the inflexibility makes mid-project changes frustrating and difficult; often by the time something is “completed” you’re already writing specifications for the upgrade. In many ways this is Agile’s reason for being. It’s focus on deconstructing tasks into “bite-sized” chunks designed to scale and stack allow and even invite adjustments at every stage of the process.

There’s no doubt about it; Agile is different. Development teams are deeply embedded in the change and so the difference for them is obvious and clear. However I’ve realized that for stakeholders and managers, the change can be much more subtle and that when you’re used to and expecting something like waterfall, Agile can instill a pretty deep sense of panic. Specifically:

a) People are constantly refining “the goal”. In waterfall you invest a bunch of time in the beginning to drawing the finish line, and a change to the scope or requirement means someone made a pretty big mistake. In Agile, this isn’t a bug, it’s a feature; but it really looks like a bug in the system they expect to be seeing, they think that the planning portion of the team is constantly fucking up.

b) There’s no “unwrapping”. In Agile, you deliver the tiniest sliver of functionality and then constantly improve it. However, people are used to seeing things work from their first hands-on interaction; incessantly checking in with your stakeholders to tell them that most of what they actually care about is still x sprints away, it’s easy to see how serious constipation can develop.

c) In waterfall the business submits their scope and requirements and then walks away for a while, freeing them up to go do whatever it is they normally do. Agile requires constant engagement with the team so that we can keep what we’re building aligned with what they need. A lot of people don’t know how to interpret this, and usually it comes across as “these people must be asking me questions because they don’t know what they’re doing”.

From the perspective of someone unfamiliar with Agile, this all adds up to a team that seems to be constantly in need of “help” while not actually producing anything you can work with. While simply sitting on their hands would produce a product (definitely) closer to what they actually need (probably) faster than what waterfall could achieve, they feel they have no choice but to “cut the experiment short” and impose their iron will just so that they can salvage something from the wreckage.

Leave a Reply