Let me be clear - I don't believe in waterfall or old school ways of product development. Rapid iteration and shipping are absolutely critical to modern software development. If you're not releasing new things or iterating on your key product flow, you are probably dying.

However, what I object to is the notion that any system should be adhered to 100%. Having worked at many large and small organizations (Booking.com, Naspers, Intuit, IMVU), I've encountered far too many situations where the solution to a poorly functioning team is to "bring in an agile coach" or to "add better process." Most of the time, all this does is make things worse.

Sorry agile coaches. I don't find your job very valuable. I don't think sticking 100% to a regimen of agile, kanban, scrum or any of the methodologies actually solves the problem. The best teams I've ever run used elements of all the different schools of thought, finding the elements that work for them and discarding the elements that were useless.

This is why at most companies I join, I try not to impose a strict system on any of the teams. The best teams I've found generally have a few things in common:

Teams create their process as a team rather than having it imposed on them from above. Most great teams understand the expectations and business impact they are expected to deliver. They sign up to drive a key metric or a key element for the business. And the contract they create with the leadership team is that as long as there's alignment on the goal, the team should be free to self organize to make it happen.

Great teams create the process and system that's best suited for the team. I've seen incredibly effective teams at the same company use fairly different processes. One team could be doing sprints while another could be doing some form of Kanban. Some great teams mix multiple different methodologies together to create something that truly works for them. Great teams are formed through camaraderie, a shared sense of responsibility, and clear accountability. If a team wants to mix methods to accomplish this, if they are performing, imposing something on them tops down does not usually make things better, and often just serves to slow them down.

A great example happened at IMVU. My teams were high performing and successfully leveraging a days estimation model for our sprint planning. Was it perfect? No. But we consistently were outperforming our expectations despite not having entirely accurate timeframes for everything (which is normal in my experience). At some point, the company decided to implement a points system across the company using Planning Poker. Immediately, planning meetings went from 1-2 hours to all day for at least the next 2-3 months while the team tried to figure out what the difference was between a 5, 8, and a 13 (and I'm still not clear what it all means). The planning poker exercise was not wrong - some teams at the company were really not good at estimating and needed a process change. But the issue here was that it was imposed on all teams rather than a sought after solution. All it did for my teams was lead to an outcome where the teams actually had productivity hurt for a number of sprints without a tangible return in the long run. The lesson here - think about imposition of planning and other exercises, especially for your best, highest functioning teams. (I'm still not clear how planning poker works all these years later, honestly).

The point of all of this is to say if you have great people, give them clear goals, and enable them to self-organize with clear expectations, oftentimes they will do a better job of it than if you try to impose process on them from above. Usually it feels productive to give a team a coach or some form of consulting, but I've rarely seen the team that improved anything other than vanity metrics with this approach. The team will feel more productive with some new, pretty process, but rarely does the output of the team actually increase in a meaningful way that delivers for the business or for customers.

Teams themselves have to do the hard work of fixing their own problems. A coach can help them to uncover and solve the deeper problems in that context. But applying a blueprint (which I've sadly seen is the preferred approach in many instances) usually doesn't work because it doesn't solve the unique challenges of each team. Every team is unique, needs to have a thoughtful and reasoned approach, and the team needs to be bought in to wanting to solve the problems. That starts with clear goals, clear leadership, and expectations. If those things aren't present, the best and most expensive coaching in the world won't solve problems.

Barron Ernst's Blog

Don't Impose Agile (Or any other development…