Whenever a transformation is undergoing, it’s almost impossible not hear people blatantly promoting (and asking to use) so called “best practices”. Especially in the consulting industry, people tend to collect them, implement them, and feel proud when putting those words together on a presentation deck. But what if I told you that blindly following ANY best practices most likely won't result in what you expect?
The Trap
A few years back, I was brought to work with a struggling product team at a relatively size corporate (less than 1000 people). The first thing I noticed? They had implemented every Agile "best practice" in the guide book. Daily standups that ran like factory operations. Sprint planning sessions with precise story point estimates. Retrospectives with action items neatly documented. Burndown charts and committed vs completed ratios that would make Scrum Masters cry of joy of such flawless perfection.
On the surface, they were doing everything "right." In reality, it was a completely different story.
When Best Became Worst
The daily standups had become status reports, with people giving updates no one needed or cared to hear. Sprint planning consumed entire afternoons debating whether a story was a 5 or an 8, while real customer problems kept unaddressed. Retrospectives generated the same action items sprint after sprint (e.g: get better at communication), with no real change.
They were following every best practice religiously, but they lost sight of why those practices existed in the first place. It was clear that whoever setup them in place, it was optimizing for process compliance, not customer neither business value.
In my walk the floor conversations I heard many variations of the following: "I feel we spend more time talking about the work and how we will do it rather than actually doing it."
Best practices are set when we have a specific context, determined constraints, and an existing culture. What worked great for a small startup might be unattainable for a team in the average corporate. What solved problems in tech-focus companies might create new ones in your less tech aware companies.
And that’s why 90% of the clients I worked asked for “best practices” as most people treat them like universal truths. Copying frameworks without understanding the problems and context in which they were used (e.g: “Spotify model”).
Now back to that product team; it was a great opportunity to question everything as a new head of product was recently on boarded and that’s exactly what we tried:
Daily standups: Cut to 5 minutes, only blockers and coordination needs. Regular updates were done async in the development team group chat.
Story points: Replaced with simple t-shirt sizing, focused more on uncertainty than trying to capture accurate effort.
Sprint planning: simply trying to answer a single question: what customer problem are we solving this sprint?
Retrospectives: Facilitated conversations to move away from "what went wrong" to "what did we learn about the issue and how we can prevent from happening again?"
Within weeks, communication perceptually changed. You could feel the energy returned in the team meetings and we spent more time discussing customer problems rather than ways of working.
The Real Best Practice
The only real best practice is: understand the problem before you adopt the solution.
Every framework, system, approach, technique exists to solve a specific problem. If you don't have that problem, you don't need that solution. And if you have a different problem, you might need a different solution altogether.
When you stop being a slave to best practices, you start becoming a craftsperson. You pick up tools because they solve your problems, not because everyone else is using them.
