The following is a rough draft for an agile book I have rumbling around in my head. I’m curious for feedback on the concept and would love if you could drop any thoughts in this Mastodon thread.

If I had to guess, you probably picked up this book because of a nagging feeling that your team or company is “doing agile wrong.”

Maybe you read the class Spotify article about how they have a whole team focused on just the Playlist widget and all they have to worry about is engagement with Playlists. They can be super agile and try all sorts of A/B experiments to improve playlists.

Or maybe you recently finished your first round of Scrum training and certifications, but despite the new meetings and process, you’re not getting more done “in half the time”.

Whatever the reason you’re feeling this, you probably have ideas why. “If only we’d stop doing X, we’d be more agile” or “That department doesn’t understand agile. They don’t get it.” If only everyone would get on board and do agile the right way, things would be so much better.

I’m here to burst your bubble. There’s no right way to be agile. I love the Agile Manifesto and the Department of Defense’s “Detecting Agile BS” guide. But even in both of those documents, I can point out things that may not work for every project and company. This doesn’t mean those teams are bad or can’t be agile.

It simply means that the incentives of the company don’t align with that flavor of agile.

As an example, let’s look at the very first principle of the Agile Manifesto.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

In one of my roles, I worked for a start-up whose primary customers were utility companies (electric, cable TV, natural gas, etc.) and the primary users were technicians who worked in the field. Under a union agreement for those technicians, they had a reasonable expectation to be trained on any new versions of the software they needed to do their job. That meant that any time we released a new version of our software, the customers had to provide new training classes and materials for their technicians (the users).

Obviously, this wouldn’t have been feasible if we were releasing multiple times per day, which is the “elite performers” goal of the DORA metric for “deployment frequency”. Additionally, because our customers incurred a cost each time we released, they wanted it to be less frequent than was even technically possible.

The incentives in this company didn’t align to this principle of the Agile Manifesto. The team could still be, and was, agile but had to do so in a way to satisfy their customers and incentives. In fact, they had to lean more on the “Individuals and interactions over processes and tools” part of the Agile Manifesto than the principles, so as to work with their customers to create a process that worked.

And that is the heart of this book. You shouldn’t worry about “doing agile wrong” when comparing yourself to other companies, past experiences, and the endless blog posts and LinkedIn articles you read. You should be worried about doing it wrong in a way that doesn’t align with what’s best for your company, team, customers, and users.