Over the course of my career, I have had the pleasure of working on a variety of teams in a number of companies, which has given me the opportunity to experience how things are done in a multitude of environments. Each company and team has their own unique culture, but with enough experience, patterns tend to emerge. One of the most notable for me has been with Agile.
It’s no secret that Agile has been co-opted by management to become the very problem it was meant to solve—that instead of removing barriers to work and providing opportunities for better communication we have added more in the name of “going faster.” And that instead of promoting direct collaboration and customized team environments we have pushed for more documentation and certifications in search of doing things the “right way.” I will admit to being just that little bit annoyed every time I see “Certified Scrum Master” or worse, “Certified SAFe Practitioner” in my LinkedIn feed.
What has shocked me the most, though, is the sheer prevalence of Anti-Agile practices. Anti-Agile is a term I started using when I noticed that many of the “Agile” practices I was instructed to follow went contrary to the Manifesto. Does it fit best if you read the lines in the Manifesto forwards or backwards? If it’s the latter, then it’s Anti-Agile. What I had initially believed to be a localized issue with the company I had been working for at the time turned out to be industry-wide and that’s when I realized swimming upstream against the wave of certifications, trainings, and other corporate-mandated activities was a futile effort.
Where we went wrong
One notable observation I have made in multiple companies, is a noticeable lack of desire from most developers to be heavily involved with managing the team processes. Developers, almost universally, have been quite happy to hand over management of the team processes to someone with Scrum Master as their job title, if that meant they never had to do it themselves. Agile is not dead because management took it away from us. We, as a developer community, willingly chose to give it away.
It is the fact I find myself surprisingly alone in my desire to both understand and improve upon our team processes that motivated me to write this post, because I think it’s here that I am contributing some new insight and not simply rehashing an old idea. I have found management to be generally more receptive to Agile than most developers, because they have a more direct interest in increasing team adaptability and/or efficiency than the average developer.
Before I get too harsh on my peers, I think it’s important to point out that these attitudes do not exist in a vacuum. Senior developers who once held the energy and enthusiasm I do have had it stripped from them by years of immovable management. For others, but senior developers especially, Agile is yet another thing to know on the ever-growing list of things to know. And in an attempt to recapture time for actual development work, offloading the team-level concerns to someone who has the time for it provides a welcome reprieve. I don’t see handing over Agile to management as a result of irrational decision-making, but the result is the same nonetheless.
Where do we go from here?
If I had a solid answer for this question, then I would probably be publishing books about it (and perhaps running expensive training courses with associated certification tests to make it big on my newfound success), but I think the short answer is to do everything, and nothing.
The fundamental challenge is that teams who closely adhere to the original Agile concept and find success likely would have done so following any methodology. Conversely, a team struggling to perform will do so regardless of what methodology they attempt to use. As is quite universally true, the fundamentals are what make the difference and not the smaller details. To create a high-performance team, we need only look at what makes any team successful, independent of any methodology or industry – good communication, mutual respect, clear goals, and the ability to depend on each other.
Creating and maintaining a high-performance team requires substantial work and having a framework with which to focus that effort in a way to increase the likelihood of a successful result is useful. So, methodologies like Agile, even if co-opted, are not without value to those who need them, but those teams who benefit from them are outnumbered by those who don’t and it’s difficult to see how Agile’s present situation is not the eventual fate of similar movements that may arise in the future.
I believe the answer is to do everything to make our own teams a more open and welcoming place for our team members to collaborate and communicate and to do nothing to create the “next Agile.” Because no matter what misshapen form Agile might take on in the future, making our teams successful relies on all of us making it so, developers and managers alike.
Adam Lif 