"Agile", you are not good enough anymore
"Agile", you are not good enough anymore
We always cared about the customers, that was never the problem
What the “agile mindset” solved for us was the problem of creating products with big teams. We solved that problem well compared to the past.
But AI / Machine Learning and better available learning accelerated an existing trend: We don't have a problem anymore of not having products for our problems.
We have too many. The existence of a product is not a differentiator anymore
Our tools became so incredibly good at reaching everyone with products we created quickly that there is now a new enemy: Choice.
And in order to battle choice you need to stand out, except…
Customers don't know whom to trust anymore. Everyone says they have the best, and convincingly so. It is an absolute bloodbath that everyone tries to solve in sales and marketing by convincing people somehow better.
Users turn to the only trust we have left as a reaction:
Other people who have no incentive of deceiving us -> Word of Mouth
Trying something before buying it -> Trials, freemiums
Building custom solutions ourselves
Limiting liability on contracts (monthly vs. multi-year contracts)
Creating visibility into our tooling and cutting off things that don't work
This is a reality that swoops up from B2C markets into B2B and ultimately enterprise whether you accept that or not.
You can have the perfect sprint and achieve still nothing
And this in turn means being agile - building fast and being organized - is not enough anymore. You could have the perfect sprint and achieve nothing.
In the past, you had to be fast because there were so many valuable destinations to reach
Today, discovering the right direction is the key. Whether you get there 20% faster than a competitor is just nice to have
Being customer-centric is not a buzzword anymore. It means, only if you have a lasting impact on your customer's success you can persist.
Agile may not be entirely dead but if anything it became a small cog in the machine. In the past, it was the machine. No scaled agile framework will ever change that.
Speed without direction is wasted energy. And you can't guess the direction anymore from the top.
Only your customer knows it.
The problem with the intent of “being agile” and the outcome of it
To clarify, there is nothing wrong with the intent of being agile.
We never tried to actively create products that are not good.
Waterfall was invented to deal with the absolute chaos that no organization at all brought.
Agile was invented to deal with the weaknesses of waterfall projects to be closer to the customer and create software faster and more iteratively
Product-led principles like intently measuring customer success are now necessary to bring it over the finish line because agile processes have a fundamental flaw
The illusion of iterative feedback being enough
Asking the customer what they think is not a specific enough method to create good products after you shipped something. The goal is not to ship. The goal is to test a hypothesis around the measurable impact on customer success and then make a decision, we went from:
Output driven: We deliver feature X
toOutcome driven: We increase revenue
toOutcome success driven: We increase engagement from x to x
And the latest iteration does NOT work if you don't define first the correlative connection between how much your product is used (engagement) and what impact that has on value capture metrics like revenue etc.
Because if you do that consistently it means that you might have a perfect product as per requirements, great code, and great quality but it does nothing as the tests show, therefore it doesn't get shipped.
"But what if has an impact on revenue? Isn't that proof?"
No, it's not - you can pump revenue with really bad habits that don't help your customer. You could make it harder or impossible for people to unsubscribe and artificially push short-term revenue. Goal reached? No, not really.
Your product might become worse with more features but you need to have a check in your system to notice.
And that's measuring customer success. Agile doesn't deal with it. It has the INTENT, for sure, we all want to create great products. And the reason why it goes wrong so many times is that people "misunderstand" it constantly. But when is that the problem of the framework?
The reality is that companies use “Agile” as a buzzword to the extent that it lost all meaning. And frameworks, mindsets, and processes that don’t have meaning are ultimately paper tigers.
“You don’t understand Agile!”
My not understanding has nothing to do with it. The problem is what people commonly understand under the term. And it’s evident that if you have 5 “agile coaches” in a room you have 5 different opinions on what that actually means. For some, it’s a framework. For some a collection of processes, or a mindset!
Imagine “being agile” was a product:
You cannot blame your users to be stupid that they don't understand your interface, at some point you have to admit that the problem is the interface.
And in this case, “Agile” has lost all meaning. You can interpret anything into it.
Processes alone won’t save you
The gold standard is to use some ceremonies (personally a fan of standups and retros), reduce processes and give teams autonomy as long as they create a meaningful impact. → They need to be measurable otherwise it becomes a conviction circus
Whatever works.
Yes, we can use some agile processes and lament over the “mindset”. I even use some waterfall processes. But none of them address the fundamental problem:
You can execute agile processes perfectly by the book and still have a product that sucks. Don’t think that being agile is going to give you answers, because not even internally you will have agreement on what it means.
The goal is not to ship something into production. The goal is to build something that allows us to test our hypothesis. The best way forward may be to not ship anything at all.
“I didn’t mean to drive over you with my car!”
It’s little consolation to someone in a traffic accident that you exit the car and tell them that you didn’t mean to drive over them. The most important thing is to get them into the hospital and analyze what lead to the accident so we can prevent further mistakes.
Intent becomes secondary. That’s why we have traffic rules and safety measures. We analyze constantly how our “users” are using their cars and roads and then we adjust the signaling.
We don’t place people on the side of the road that constantly scream “Well! You just don’t know how to drive! That’s now how the car was designed for!”
We adopt our cars and organizations based on the outcomes that they have. Anything else is arrogant lunacy:
A great product is one that delights users, not one that had 50 burnup points in the latest sprint retro.
Don't be married to processes just because that's what you learned.
Read more here on how to build organizations that scale:
C. Good post and I very much agree. The only thing that struck me was your comment “Today, discovering the right direction is the key. Whether you get there 20% faster than a competitor is just nice to have”. I think this has always been true. Moving quickly & aligned using agile and building the wrong thing for the wrong person was never rewarded or a successful outcome. The best companies get this right and to your point, this is very hard. Agile is not enough and it is a tool that brings cross functional teams together to execute well but the right direction will always be more important.
"You can have the perfect sprint and achieve still nothing" - I've been on teams where this was the case 1/4 of the time. We never would actually fix it though. Just kept moving along like everything was fine. Oof.