This post summarizes my view on negative impact of Scrum on development teams, and why other alternatives should be considered.
What Scrum Really Is?
Scrum describes itself as “... a framework for developing and sustaining complex products… Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value…” (SG2013, Page 3). The descriptions of goals and values that Scrum is trying to achieve are changing from one guide revisions to another, still the framework itself, which consists of well defined participant roles, events, and artifacts stays more or less constant. I will not try to argue about the goals and values themselves, or efficiency of the framework to achieve them. My goal is to explain the negative impact, that, in my opinion, Scrum will inevitably have on the projects where it is used, specifically speaking, software developement projects. This impact I have experienced personnaly, while participating in several Scrum projects in different organizations.
The uneasy feeling, that Scrum impacts negatively my work as software manager or programmer, was always there, from the day one of my involvement with Scrum projects. And due to the fact, that Scrum turned out to have a very long lasting effect on the industry, which is not going to dissapear any time soon, I decided to do some retrospective and reflective thinking on what exactly in Scrum, made me feel so uncomfortable with the framework.
Briefly speaking, the conclusion I eventually came up with, is that despite prevailing claim that Scrum is an agile and adaptive framework, it is actually anything but that. First, somewhat ironic, proof of this idea, can be found, or more precisely “not found”, in Scrum guide itself. The word “agile”, suprisingly, is not found even once, in the Scrum Guide (2020). Second observation that you can make to convince yourself that agility and Scrum are at least orthogonal, if not opposite concepts, is that even Scrum arch-nemesis – the Waterfall can be easiliy embellished with sprints and daily meetings and call itself a Scrum while still having its, one way, inflexible nature. But of cause, the best way to convince yourselves that Scrum is not agile, is partipating in Scrum projects yourselves and finding your ability to meaningully and timely impact the development process being severely diminished, in comparison to traditional projects management approaches.
It is important for me to emphasize the idea, that Scrum issues are embedded right into into the framework. This means that there is no “right” way to implement it, without avoiding the negative consequences. This idea is an opposite, to the claim which I see quite frequently in different discussions online and offline. The claim that basically shifts the blame of Scrum techiniques implementaion failure on the implementors themselves. The latter, can be summarized like that – “If Scrum doesn’t work, then it is not a real Scrum”, which is of cause just another occurrence of “No true Scotsman” fallacy. Also many claims made by Scrum proponents are frequently “values” based. By that, I mean, that for these proponents, simple claim that Scrum “wants” to achieve values X and Y like “adaptiveness” or “agility” cancels the nececity of proof that suggested framework actualy achieves them. And as I already noticed in the Waterfall example that might not be the case.
Getting straight to the point, the exact reason of why Scrum becomes so inflexible, lies in my opinion in planning project milestones, and measuring its progress in Sprints. In additions, daily meetings will further introduce a senseless rigidness in your project planning adding the flavor of artifical daily pressure and army “discipline” to project participants routine.
I will now briefly explain why exactly sprints and daily meeting can harm your chances of success in long term, sufficently complicated project.
Sprints planning considered harmful. Sprints are at the heart of Scrum framework and, by far, its most recognizable attribute. Scrum is a never-ending treadmill of project milestones marked by the end of the sprints (“A new Sprint starts immediately after the conclusion of the previous Sprint“, SG2020, page 7). During each sprint the team must be committed to achieve some pre-defined goal. Scrum team should be reluctant to make changes to sprint goals in the middle of the sprint run (“No changes are made that would endanger the Sprint Goal“, SG2020, page 7). In regard to sprints duration, sprints are described as “… fixed length events of one month or less to create consistency… (SG2020, page 7)”. In practice, they are between two and four weeks long.
The issue with sprints, is that its senseless rigidness is a bad fit to the richness of processes that occur during any sufficiently complex projects. And such projects constitute a vast majority of all software development projects in the industry.
Sprints cause the situation where, instead of letting the project timeline in general and milestones in particular, arise naturally, from analyzing its building blocks, their effort estimation and dependencies, the framework constricts the project to artificially fit into Scrum sprint boundaries. The condition, that after each sprint some minimal valuable product be presented, along with the fact that changing the goal during the sprint is frown upon, makes output planning much less effective and organic to the project “normal flow”, than it would be, if sprints time constraints were not present at all. It is like if a flexible water pipe which could be used to freely connect facet A to facet B, was replaced with solid rigid pipes connected by joints, of length long enough to make connecting two facets, while avoiding the obstacles in the middle, a very difficult and annoying puzzle.
The end-of-sprint schedule, does not make sense from natural project development angle, to begin with, and that’s why it is rarely negotiable. In other words, because sprints were not derived from some natural miletsones but consitutes an artifical two or three week boundary, being late hitting the “natural” milestone , even if it was the Sprint goal, will not help moving it. Then, it serves to induce a sense of urgency because of constant non-negotiable deadline looming up a front. The issue is exacerbated further, by the fact that different independent teams across the organization are sharing sprints’ schedule, which makes changing sprint schedule for single team impossible as it will impact many unrelated activities and strata in the organization.
Sprint time span of several weeks is long enough for achieving some measurable result on one hand, but too short to give substantial time for reconsidering the sprint goals without immediate impact on the current sprint schedule. This brings a very subtle, nevertheless important, outcome of sprints framework – the lack of time for doing critical thinking for developers during the Sprint, and not much time to do it either in between. Empirically, I became convinced that Scrum teams members are spending much less time doing thinking and re-design work than in traditional non Scrum development process. Again, I think, it is related to the very small window of opportunity to “think without retribution”, that exists only for very brief time between the Sprints.
“Thinking” means taking constantly re-evaluating current design and planning. It is a sporadic process which can be hardly planned on one hand, and time-consuming on the other. When working in sprints, “Thinking” introduces the immediate danger of at least some schedule slippage, or “risk” of adjusting the Sprint goals which is not something that is welcome by Scrum framework. As a result, in many situations, Scrum participants tend to sacrifice the quality of the product in the long-run, in favor of achieving short-term Sprint goals.
Process of software development is more similar to going over spiral than straight forward building process. One sometimes need to cross the same point several times. For every two steps forward at least one step back must be planned for. And of cause, the timing of taking these steps backward should not be limited in any way, in time. The planning framework of the project must be flexible enough to allow making ajustments and re-evaluation to project goal and schedule at any time, not just in-between the sprints. The lack of such flexibility is severely impacting the ability of the participants to adjust the project to changes, and make critical project steering decisions in timely fashion.
Daily meetings. In regard to this one, I need to make a caution note. Today, in the times of remote work, frequent team meetings are the best alternative for managers to stay up to date with the rest of team and impose the window of communication of everyone with everyone, which would naturally occur in the office. Also daily meetings can be a very effective offline communication tool, which must be in the tool set of every manager. Syaing that, It is better be used for short periods of time, when the project is in critical stage and every day really counts. However, if your project is always in “critical state” where there’s an urgent need to count each day of progress toward the goal, then you’re doing something wrong.
Scrum prescribes daily meeting routine indefinitely, regardless of the urgency status of the project. Its main purpose “… inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary…SG2020, page 9″. In other word, it is just another tool to introduce the rigidness of the Sprint goals into the project, and deny from developers to even think of taking a detour or spending time on re-evaluating the Sprint outcome, justified or not. The level of details that SG prescribes for the daily routine is mind-boggling. It limits the time and the space of the event, without even marking it as recommendation – “… The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint …”. I cannot help myself to think that such prescription belong more to the army routine rather than daily life of developer in the high-tech industry. All in all it is just anoter nail into the coffin of possiblity of having a necessary degree of freedom for taking time for critical thinking and adjusting the plan at any point without undermining the official sprint goal.
Last but not least, daily routines with constant measuring of progress induce constant feeling of urgency which brings team quickly to the state burn out and indiffirence.
What Else?
Other details of the Scrum like backlog, team roles etc are actually have lesser effect on team productivity. Not least, because they are somewhat exotic, and I rarely have seen the roles of the Scrum team being implemented exactly as prescribed by the guide. The corporate natural hierarchy still constitites the basis of any Scrum task force with the traditional team leaders wearing the hat of Scrum masters and product or marketing team representative naturally falling into “product owner” category. The sprints and dailies on other hand are followed with much greater discipline.
Why SCRUM is so prevalent? If Scrum does not bring any improvements to the table but only impacts the productivity of the team, why it became so prevalent? In summary, it happened because, Scrum is an ideal choice for corporate managers. As explained below:-
- Scrum as blame sink. There is an urgent need of the management, to formally follow any well known framework during software development process in corporations, in order not to leave a place for personal blame that the software development was not managed in an inadequate manner. This fear of being blamed is more substantial in the software development industry, which is characterized by very high risk of project schedule slippage, cost overrunning, and failure to deliver a quality product. The Scrum hype and its snowballing adoption in the corporate world only increased the price of “not following” the practice, making it virtually impossible to avoid in a modern work place. Scrum has no real alternative as a clear, defined process for building software development process. The Waterfall that Scrum claims to oppose, is not a framework but just a derogatory term used to some non-agile practices “before” Scrum. It is non-existent, in a sense that there’s no organization that claims (or claimed) that it has implemented the Waterfall methodology, and, of course, there’s no “Waterfall” certification. The agile practices like “Test-Driven Development”, “Extreme Programming” etc., has no clear path to implementation, which leaves Scrum as the only implementable candidate for corporations.
- Scrum is cheap. The guide claims that Scrum is “Lightweight, Easy to understand and Difficult to master”. The “lightweight and easy to understand” is referring to simple well-defined structure of Scrum events. Scrum framework does not involve any real investment into supporting infrastructure, be it software or capital. The first Scrum teams were using white boards and yellow stick notes. Also, there is no external certification body, to confirm the quality of Scrum implementation, like ISO for or PMI for example, that confirms the adherence to Agile practices in the organization in return for not so modest payment. So the organization can claim using Scrum freely.
- Scrum is not intrusive for higher managers. Scrum’s “small”, “self-organized” teams with no-titles-practices are targeting the lower levels of Corporation because only there it can somehow exist. Upper management is not involved and are not bearing any effort in participating in the events
So what’s next? We surely will see Scrum for the long time in the future. Scrum practices became deeply rooted in corporate world. A new generation of project and software managers probably has been raised which have seen nothing but Scrum from their early days in the industry, and in no position to take the risk of doing things differently.
But this text is not only a criticism of Scrum. It is a call, call for action to continue working and researching the ways which will truly help us developing software in a way that will provide engineering products of highest quality without sacrificing the costs, and mostly important developers’ excitment and joy from being involved in a creative process of building the software. Almost a hundred years after the first program was written, we are still at the begining of this journey.