Why should you be concerned about the rise of the Agile?Empire?

A long time ago, in software teams not so far away

Around the turn of the century a lot of things were looking promising: the music was energetic, computers started to be cool, and people in software development got to live out their fantasies of being dark wizards of cyberspace. Life was good, people were happy, but it did not stay this way for long.

A few years later, the software industry became the target of public scrutiny. A few newsworthy stories of software failures causing chaos in the “real world” started gaining traction. People started to realize how important the systems built by their nerdy compatriots had become. And as with all things new, the general populace was concerned about their own safety. Questions such as “what happens if it fails?” or “what will happen when the year 2000 comes around?” were featured prominently in popular media. This even resulted in the famous Y2K Simpsons episode. In short: the end of the world was nigh, and software developers, as well as their bosses, were likely to blame for their cavalier attitude towards quality.

A new hope: agile software development

In order to combat the issues that plagues the world of software development, a group of brave pioneers set forth and tried to share the knowledge they had acquired over the years. This group of people contained some of the most noteworthy names in software development at the time (and in my opinion, still to this day). 

All of them were part of the few developers that cared enough about the profession to create their own processes and developer flow systems. These systems were a structured bundling of the lessons these development gurus had gathered over many years of their professional careers. As with all things IT, plenty of debates had already begun about which of their systems was the best. Developers all over the world started looking for the “one system to rule them all”.

The aforementioned pioneer-developers decided to get together at a ski resort to discuss their shared beliefs (and probably have some drinks and fun along the way). This free-form discussion ultimately resulted in the famous manifesto for agile Software Development. One of the attendees made a simple website with nothing more than their four core beliefs, and a set of complimentary principles that were intended to demystify the four core values. The development world jumped on this wisdom like a pack of starved dogs on a juicy steak. The manifesto and accompanying principles started to become revered as Holy Scripture in the software development industry. Unfortunately, the values and principles contained in this “manifesto for agile software development” were regarded as commandments, more so than as a set of useful fraternal tips.

The empire strikes back: copy-paste adoptions

At first, it was mostly software developers that bought into the manifesto. They held conferences, and tried to deliver software in a better and more relaxed way. The few who were allowed the freedom to work as they pleased, reported good results. 

Fast forward a decade or two, and we see an abundance of agile consulting firms. Each offering training in their “optimized method of agile”. Many of these consulting firms market their agile methodologies as the end-all-be-all of project management. As such, a lot of project leads and managers got very interested in these methods that claim the team will be able to cope with any change of requirements, will always have good estimates, and always deliver on time, no matter what happens or who leaves the team. I must admit it sounds like a wet dream to professionals in a leadership position.

In the world of software development, there is an undercurrent of people that believe something along the lines of “if we can just find the right system, everything will go perfectly!”. If anyone ever manages to come up with the perfect cut-and-paste methodology that can be applied to any failing software project, and instantly transform it into turning a team in crisis into a high-performing team, they will make millions (provided their marketing is engaging and flashy).

Because of these agents and the copy-paste culture in some companies, the agile software development movement starts to increasingly look like an industry of cultist preachers and zealots, kind of like those you would see on American daytime TV shows. A lot of the late-adopter developers trying to deliver good software lost interest in the techniques as their ideas and values were misappropriated. 

Return of the Devi: steering back to the core values 

Recently, my developer heroes, the pragmatic programmers ( Dave Thomas and Andy Hunt), have started proclaiming they regret how popular the ‘Agile’ system they co-created has become. Dave gave a very insightful and interesting talk on the subject at the GOTO conference in 2015, basically pleading for people to stop sheepishly following the latest and greatest flavor of SCRUM, and to steer our ships back to the original values of the manifesto.

I fully agree with Dave when he says that the branding of agile software development has taken a turn for the worse. Let’s take a look at the values that were championed by the original authors of the manifesto for agile software development, as published on agilemanifesto.org. The authors of the manifesto discussed for days to find the perfect wording, they refactored their initial text countless times to come to a manifesto that had “all the right words, in all the right places”. This is the reason that their website contains the line “this declaration may be freely copied in any form, but only in its entirety through this notice”. Unfortunately, the last sentences and the header of the text are often omitted or regarded as of little value.

Easy fix approaches lead to uninformed implementations. 

Uninformed implementations lead to lack of nuance. 

Lack of nuance leads to confusion. 

Confusion leads to unresolved frustration.

Unresolved frustration is the path to the dark side.” 

— Coda, master developer and Devi council member

We started to notice that the combination of agile approaches and our modern cut-and-paste way of applying best practices can be a recipe for disaster. So, how can we do better? As discussed above, there is no silver bullet approach to this. We should aim to be good at our jobs, and strive for agility in our daily jobs. 

I can tell you from personal experience that sometimes the most agile teams are the ones that officially follow a “waterfall process” but live and practice the values of the manifesto on a daily basis. Your project structure will not stop you or your team from working in an efficient way if you know how to apply the principles behind the manifesto. Conversely, just applying an agile framework (such as SCRUM) will not make you productivity gods overnight.

I doubt there is any boss or customer that will sit next to you, look at your computer screen, and tell you not to use TDD, orthogonal design, or developer notetaking.

Join the rebellion! You are our only hope.

If we are to stand a chance against the over-simplification and frustration that is commonly associated with the adoption of “fake agile”, we will need YOUR help. If you are thinking “Sounds cool. What can I do?”, keep reading.

In short: focus on being the best developer and team member you can be. Do not fall for easy-fix solutions to complex questions, such as “how can our team be more efficient?”.

The journey will be challenging, but much more rewarding. I implore you to seek answers to these questions that work well for you and your team. Referring to the ancient Jedi texts can give you insights, wisdom, and guidance.

As this is easier said than done, allow me to offer some practical tips:

• One of the best pieces of advice I have heard was one particular sentence from a talk by professor Rini Van Solingen (which can be seen here. warning: Dutch version). To paraphrase the quote a bit: “When I do not know which approach to take, I think of how it corresponds to the agile values. If it helps me steer more towards the left side of the statements, it’s likely a useful experiment to try.”
• I would also advise you to take a look at the manifesto for software craftsmanship, Andy Hunt’s GROWS method, and the CommonS3nse Framework (S3). These resources contain a plethora of useful and practical tips that can be applied to almost any environment.
• Just remember to not go full “Han Yolo” on your endeavors and to make sure you do not make life harder for your teammates on your quest for mastery of the noble art of pragmatic programming.

“This is pragmatism. An elegant weapon for a more civilized age.”

— Obi-Dev Codobi

Roll credits!

I hope you enjoyed the article, and are inspired to dive into the rabbit hole of essays, papers, and websites that are written on the subject of team performance, and personal improvement.

If researching these things is not your particular cup of tea, keep a look out for my next articles on the subject. I intend to dive deeper into the subjects of “effective communication” and “taking back control of your learning”.

As always: Have a nice day, and Happy developing!