13 Ways Agile Can Undermine a Team – A Candid Reflection
The author, a former programmer turned tech manager, humorously lists thirteen counter‑productive practices—ranging from fake agile enthusiasm and lack of coaching to cultural neglect and tool misuse—that can sabotage a development team when agile is applied without genuine understanding or respect.
Many years ago the author was a poor programmer who never despaired because he believed future hardship was inevitable; after years of effort he became a tech manager and bought a car.
He realized that at his age, riding an electric bike without a helmet makes him look foolish compared to colleagues driving BMWs or Mercedes.
When he first became a manager he could not stop flaunting lofty management theories, constantly preaching agile to the team, leaders, and bosses, more to show off than to help.
He later learned that if you keep showing off without admitting it, you’ll be punished by the thunder of consequences or by the boss.
He claims that any team can be broken by implementing just half of the following thirteen points.
1. Not believing in agile – Employees think “the boss is being stupid again” and fear losing jobs when agile promises faster delivery.
2. Not assigning an agile coach – Brilliant programmers don’t need a coach; training is seen as a way to harvest their talent.
3. Disrespecting team members – Team members are treated as tools; advanced management methods are imposed without caring about feelings.
4. Intolerating mistakes – Results matter; any error is heavily penalized, likened to luxury brand pricing.
5. Avoiding difficulties – When agile is introduced, questions about ad‑hoc requests, documentation, and reviews arise, but the advice is to stay calm and postpone solutions.
6. Treating change as an experiment – Agile is reduced to meetings and whiteboards, trialed on a few teams without assessing impact.
7. Being overly aggressive – Blindly adopting agile, believing it’s perfect, and blaming any problem on the team’s inadequacy.
8. Criticizing and attacking the team – All feedback should be given privately; public criticism is avoided to keep the atmosphere toxic.
9. Exacerbating conflicts – Product and development relationships are compared to a card game or a volatile romance, warning against arguing over requirements.
10. Lacking product planning – After adopting agile, product direction is abandoned, and copying big tech’s strategies is encouraged.
11. Losing control of technical architecture – Fast‑paced agile leaves no time for architecture; temporary fixes become patches on patches, and blame is shifted to others.
12. Missing tool support – Automated build tools are dismissed; Excel is praised as a cheap agile management tool, and automation is mocked.
13. Cultural divide – Team culture is left to “natural” development; lone‑wolf programmers are glorified, and team‑building activities are scorned.
In conclusion, implementing any half of these practices can easily collapse a team, but the author suggests that even failed experiments provide valuable experience.
DevOps
Share premium content and events on trends, applications, and practices in development efficiency, AI and related technologies. The IDCF International DevOps Coach Federation trains end‑to‑end development‑efficiency talent, linking high‑performance organizations and individuals to achieve excellence.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.