Skip to main content

If you try things and they work - it's agile


Moreover, if things didn't work but you try something else - it's also agile. In general, it's quite hard to not be agile if you try things and see if they work. Continuously.


I recently heard an Agile coach speak. Usually, it's an eye-rolling experience, but this time it was different. Matt LeMay was refreshingly honest. He admitted that most "Agile coaches" just re-packaging waterfall to jump on the bandwagon of various "transformations".

Product teams that adopt Agile often become fanatic about a particular implementation. They say:
- Daily scrum should be like that!
- That's not the way you run a retro!
- User story doesn't follow the format so we will not even read it!
- We delivered that many points this sprint, but we will not ship product to production!
and so on and on.

Such an approach contradicts the spirit of Agile movement. Something that was created as a set of principals - turned into multipage manuals prescribing every little detail.

I guess some people will be surprised to learn that original Agile manifesto said nothing about daily scrums, length of sprints, user story format, acceptance criteria, retrospectives... Nothing like that was mentioned. It was a vision of a group of experienced engineers on how to work better.
- We tried that way vs the other way and it worked better for us, - that's the essence of Agile manifesto.

One could say there was only one, cornerstone principle of Agile - continuous learning. While you try things and learn from results - you're being agile.

Why does this matter?

People treat Agile as a project to complete

They invite consultants, hire a bunch of scrum masters, set deadlines and eventually announce "successful" Agile transformations. Usually, it coincides with the decision to cut financing. Also usually, people regress back to the old ways of working quickly after consultants are out of the doors. Treating Agile as a project one can complete is neglecting its biggest value.

People hide behind the process

They report their velocity. Show beautiful, estimated backlogs. Do all scrum meetings, including reviews where they show a presentation about the latest sprint outcomes. All might look good on sticky notes, but on production, the software is still underperforms. Not shipping working software regularly is not making progress, merely hiding behind the process.

People do Agile to be agile. And fail

They hear those countless voices telling them how to do a "proper" Agile. So they try everything in the book but it doesn't work for them. But it has to work! Everyone says it has to work. So they continue to enforce the book. Pursuing mindlessly Agile people walk past its main value: being agile - trying things and learning from them.

Sometimes the name brings toxicity. It brings all the past emotional baggage. All the failures and illusions. No one needs that. If you've found ways that work for you - great, you're a star! Don't say you do Agile, just be agile in your own way.

Popular posts from this blog

Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions. But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

3 steps to build a customer journey map

A customer journey map is a visual tool that shows how satisfied your customers are on every step of using your product. By a quick glance at the map, you can immediately see where you're doing fine and satisfying your customers and where you're failing.

First things to fix on a Customer Journey

Customer experience is the cornerstone of your product success. Customer Journey Map could help you to measure customer experience. Which parts of a customer journey are the most important? Where should you pay the most attention?