There’s been a trend lately of IT thought-leader types claiming that the Agile movement is dead or dying. There are, of course, a ton of organizations still using Scrum and other Agile methods to great effect. And I still believe that Scrum is responsible for amazing improvements in the quality of life and value delivery […]
There’s been a trend lately of IT thought-leader types claiming that the Agile movement is dead or dying. There are, of course, a ton of organizations still using Scrum and other Agile methods to great effect. And I still believe that Scrum is responsible for amazing improvements in the quality of life and value delivery for teams.
But I can’t deny that public enrollment numbers in certified training have fallen off a cliff, as has demand for experienced Scrum Masters, Agile coaches, and related titles in the job market. So, if the perception that Agile is dying is starting to take hold, the trained criminologist in me wants to know: who killed it?
After thinking long and hard about this, I’ve come up with a few suspects. Each of them will be addressed in a separate post. I’m relying on you, dear reader, to be the jury.
The first suspect was examined was your boss and ways that an organization can derail Agile adoption while blaming it on issues that are really features of their pre-existing culture. The second suspect was SAFe and the way it’s coopted the brand of Agility and the entire Agile community has been scapegoated for SAFe’s failings as a result.
Now we turn to a final suspect: a changing world that may undercut the foundations of the Agile movement.
All things have a season, and trends in management and technical approaches are as rooted in historical context as anything else. In my own professional lifetime, I’ve seen a number of ‘next big things’ come and go in the AppDev space: Total Quality Management, CMMI, ISO 9xxx, Lean Six Sigma, PMBOK. And that’s just a few!
While most of those stemmed from manufacturing contexts, Agile methods were unique in that they very explicitly came from software development. Many of the core assumptions of the models we know today as Scrum, XP, or Crystal are clearly based on features of software creation that were mostly universal for the last 30 or so years. Many of those premises are still true. For example: that delivering in small iterations reduces incremental risk or that delivering functional slices of product positions a company to rapidly pivot to market shifts. But there are two assumptions I want to examine in this article:
Software is a thing created by people…
…who do it sitting near other people in a centralized office.
In the last four years, the challenges of COVID and the onset of generative AI tools have called both of these elements into question.
Agile methods don’t claim to be incompatible with the idea of remote work, though that’s a common misconception. But there’s a reason that the Agile Manifesto says:
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
The message was never that remote or distributed teams can’t work. Instead, it’s that a team that’s communicating from afar will always have a slightly harder time being a team than if they could just sit around a table together.
A certain amount of their energy will always be lost in the overhead of meeting requests and textual misunderstandings. A co-located team can skip this and redirect that energy into more productivity. That was certainly my own experience working as a Product Owner or Scrum Master with teams that were split between two physical locations. Same goes for teams that were mostly collocated but with one or two members who were remote. So, I recommended that organizations centralize teams whenever possible. That might bump up the per-Sprint cost of each team in expensive locations, but the productivity boost we got as a result would more than make up for it.
But then along came COVID and suddenly teams everywhere became entirely virtual overnight. All communication was shunted onto platforms like Zoom and Teams. And there were huge benefits to orgs and workers. No time lost to commuting! No geographic limits to candidate pools! Easier childcare! Less office-related overhead! All of these things are awesome. But there are consequences for the quality and quantity of work produced, and for the experience of doing the work.
Initially, the effects were less noticeable. Teams that had formed strong team identifies in person before the pandemic were largely able to maintain those bonds when they traded cubes for kitchen tables. But for teams that have only ever been remote? They struggle with fundamental questions of trust building, emotion sharing, and psychological safety that seem insurmountable when we only talk through tools. Problems arise like:
How do I get my team to turn on their cameras?
How do I know that everyone is engaged in a conversation?
I think half my team is secretly moonlighting…
No one will talk in retrospectives…
Those issues are so much easier to address when we’re in the same room. Yet so much harder when everyone’s reduced to just a letter icon in a virtual meeting. This is why even Zoom….yes, Zoom!…is starting to require team members to work on site. The announced reason for that change is that they were “having trouble establishing trust in teams that had never physically met.”
So, why does that matter for Agility? Whatever assumed return on investment an organization thinks it’s going to see from a team adopting an approach like Scrum isn’t discounted for the realities of fully remote teams. As a result, I think Agile frameworks are being seen less effective than they used to be, without understanding that distributing team members has lowered the ceiling on what’s achievable.
A strength of Scrum and other Agile approaches is that they point out the power of small teams to accomplish incredible things. Small teams outperform individuals because they allow for greater cross-functionality and resiliency. Cross-functionality refers to the state where a group has all of the skills and abilities needed to go from an idea to whatever ‘done’ means as a collective. It doesn’t have to mean that everyone on the team can do every aspect of the work; it just means that together they can cover all of those skills.
Resiliency refers to a team’s ability to share capacity and availability so that whatever short term plans they make are likely to be completed. Small teams outperform larger teams because they have fewer communication channels that they can self-manage work. So, the most effective and efficient way to build a product by people is to organize them into groups of less than 12 members. Then, let them self-manage toward a shared goal.
But what if the product is not going to be built by people? The sudden onrush of generative artificial intelligence in the software industry has a lot of folks wondering if knowledge-based occupations like software developer and engineer will persist. This speculation, paired with a number of large tech lay-offs in recent years, has a number of my students feeling pretty bleak about their career prospects. But upper management types seem to be salivating at the prospect. “If one person can generate the same productivity as a team,” some organizations are beginning to think, “then why we do need team-based approaches for anything?”
The perception that teams may no longer be necessary directly strikes at the justification for methods like Scrum. And since Scrum also tends to expose a lot of ‘inconvenient’ organizational truths about what’s really in the way of teams delivering value, deciding that we don’t need Agility is a good excuse to go back to pretending those problems don’t exist.
So, if Agile approaches are seen as less effective (because distributed teams have been less effective), or if teams are seen as obsolete, that undercuts the case for Agility in the first place.
I’m not ready to accept that Scrum or Agility are actually dead. One reason for that is that I keep seeing job postings from companies trying to hire someone with all the skills of an Agilist, but under different titles.
That tells me that while people may be leery of the vocabulary, they still understand the value proposition of the people who made teams great. So, if you’re looking for those skills, certified Agile training is still a good place to find them. Check out NextUp Solutions’ trainings here.