Scrum and the Backslide into Incivility

Scott Bellware
Mad About Software

--

Suggesting that the software methodology wars are comparable to the fight for basic human rights in the US in the 1960s is a stretch, and its not meant to depreciate the sacrifices of the civil rights activists of that time, and the improvements they brought to society.

Nonetheless, I increasingly reflect on the parallels between growing up in the shadow of the civil rights movement and growing up in the shadow of Agile software development that has become synonymous with Scrum.

I grew up in a world that that the civil rights movement created. I was born into it. From my perspective, civil rights was always the way that the world was, and the systemic racial injustice of the previous decades was part of an ancient history that could never return. I took it for granted. And that’s why the progress and advancement of civil rights has been actively eroded in the interim.

We think it emerges from nature rather than effort and struggle to make sure that better ideas aren’t suppressed by those who stand to lose if better ideas disrupt the status quo. And because of that, the progress made by the civil rights movement is not being defended from exploiters whose efforts never ceased while the efforts to defend progress have receded.

The most recent generation of developers have never been inculcated into the reasons why and the ways and means of making sure that software development improves, and of making sure that the conditions of the work and the workplace improve, and continues to improve.

I was one of those activists for better software development that used to be called the Agile Software Movement in the days when Scrum wasn’t really taken seriously as a significant enough contribution to make a difference.

Extreme Programming was practically a labor rights movement for software developers. It was a fight for permission to pursue excellence, to not be compelled into participating in the gaslighting of project oversight methods of the time, and to be free of the inefficiencies that required us to work at a level beneath our level of capability, and far beneath our potential. It was about bringing safety to the work so that we could both deliver on needs and excel at it. We fought for permission to do software development in a way that makes software development sustainable, and we fought for this against the momentum of ideologies that sees software labor as a lower class and largely disposable.

We had to develop enough demonstrable excellence in our work that we’d have enough credibility to push for changes

And to do this, we had to develop enough demonstrable excellence in our work that we’d have enough credibility to push for changes. And it wasn’t easy. Many teams had to do it covertly, running a secret Extreme Programming project while simultaneously supporting the process and work management regime that was in-place.

And eventually, the tenuous hold of improperly-employed phase-gate methods loosened, and Agile started to gain prominence.

And that’s when the hordes of Scrumites started pouring over the walls to claim the hard-won progress of the grass roots Extreme Programming for itself, effectively replacing the historical account with something that favors its own market dominance imperatives, and displacing the honest hard work of people who are actually in the work, and not merely near the work.

And this is the environment that the code school generation of developers of recent years is born into.

In this generation, “Scrum” is just “Software Development”. It presumes that this is what Agile change agents were doing and what they fought for. It presumes that Jira and the like are essential to Agile, rather than an appendage that has as much to do with Agile as your chosen color scheme. It’s a generation that wasn’t filled on on the fact that we considered Scrum to be mostly a sideshow to the tangible advances being made by approaches that address not only the requirements management side of things, but also the needs of producing software without also producing setbacks.

I grew up after the civil rights movement. I presumed it was an immutable part of nature and that it was permanent. We can easily see today that the advances in civil rights are not permanent and have been continually under attack. And the same can be said about software development.

We made tremendous advances in the early 2000s from the over-elaborated, high-ceremony and high-bureaucracy mainstream processes that preceded Agile, to the focus on sustainability and continuity in software work. And yet, we’re right back to where we started, but it’s now just a new generation of mindless, over-elaborated, high-bureaucracy high-ceremony.

I was chatting with a rookie developer about being sent to Scrum training with his team. The first thing that came to mind was, “How far we’ve fallen”. He could learn more by just going back to the XP and TDD texts that haven’t gone anywhere. And I thought to myself, “No one could compel me to go to Scrum class.” What a massive step backward that would be from the advances we had already made by 2005.

And in that gloomy state of mind, I couldn’t help but reflect on how far we can fall when we believe that our past wins don’t have to be perpetually-reinforced and protected from the encroachment of elements that patiently wait to take full advantage of momentary distraction.

--

--