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

Fogg Behavior Model

Have you ever wondered why you do certain things? Why are some behaviors easy and joy to do while other not so? And your customers - have you ever struggled to understand their behavior?
BJ Fogg, from Stanford University, has created simple and powerful behavioral model for persuasive product design.


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.

7 steps of Product Discovery

Before building a product - how do you know what product to build? While building a product - how do you know what features are the most valuable? After you've built a product - how do you know if to tune stuff or add a new one?