I’ve been working in an agile environment for most of my career (other than a little stretch as a government contractor). Pretty much all of those were versions of Scrum. Scrum also happens to be the butt of nearly every joke I’ve ever seen about the software development lifecycle, and the subject of the periodic articles and videos about why Scrum failed. On the 1 hand, it’s a shot at what I do, specifically how I do it; but on the other hand, all the crap-talking has a good point. So why is having a problem with Scrum so ubiquitous, and is it really justified?
On the surface, Scrum seems pretty good. Do incremental work in short, time-boxed sprints, ending with shippable software at the end of time box. Since we have shippable software, the idea is that you start releasing and deploying these updates more frequently too, while they’re smaller (and thus lower risk). Since we’re releasing more frequently, we can start getting customer feedback earlier and more often. Since we’re getting customer feedback earlier and more often, we have better ideas of what’s resonating with users and customers. Since we have a better idea of what’s resonating with users and paying customers, we can adjust what we’re building earlier when it’s easier. Since we’re adjusting what we’re building when it’s easier, we want to build something shippable to confirm we’re on the right track. And thus the cycle continues.
So how did we get from “do a little bit, deploy it, adjust, and repeat” to story points and stand-up (meeting) jokes? I think it’s because we’ve gotten away from Scrum in the second step of the cycle – we’re not actually shipping more often. Because we’re not shipping more often, it stops mattering if we’re actually done with anything and if the code is shippable at the end of a sprint. So now instead of treating sprints as short periods that focus on iterative releasing, they’re basically what get put into the “repeat every” field for meeting invitations.
Speaking of the meeting invitations, the overwhelming majority of the Scrum hate seems to stem from these meetings. The idea behind these meetings, per Scrum masters, is to make sure the team is regularly talking about the work to be done, what’s needed in order to actually do it, that everyone is on the same page about whether or not this is something that they can get done in a given sprint. That word “everyone” is important – because the idea behind Scrum is that software is organized into cross-functional teams, complete with everything needed to build and run the code (which, granted, is hard, but it’s also not like most places are actually trying, so save your sympathy).
And while we’re on the subject of meetings, the most (in)famous meeting in Scrum is the daily stand-up. It’s so iconic that most of the places I worked that said they did Scrum, literally refer to the stand-up meeting as some variation of the “daily Scrum meeting” (I’ve even heard attending the stand-up meetings as “doing Scrum,” which may give you an idea about another part of the “Scrum problem”). That’s the daily status update on the current sprint. Oh, it’s not supposed to be a status update on the current sprint, but the point of the meeting is to answer 3 questions:
- What have you done since the last stand-up?
- What are you doing today?
- Is there anything blocking you?
This is supposed to be capped at 15 minutes, tops, but can easily go over that once you add in things like people reserving off-topic items for the “parking lot” (I’m not sure where that came from, or why “…and I need to chat with {X} about {Y}” wasn’t just part of the “things I’m doing today” section), and reviewing the burn-down chart. Making the parking a part of the status meeting encourages people to wait until the next day to bring something up, instead of just reaching out via email or chat when you have the question (bonus points if you work somewhere that decides to solve this by scheduling regular coordination/sync-up/collaboration meetings). Point 1 of the Agile Manifesto is literally “individuals and interactions over process and tools,” and yet the way a lot of us do Scrum overvalues the meetings to the point where it’s assumed that’s they’re a prerequisite to having individuals interact.
Back to those burn-down charts I mentioned earlier – this is chart that tracks how much work is completed against the amount of work to be done (you can graph this based on “story points,” a concept I’ll cover later). This is plotted against a “hypothetical” or “ideal” burn-down, which is basically a line running diagonally from the top-left to the bottom-right. The “better” charts at least acknowledge that nobody expects anything to get done over weekends (essentially stair-stepping the chart), but that’s about the only time these things acknowledge reality. Basically these charts assume work gets done at a constant rate, starting immediately. That only happens if work is being done at a constant rate, starting before the sprint in question. That’s fundamentally not how Scrum works, but this graph is still the go-to chart, especially when determining progress, because “reasons.”
Back to story points. These are intended as a way of gauging level of effort on any particular work item. Because they’re numbers, you can now track them as metrics, leading to the aforementioned burn-down charts, and things like sprint capacity (the point value of all the work you typically get done in a development cycle) and velocity (the point value of the work you’ve done so far). The intent here is to take something that’s traditionally been qualitative (what work is getting done and how long do things take) and tries to make them quantitative. That lets things be measured and graphed over time, with the intent of finding ways to optimize the development workflow in order to be iteratively improving constantly, tested by looking for improvements in sprint capacity and velocity.
The biggest problem with points is that there’s no uniform basis for the points. Pick any sport where you have the basics of how points can be acquired, you can generally gauge the relative level of effort involved in any score and, if the game is still going on, the relative level of effort needed for the team that’s losing to come back to win. Even without knowing the exact combination of scoring actions that created that score, we can still get a feel for how much work it took to get that final value. But here’s the thing though – in any given sport a scoring action is a scoring action, the points involved are the same regardless of who achieved the score, regardless of how hard they had to work for each individual point. Scrum story points are quite literally the opposite – developer 1 could say a piece of work is 5 story points and developer 2 can say it’s 3 story points, and that’s somehow OK. The idea is that you can track relative levels of effort at the developer level, rather than the work level.
The problem with that, is that the points are assigned by the team and then put on the ticket, before the work is ever considered “ready” to be assigned to other people, at which time the points are never updated. In addition to not having a standard basis for what constitutes 1 point, another criticism there’s not even 1 standard for determining the points either. Most places I’ve worked use the Fibonacci number scoring, but I’ve also been on a team that did planning poker (which still fundamentally ends in a Fibonacci number). Here’s an unspoken secret about story points – all methods of story pointing fundamentally derive from the Whose Line Is It Anyways method. For those of you too young to remember, Whose Line Is It Anyways is a TV show whose tagline is literally “Everything’s made up, and the points don’t matter.” Because there’s no basis for the points, they’re essentially arbitrary.
Arbitrary or not, these points are still used to plan out work in advance. I mean way in advance. Months and months in advance. Because we know the story points, and capacity per sprint. So total points / sprint capacity = total number of iterations needed to get everything done, right? Yes, some of these work items depend on other work items being done, which should impact planning, but who cares when we can just do simple division instead? This is all months and months into the future, it’ll all work itself out. We’ll take this, group our work items into releases, then tell you when it’ll ship months in advance, all before anyone even starts building anything. It’s great, and not at all why people said software development lifecycles like Waterfall were failures!
Here’s a handy chart if you want to gauge the accuracy of any estimate based on how many sprints out the estimate is. I’m assuming you’re looking at a team that is consistent in terms of their ability to pick the work they’ll do in a given sprint and subsequently get it done.
| Sprints out | Reliability |
| Current sprint | This estimate is trustworthy. Something may come out of left field, but you can generally trust this commitment |
| 1 sprint out | This is the optimistic end of a generally reliable estimate range. This won’t always happen (or even regularly happen), but it’s at least close. |
| 2 sprints out | This estimate is hopeful, as in “I sure am hopeful nothing comes up between now and then” (Cue the narrator voice: “Something always comes up) |
| 3 sprints out | This estimate is effectively a wild guess, but ostensibly made by experts in order to pretend it has more accuracy than just letting monkeys throw darts at a timeline. |
| 4 (or more) sprints out | This estimate is fiction |
OK, so it turns out hating on Scrum is really easy. But if it’s such a joke, then why do so many people swear by it? Because it’s possible to do Scrum without putting an emphasis on all this stuff that I’ve just written about. It’s still there, but it’s all being done with the intent of focusing on consistent, iterative improvement and regular customer feedback, and looks a lot like a highly structured version of Kanban. The problem with Scrum isn’t the meetings, burn-down charts, or story points. It’s that these very iconic aspects that are incredibly easy to cargo cult by people who have no intention of actually changing how they build software.
The end result is basically the waterfall software development model, but with hundreds or thousands of tickets to be worked on instead of pages and pages of documentation saying the same thing (a “process” that’s typically referred to as “Scrumerfall“). In my experience, the defining difference between Scrum being done well vs. Scrum being done in name only is whether or not the team recognizes that they’re just trying to make incremental improvements on the code and see how well those incremental improvements are received, which means shipping often (see step 2 in my “how Scrum works” earlier in the post). The teams that are the butt of Scrum jokes focus on the process and meetings because the checkboxes on the “how to do Scrum” list say to do those things.
Scrum isn’t a software development lifecycle built around long-term plans for big releases and larger-scale projects. It’s a software development lifecycle that’s optimized around small releases and seeing where to go from there. Over time, the team eventually completes major changes to the application, but the realization behind Scrum is that when you’re listening to customers, the final product to them is likely going to be very different than what the organization thought it was going to be before getting started. The entire point of not just Scrum, but literally every agile development framework, is recognizing this reality and building software in a manner that allows organizations to identify the differences between what they thought they should build and what customers actually wanted. If you want to do Scrum, you need to let go of the meetings, the points, and the charts and put the emphasis on writing small code updates, testing them quickly, releasing them ASAP, getting customer sentiment, and planning the next step from there. The truth is, the problem with the Waterfall methodology was the assumption that software can be reliably planned and estimated upfront, while knowing what users and customers want up-front with total accuracy. That’s never true, and changing the process from long bouts of documentation and planning up-front followed by massive stretches of coding to putting the documentation into hundreds or thousands of work tickets, with meetings all throughout, won’t change that.