Why I'm not an Agile Coach anymore

You know who cares about being really, really Agile? Agilists. You know who doesn’t? Customers, stakeholders, shareholders, CIOs, CTOs, pretty much anyone who’s not selling Agile or is on a Scrum Team – and they only care about it because Agile Coaches tell them they should.

Agile is now old enough to drink. Over the last few decades, it’s grown from a set of values and principles that guide good decision making into a bastardized amalgamation of cult practices, playbooks, ideologies, and frameworks. Agilists are now in the business of arguing over “my Agile is better than your Agile”, and success is defined by checking enough boxes to get the Agile priest’s blessing as opposed to delivering value. There are now people coaching delivery teams who have never been a member of a delivery team before; people whose entire careers have been divorced from building real things.

Is DevOps an Agile thing? Is Agile a DevOps thing? Who gives a crap? They’re both good, they’re both good things. Is a hot dog a sandwich? Why do we get so wrapped around the axle of whether Human Centered Design is “agile” or its own thing? At the end of the day it’s all part of your delivery strategy - or should it be? In the age of burgeoning AI, is arguing about Story Points or T-Shirt sizes the right conversation to be having? This echo chamber has become very comfortable for agile coaches to hang out in and gracefully argue academics or just violently agree with each other non-stop. Look at the reaction options you have for LinkedIn posts. “Celebrate”, “Support”, “Insightful” – these are just means for digital virtue signaling. They don’t spark debate or growth.

Let me be clear: I still believe the Agile Manifesto is valid. I’ve found those values and principles to be applicable anywhere humans need to work together on a shared outcome, not even limited to software development. Some of my favorite people are Agile Coaches. But you know who doesn’t want to deal with all of them? Technologists who need help. They can’t stand this community and I can’t blame them. They’re coming to us with real problems affecting their business’s ability to survive and this community has completely divorced itself and its beliefs from P&L.

It breaks my heart to say I was a part of organization that was totally focused on getting “Agile AF” - making our developers lives cooler, funner, hipper, and more modern – and we completely failed at making the business more profitable (or more agile). We judged ourselves by things like our Clean Language and our Psychological Safety, and were winning by all those metrics. And then executives asked us for the ROI of our department and its efforts. ?And then we all got fired. If your business isn’t profitable, it doesn’t matter how many ping pong tables you have or what your dress code states.

All the easy Agile Transformations are done. Companies with the culture and workload that easily aligned to agile practices started adopting them with little friction twenty years ago. I haven’t seen one of those in the last three years. Most companies aren’t pure software development shops, they’re hospitals, banks, insurers, or electricity providers. Their problems show up differently from software development problems. We can’t afford to show up with “The Manifesto for Agile Software Development” and not expect to get laughed out of the room.

We’ve got to get better. We’ve got to move past the ego of puritanical Agile for Agile’s sake. There’s plenty of good practices there that we can still use every day but we have to focus on holistic production of value. Belts are tightening, capital is shrinking, and we need to have an actual ROI to what we’re recommending. The only way to prove this is with tangible and measurable delivery improvements. That’s going to look different in every organization because, believe it or not, everyone actually is a snowflake. They may have common signals or similar problem sets but no two companies, let alone individuals, need the exact same solution. That’s what we’re doing at Sketch. We’re taking the understanding of practices from all the disciplines needed to deliver – Product Management, Design Thinking, Scrum, SAFe (jk lol), Change and Risk Management, etc. – and pairing that with the wisdom to know which to use and when.