Scrum is now the default agile software development methodology. This management framework, which is “simple to understand but difficult to master”, is used by 66% of all agile companies. After two extensive workshops, more than five years, and a couple hundreds of sprints working in Scrum, I have some points of criticism about it. I think it’s not naturally conducive to good software, it requires too much planing effort on the part of the developers, and it inhibits real change and improvement. In the following, I will try to put these into more detail by organizing them around more concrete topics.
Before you go to the comments section to tell me that I have no idea what I’m talking about, please keep in mind a few things. First of all, this is not a rant against agile. I’m a big fan of agile, as it is explained in e.g. The New Methodology, and I believe that the potential of this concept has not been exhausted yet. Also, I’m not against every idea and practice in Scrum. For example, the principles of the whole team taking responsibility for the code base, or always having an integrated, working master are really awesome. Last but not least, the following points are directed against standard Scrum as described in the official guide. If you are doing something totally different but still calling it Scrum, this post is probably not so relevant for you.
One thing I would like to refrain from here is anecdotal evidence. My individual experiences, as far as they are not related to the proper Scrum entities, are not really relevant, since many of them are individual mistakes, and will therefore intentionally be left out from the following.
The use of story points appears to be one of the defining features of Scrum. Each user story is given a certain count of story points, and a team is confronted with the number of points it has “achieved” at the end of a sprint. Some teams also follow their daily progress in terms of story points with a burndown chart that is consulted every day at stand-up. The points collected at the end of a sprint consitutes the velocity of a team, and the team is expected to keep this velocity. During planning, the team takes on stories it thinks it can finish until the end of the sprint by looking at the velocity from previous sprints. The velocity of the teams serves to project an estimate of what can be achieved in the future, for the purpose of business planning.
There are many murky things about story points, but somehow the scrum masters and coaches will not abandon it. First of all, what are story points? Are they measures of time it takes to complete a story? If yes, then why are they not in terms of time? Are they measures of complexity? If yes, why are we not talking of the complexity of stories, and how we can remove them, instead of how we can achieve as many points as possible? That is, shouldn’t we be talking about doing as few points as possible? The best measure I have heard is effort. You can work three hours on half effort, but work hard for an hour and finish a task, which explains why it’s not about time.
No matter how you define story points, the real issue with them doesn’t go away. The main purpose of points is making planning more reliable, and providing a temporal perspective for business. They never fail to take on a life of their own, however, with teams working to gather points instead of delivering good software. I don’t understand why points are special compared to the oft-mocked cases of bug hunts or lines of code written. If devs are measured on points, they will optimize on points. Has the code base improved? Did it become more modular, simpler, habitable (see the section Habitability and Piecemeal Growth in this book (pdf) by Richard P. Gabriel)? None of these questions is of relevance. The points have to be gathered. The spice has to flow. That’s what counts.
One can of course counter that if you write stories for accomplishing these counter-examples, you would get points for them. But the point of stories is that they have acceptance criteria that can be tested for, and demo’ed at the end of a sprint (see the point on creating user value below). How can you demo that your code base has become more habitable? Will the acceptance criterion be that the code is “just, you know, nicer”? In practice, refactoring that aims to improve existing code is done as a part of new stories. Instead of simply adding more to the spaghetti code that exists, you try to “leave the grounds better than you found”, as per Pragmatic Programmer lore. This might well be true of simple refactoring where you move code, reorganize classes, or rename things, but the really complicated cases that require rethinking of the base abstractions cannot be covered with this simple recipe.
I definitely understand the need for making software development plannable for business purposes. If the business people cannot rely on some kind of an estimate as to how much can be achieved in a certain time frame, they are navigating in the dark, and the developers are in danger of losing their jobs. Programmers also occasionally dig deeper when they have already dug themselves into a hole, so it makes sense to set limits to stories. But there are, must be better ways to make reliable estimations of how much effort stories require.
Scrum meetings (aka rituals) have been among the most miserable hours of my life, and this is coming from someone with a number of visits at the Berlin foreigners office. First of all, they are long. I don’t care that the meetings take place every 2 weeks if I’m going to be sitting there for three hours. They have too many attendants. Most of the stuff presented is not relevant for most people, but everyone comes because there might be something relevant, and because they have to. The review meeting causes utterly unnecessary anxiety (Oh my god, will my feature work?). It’s as if the whole work of the sprint will get evaluated then and there (which in some Scrum implementations actually is the case), and you either get the points or don’t, no matter how much thought you put into a piece of work. The app is now faster? Who cares, I don’t get the exact response that was expected, so no points for you. One implicit requirement of every story is thus “should be reliably demoable to a roomful of people”, which requires much more work than you would imagine (think payments).
In the planning meeting, you get to discuss with others about whether something is two points or five, and then actually list the things you are going to do. I presented my gripes with story points above, but in the context of planning meetings a few more sentences are in order. Why estimate stories that you are going to break down anyway? The breakdown will be a much more detailed analysis of stories, so doing that would provide a much more precise estimate. Another thing that outright astonishes me is how little attention is paid to whether estimations are correct. This is one area where teams can learn the most, because incorrect estimates point to misunderstanding of the code base and domain, but decent review of estimates is rarely, if ever done. Tracking and estimate reviews would also enable Monte Carlo simulation of delivery dates, which sounds awesome, but is, again, rarely done.
Next up is retrospective. Frequent feedback meetings (in which also the estimates are reviewed) are actually a great idea, because the best opportunity to learn from something is right after it happened, but in Scrum, the retro is explicitly supposed to be about the Scrum process itself, not about the codebase, the technology stack or development patterns. So you have this hour for the team, and you are supposed to use it to talk about Scrum itself. Blergh.
The daily standup deserves a blog post of its own. This religious ritual has become a staple of every team in the world. Ten minutes of staring into the void, talking about what you did while no one else listens, because they were in the middle of something five minutes ago and will go back to it in another five minutes, and waiting for everyone else to finish. I know this sounds cynical, but it is the end result of asking people to do it every freaking day. Nowadays devs are communicating on all kinds of channels (email, Slack, Github/Gitlab, ticketing system) and tracking detailed progress on some of these. What’s the point in having them stand around for another ten minutes to repeat a few standard sentences? The daily standup is in my opinion a manifestation of a significant but unspoken component of Scrum: Control. The main goal of Scrum is to minimize risk and make sure the developers do not deviate from the plan. I will come back to “Scrum controlmania” later.
One problem Scrum meetings share with all other meetings is that they are synchronous. For teams working remotely, this can become a serious issue, because you have to synch across continents, ending up with people attending meetings at 7 in the morning on one side of the world, and at 4 in the afternoon on the other. This might sound like a simple scheduling problem, but synchronicity is more than that: It means cutting into people’s daily routines to force information exchange that could as well be handled otherwise. As argued here, the agile manifesto is complicit in this meeting obsession, due to its emphasis on face-to-face communication. What I have a hard time understanding is why the ancient, simple communication form of text is given second seat. The truth of the matter is that, especially under the constraint of distributed teams, it’s difficult to beat text. It is definitely true that writing well without offending others is not the simplest thing in the world, but why not educate the developers and stakeholders in this dark art? They will have to learn to communicate anyway, so you might target this asynchronous mode of communication supported by all tools out there. Text is the best means of communication, and a team that masters it will have a huge advantage. Scrum, however, does not build on text, but on meetings.
Scrum is organized in units of sprints. A sprint is an iteration in which work is done, evaluated, and the process is adapted. The idea of the sprint is that the developers take on a certain amount of work, and do their best to finish it, as in, you know, they sprint. Nobody is allowed to change the acceptance criteria of the stories in the sprint, or add/remove stories. The sprint has its own backlog, which can be changed only in agreement with the team and the product owner. I find the idea that you should get somewhere by sprinting repeatedly rather weird. As any developer will tell you, software development is a marathon, not a series of sprints. But let’s forget the semantic point for a moment, since it’s a bit too obvious, and scrum proponents could claim it’s just a convention that does not have to reflect the actual spirit.
But still, why the artificial two weeks unit? In the above mentioned guide, there is even talk of four weeks. Four weeks is a lot of time, and it is an ordinary occurence that one or more stories become superfluous the way they were written, or other, more urgent things come into focus. If the aim is to be agile, why not accept this as the correct way to work in the first place? In my experience, two weeks is too long for review purposes, too: It’s impossible to remember at the end of the sprint what bothered or satisfied you in the beginning. If you shorten it to one week, however, it feels like spending twice the time in the scrum rituals, although they might be shorter.
There is a more fundamental problem with the sprint idea, in my opinion. The reason software is so difficult to plan is that you discover new things about the problem at hand and your idea of a solution as you implement it. These discoveries affect not only the estimate, but also the actual path you are taking to the solution (as excellently described in this Quora answer). The immediate work items, which consitutes the head of the backlog, is the most affected by these discoveries. So essentially, a sprint is working on a frozen set of items that are most prone to change within that time frame. This is also relevant for the point made above, of assuming a too linear trajectory for software development.
What’s so difficult about software development? Write stories, put them on a board, split them into tasks, and then start processing them from the top to the bottom. Gather points by closing stories, pick a new story after closing one, and watch your burndown chart go down. There are a million complications with this approach, of course. How should the teams manage dependencies among each others’ backlogs? Can I collaborate with someone, or make sure that I’m not stepping on someone else’s toes? One of the most central questions of large-scale software development alluded to above is how to rearrange work in the face of new discoveries as you are actually working; how to rebuild the ship while you’re sailing, so to say. This does happen in Scrum within the sprint, and the results of the sprint flow into the next planning session, but it is not foreseen, or even taken to be possible, that the development team can rearrange work while it is making progress.
The Scrum coach will find fifty ways of attacking each and every one of these topics, but all of them will be in the form of one more thing. One more meeting, one more document, one more backlog, one more item in the definition of done. The development process of a scrum team resembles one of those overly-pimped cars after a while: There are so many fancy bits and pieces that the actual car is not recognizable underneath anymore. The development process starts to resemble the oft mocked enterprise development process, where devs are occupied with attending meetings and filling up some documents more than anything else. Talking about the code the team is writing, and how to improve the codebase, might just be one of the meetings among others, if it at all exists.
Every story in scrum has to end in customer value. The acceptance criteria have to explicitly state what the customers will derive from the results of that story, in the well-known “As a …” format. The idea sounds great in its simplicity, but leads to some really convoluted results when taken to the extreme (which Scrum masters have consistently told me should be done). The most obvious thing is refactoring, already mentioned above. If neither the behavior nor performance change, why even bother with refactoring? And one thing I would be ready to bet my career on is, if you want to develop quality software, you should always be refactoring. As an engineer, I care about many things that will not lead to more sales, or the customer going “It got better” in the very short run. Making the platform more reliable, understandable, aesthetically pleasing is worth spending time on, but none of this is easily expressable as delivering customer value. For that matter, is writing a blog post delivering customer value? Will I get points for it? “As a customer, I want to read Ulaş’s blog post” just doesn’t sound right. What about contributing to open-source software? Reading the code of an important external dependency, such as the web framework your team uses, and working on bugs or feature requests to get a better understanding was not part of any Scrum backlog I’ve ever seen.
One more note on refactoring, since this is a favorite topic of mine. Why is it that scrum coaches keep on saying “You should always be refactoring”? Because the assumption is that refactoring will be a few hours’ work, or even shorter if it’s renaming a class here and replacing a file there. These are only the most superficial cases of refactoring, however. The most difficult refactorings, incidentally also the ones that make the biggest difference, target balls of mud that need considerable effort and work to disentangle, and this is not happening “always”. It is the ideal condition to be able to do mini-refactorings, and improve code little by little, but small steps bring you nowhere in the case of these hardened balls of mud. It’s of course well and dandy if you can somehow magically plan such a complicated refactoring and find a place for it in your backlog. If you can’t, which is much more probable given that deep-reaching refactoring is difficult to foresee, good luck telling your product owner that you will be lost in the depths of your codebase for a while.
Any team that builds something can work on Scrum. This is often touted as a selling point, but it is admission of a shortcoming, in my opinion. Claiming that Scrum is generic is admitting that it is not cut for the specific nature of software development. What is the job of a software developer? Writing code? I don’t think so. I think it’s inventing and customizing machine-executable abstractions, and Scrum has no facilitating aspects specifically for this kind of work. Scrum does not tell you how to organize interdependent processes that mutate while they are in flux. It doesn’t tell you how to match domains to common abstractions. It doesn’t tell you how to distinguish important differences from superficial ones based on context.
Of course, one can claim that this is not the job of Scrum, which is a software management methodology, and not a software engineering methodology, that it’s only concerned with organizing the teams’ time and workload, and anything else is the business of an engineering methodology, such as XP. If that is the case, why the hell am I, the software engineer, doing most of the work – apart from the product owner, whose job description is doing Scrum anyway? Isn’t it by definition the job of the managers, and not of the developers, to be practicing Scrum? Shouldn’t I, as a developer, be spending that whole batch of time and energy on software engineering relevant things, instead of on demoing stories, discussing the ordering of stories, and debugging the process itself? Why are the developers practicing only Scrum, and not, let’s say, XP with bits of Scrum thrown in?
Another sign of the software-distant nature of Scrum is how little talk there is of an agile codebase in Scrum organizations. It’s a non sequitur to think that Scrum is agile, agile teams produce agile code, ergo Scrum teams produce agile code. Having and keeping an agile codebase is crucial to “being” agile, and is actually hard work that requires much more than only following Scrum. It is difficult to introduce processes to manage this work, however, because
Scrum makes claims that it is enough for design to “emerge”, and
Where there is Scrum, people are reluctant to introduce even more rituals and documents.
In short: Does scrum help you write good code? Does it help you achieve modularization, expression, complexity reduction? The simplest answer I have is a clear no.
This is actually my biggest gripe about Scrum. As mentioned above, in Scrum, the gods of story points per sprint reign supreme. For anything that doesn’t bring in points, you need to get the permission of the product owner or scrum master or someone who has a say over them. Refactoring, reading code, researching a topic in detail are all seen as “not working on actual story points, which is what you are paid to do”. Specialization is frowned upon. Whatever technology you develop or introduce, you are not allowed to become an expert at it, because it is finishing a story that brings the points, not getting the gist of a technology or mastering an idea. These are all manifestations of the control mania of Scrum.
I recently read Innovation: The Missing Dimension (my review of the book), a book that focuses on an aspect of innovation that is invisible if you look at design only from a problem-solving perspective. An important part of solving a problem is finding the right problem to solve, and this cannot be treated as a problem itself. It rather requires a community (what the authors call an interpretive community) that can reformulate the given domain and create linguistic and technological tools that allow novelty. This idea is inherent to the original agile principles in the form of individuals and interactions taking precedence over processes and tools. Scrum, however, is much closer to the problem solving approach, where analysis (breaking down a problem, and reassembling the solution) is the organizational tool. In order for an interpretive community to emerge, an organization needs ambiguity, open-ended conversations, and alternative perceptions. All of this, Scrum leaves to something else, whatever it is. They are not the domain of Scrum, but where there is Scrum, there is very little time and energy left for anything else. What’s more, the conditions necessary for the emergence of an interpretive community, and thus for innovation, are seen by Scrum as risk that has to be controlled and eliminated. You cannot Scrum innovation.
You might of course think that innovation is not necessary for you, or that it’s overrated, and your company can survive without innovating. But keep in mind that the software industry is probably the most innovative one out there. There are new technologies every day, and the basic tools of software development go through revolutions every couple of years. If you’re not innovating, someone else who does might knock on the doors of your customers at some point. Also, innovation, in the sense of reinventing, is what software developers love to do, and is a great incentive for keeping top talent.
So, in summary, Scrum
wastes too much of the developers’ time for management
does not lead to good quality code
is a control freak which does not leave room for new ideas and innovation.
Discussion on software methodologies are a bit like discussions of open-source software. The default answer to any substantial criticism is “What is your alternative?”, which is pretty much the equivalent of “Why don’t you submit a patch?”. Unfortunately, software management lies in the intersection of many disciplines, and is a huge field itself. My priorities as a developer lie elsewhere, namely in algorithms, programming languages, computer networks etc. I cannot squeeze in 500-page-tomes on software management into my already crammed bookshelves.
Which won’t hold me back from making probably ill-advised and rather general proposals, or at least a clarification of my expectations as a dev. First, estimations and forecasting. I don’t think there is anything wrong with estimating individual stories in terms of time, and deriving a general estimate of how long a project will take from this. The problem here is that the way stories are split and estimated is orthogonal to the way devs are working. That is, the work I, as a dev, put into organizing the backlog is not helping me in processing the backlog. If it were possible to organize and study the backlog so that this process also helps the devs, they would do it much better and eagerly. One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then resemble a network of equations, instead of a list of items, where solving one equation would simplify the others by replacing unknowns with more precise values.
The other proposal I would have is to get rid of the review, planning and stand-up meetings. Like, just stop doing them. There is no reason to make them so grand and rigid. You can replace most of the synchronous communication with textual communication, and create ad hoc meetings to discuss specific work items. Instead of having sprints that are marked by these meetings, one could simply point to the backlog as a measure of work done and pending. The retrospective, on the other hand, is the only meeting in which I saw magic happen in Scrum, but it has to happen more frequently, and concentrate more on the code base, as mentioned above.
To make it short, my dream workflow would combine offline working, continuous analysis of the sources of complexity and errors, and detailed, open-ended discussion on the path on which the team is approaching the goal (or not). The correct way of building software should align the understanding that devs have of the problem and the complexity involved with the aims of the other parts of the company.