Anyone entering the software development industry nowadays does so at a time when Agile ways of working are the norm. Even for those that recall the traditional approaches, it now seems unthinkable to expect a team of developers to digest a 300-page specification document and emerge with a first version a year later. Instead, delivery cycles of a month or less have become a reality; testers, developers and business analysts collaborate face-to-face in real time rather than through written documents; and even traditional managers are beginning to accept that developing software, especially for business, has unique challenges that require a flexible approach. For better or worse, Agile has made its mark and is here to stay.

Scrum was and still is the vehicle that the Agile rides but for all its triumphs, Scrum finds itself in a difficult position; perhaps, ironically, a victim of its own success. In helping to spread the Agile mindset, a new baseline for software development has been established; one against which Scrum itself can be measured. With the industry now aware of and open to the values and principles of Agile, questions are being asked about whether Scrum really is the best way to implement it. Lest we forget, Scrum is not Agile, nor the other way around, and while it was perhaps mutually beneficial for the two to be synonymous for a time, the situation is now different.

Is the sprint still worth it?

When the authors of the Agile manifesto thought about how often software could be delivered they considered frequencies “...from a couple of weeks to a couple of months, with a preference to the shorter timescale” to be reasonable. Scrum goes for the ambitious side of this by stipulating a maximum sprint duration of one month, with many organizations opting for two-week sprint cycles in practice. But neither the authors of the Agile manifesto nor the proponents of Scrum in its early days could have foreseen the sense urgency that the so called digital age would create. With many teams nowadays achieving daily releases of software to production, some even multiple times a day, delivering software on a two-week cycle is hardly considered an ambitious target. Trends like DevOps, CI/CD, and serverless computing - all of which encourage much more rapid develop, test and release cycles - have emerged as practices fast on their way to becoming industry norms. Just as the sprint sought to dissolve the artificial boundaries imposed by traditional ways of developing software, so too do these more recent trends. They change our notion of what it means to be agile.

Teams that stay at the forefront of the these trends are starting to question whether arbitrary sprint boundaries still hold any significance. It may be an inconvenient truth for Scrum, but the fact remains that modern software development practices have robbed the sprint of its power.

Team first, framework second

A curious revision to the Scrum guide between 2013 and 2016 added the five values of Scrum. Ken Schwaber — co-creator of Scrum along with Jeff Sutherland — explains: “When the values of Commitment, Courage, Focus, Openness and Respect are embodied and lived by the Scrum Team, the Scrum pillars of Transparency, Inspection and Adaptation come to life… We added these values to The Scrum Guide because successful use of Scrum depends on people becoming more proficient in living these five values”. Sutherland adds: “This update to The Scrum Guide officially recognizes the significance these values have to any Scrum team”.

But are these not the values of any group that aspires to be called a team?

Real teams embody all the qualities Schwaber mentions and more, but if the successful application of Scrum is predicated upon their existence then this is surely the thing to focus on getting right first.

To be fair, Scrum has always championed the idea of the team, calling for them to be “self-organizing” and “highly flexible and adaptive“. But “officially recognizing” the need for real teams is one thing, establishing them in practice is something else entirely. It seems that in order for Scrum to work, teams have to come as a prerequisite.

Of course, Scrum needn’t say much about the nature and qualities of teams; how to form and sustain them; the added value of a team and indeed the cost of ownership. These have been studied for decades, if not centuries, and the body of literature we have is there for all aspiring teams to capitalize on; not just Scrum teams. Organizations that believe effective collaboration is crucial for success may well find that establishing the presence of real teams is where the real challenge lies, irrespective of the framework or methodology employed thereafter. The corollary is also true: without real teams, what does the chosen framework matter?

After many years of operating and observing Scrum in the field, it appears that Schwaber and Sutherland felt compelled to acknowledge the importance of a solid team underpinning — albeit disguised somewhat as Scrum values — and amended the Scrum guide accordingly.

In any case, values and principles are not the domain of frameworks or methodologies, at least for those with intentions of being put into practice. These are best left to philosophies, schools of thought, and manifestos, which have the luxury of remaining abstract. This keeps them shielded somewhat from shifting zeitgeists and in turn gives them a greater capacity to endure. Thus, if persisting over time is the objective, transitioning from the practical to the philosophical and the abstract is one way to go, but it’s difficult to be both a philosophy and a practical framework at the same time.

The good old punching bag

Are there situations where a more traditional approach actually is the most appropriate way to develop software? Even enthusiastic Agile practitioners should not be closed off to that possibility. A clear, documented specification; well-thought through, expert design; and careful planning with solid execution, surely have a place in software development. The authors of the Agile manifesto in their wisdom and experience knew this, hence their choice of words is deliberately cautious so as not discard traditional ways of developing software entirely. They wrote a manifesto, not a framework to be followed in any practical sense, and had the luxury of keeping the values and principles abstract and ideological.

Scrum on the other hand plays in the framework space. It is prescriptive, tangible, and meant to be put into practice. But while principles and values are there to stand the test of time, frameworks and methodologies don’t necessarily have to. As it turns out, certain categories of software development, particularly software development for business, have proven to be an awkward fit with the “big design upfront” approach. The beleaguered and uncherished waterfall methodology fell out of favor because of this; a fact that Scrum advocates rarely shy away from pointing out. In fact, juxtaposing Scrum and the waterfall methodology is a staple rhetoric for those eager to cast Scrum in its most favorable light. As Sutherland puts it on his Scrum Inc website: “While some say Scrum is not a silver bullet, it can be a heat-seeking missile to outmoded business practices”. The truth to this remains only so long as the outmoded practices he speaks are the ones rooted in the 20th century. But how much longer will Scrum advocates be able to create and exploit a dichotomy between their framework and decades-old practices that have long since fallen out of favor?

A post-scrum world

Those curious about experimenting with Agile methodologies other than Scrum are likely to face some resistance. Scrum is effectively the new norm and norms are always hard to break no matter what. The industry built around it over the decades is large enough to sustain careers and even entire companies so, naturally, there will be those actively promoting it no matter what.

Nevertheless, Agile has long since taken off in its own right, and though there is some way to go before it disentangles itself from entirely from Scrum, new frameworks and trends are able to emerge as the Agile space is explored. Many of these have already gained significant traction. Having options can only be a good thing for software development practitioners and organizations alike. Scrum will likely be around for some time, though it faces the pressure to adapt to the modern ways of developing software. Whether it can or not remains to be seen.