Punk Rock… often shouted political, anti-establishment lyrics. Punk embraces a DIY ethic; many bands self-produce recordings and distribute them through independent record labels.
This mainly describes not only my philosophical perspective on politics and music but also on systems theory. At some point, maybe not when you start, “Question the system and try to do it by yourself”. In the case of software development, we find ourselves constantly immersed in an abundance of systems: software architecture, team topology, team dynamics, development processes, bureaucracy, infrastructure, methodologies… and as a self-proclaimed agile evangelist (but with a punk rock heart), it’s finally time to say once and for all that agile, as we thought we know it, is dead. And here, is a little dissertation on the why.
The beginning
It all started with a bunch of geeks doing a ski retreat and coming up with 12 principles written in blood for the bible of modern development. Long story short, they came up with some cool ideas about being a little bit less rigid when developing software because they suddenly realized they were human beings in the real world. Individuals over processes, software over documentation, change over rigid plans… more or less. Pretty legit. But, as it happened before with many sacred manuscripts, dark forces started stretching the meaning of things and claimed to be the only source of truth. As perfectly put by Dave Thomas in the following video, they morphed an adjective into a noun to sell fear and coolness for profit. The whole cult for scrum started growing (the scrum alliance, scrum Inc., scrum.org…) after the manifesto was created.
The world was not prepared for the tech startup bubble that was about to start with the iPhone launch. Software development started being one of the most profitable jobs in the world and its popularity grew (everyone can be a developer now if they put in a little bit of effort). They just need to figure out by themselves that programmers don’t really code, they just search in Stackoverflow and copy-paste®️. At this point, we find a lot of rookies willing to code and earn good money while lacking any experience. Someone had to bring some order there. “Say no more”, said the CSM™️ (certified scrum master). We are going to take those agile principles that literally say nothing about software development and start building frameworks that sound cool enough to make people think they are actually working. Instead, they managed to make us all lose time, money, and sometimes, even the will to live.
The End of Agile
“Stop thinking and get certified today”
Don’t get me wrong, everyone should learn scrum and work with it for a while. It’s like the basics of cooking, everyone should have that knowledge and experience before opening a restaurant. But you can’t have a restaurant that only boils vegetables and grills meat. Well, in fact, you can. But you can not pretend that this is going to work for all the restaurants in the world. And if you fail, then you are not really doing scrum.
One of the people invited to that infamous retreat was already claiming that agile was dead 10 years ago, but it seems that agile and scrum are not dead but expanding to other industries! So we keep selling empty frameworks that waste tons of hours in useless meetings and metrics instead of doing the work because no one wants to take ownership of the hard tasks, analyze the situation, and come up with a plan that makes sense to improve things. This might be explained by the maxim that any plan is always better than no plan.
Agility can be reduced to three steps:
- Find out where you are (analysis)
- Take a small step toward your goal (plan and deliver)
- Adjust your understanding based on what you learned (learn)
(Edit: these 3 steps are described by dave thomas in the video)
Once you understand this you have two options:
- Analyze your products, your customers, your business, your teams, your engineering practices, infrastructure, etc. Then come up with a first solution that can deliver something. Deliver. Analyze what went well and what went wrong. Communicate between the teams involved. Be transparent. Add those learnings to the next iteration. Repeat.
- Hire a scrum master, product owner, and agile coach, close your eyes and pray.
It seems, that for most people (or companies) the second option is the way to go. And this is what caused the death of agile: too many entities selling snake oil to upscale your business. Agility (or what they call agile) focuses only on a small part of the business and it has been sold as the solution for everything. I even worked in a company that was using a Jira project named Scrum for their product platform, which clearly illustrates the base error of mismatching the signified with the signifier. A lot of people who don’t understand how software development systems work assumed that just by mindlessly believing in the agile/scrum commandments they would be able to make successful decisions without even having to figure out what they were actually doing. That’s why, to work in software, it’s so important you either: make software on your own (even in your free time) or you are highly curious about how technology and systems work. Otherwise, you will never be doing anything good, new, or efficient.
During all these years scrum, agile and their certifications and environments have been in a parallel world that has ignored important events like DevOps, Lean Startup, or the Product model. Again, here we come back to systems. It is not that easy to build something just by focusing on a small part of the system. Agility by itself doesn’t solve problems related to testing, reliability, scalability, or innovation… it only focuses on a small part that might or might not, work for your company: it’s mainly pre-delivery and delivery and we keep on making it the center of everything. If you just ignore all the things that go before this pre-delivery and what goes far beyond delivery then you will probably fail. And not because you were not really doing scrum but mostly because you were only doing scrum.
Then what
I was the first one to be critical of the whole Twitter layoff situation. It caused a wave in the tech world that mimicked the “shed baggage” originated by Elon Musk when he was skeptical about too many people “working on things”. A year after that and having read William Isaacson’s biography, I have to admit that there is a part of truth there. I didn’t know he was also, in one of his many personas, embracing the punk-rock mantra: question the system, do it yourself. This example covers part of what the agile community has been missing these years, but a small group tried to amend it in Agile 2: “Hey, all this time we have been selling you a silver bullet to solve all your problems but it turns out that unless the gun is held by a specific type of leader, there is nothing you can do about it” said no one, nowhere. But they, in fact, did say this:
- Someone usually needs to coordinate things and be the organizer.
- …a leader is someone who delegates and empowers, but keeps a watchful eye; someone who encourages their team to develop and improve and expand their abilities, and become more independent over time.
- Leadership is needed at every level of an organization, and the same principles apply.
- Leaders of tech-focused organizations not only need to understand outcomes, but they also need to understand how the work is done, because the “how” is often strategic.
The key omission in all the agile and scrum bibliography and narrative is Leadership. This connects with the parallel universe Marty Cagan is working on in his books: INSPIRED & EMPOWERED and the articles on SVPG. Transforming into the Product Operational model instead of acting as an IT department. Strong Leadership is the catalyst for innovation, delivery, and excellence in technological solutions. So, the problem is not about what framework should you use (what everyone seems to be focused on nowadays due to a lack of technical knowledge) but what framework should you create based on your knowledge of software development methodologies, lean startup principles, product operational model, your team individualities, and your customers. Don’t use agile or scrum, create your framework based on the three agility principles (analyze, plan & learn) and lead those experts who know how to design, build software, and test innovations. It doesn’t matter if you have a scrum master, if you do standup dailies, use Kanban, or just use post-its. The team, your team, is the key; not the framework on top of it, and no silver bullet will change that for any particular situation.
Final disclaimer
It’s fair to mention that the most significant progress in my career has been influenced by agile coaches and scrum masters who shared the knowledge of these frameworks and mental models with me. This article is critical of the global agile marketplace and the wrong practices I have been seeing during my career at different companies. However, a more humanistic approach to software development, besides technical discussions, is still a critical subject for the industry.
