TL; DR: Abusive Agile – Beyond the Cargo Cult
Here are some frighteningly abusive management practices, wrapped in an agile flag, that I have lived through.
Note by Stefan: This post is a guest post, and the author is using a pseudonym for apparent reasons.
Do you want to get this article in your inbox? You can sign up here and join 24k other subscribers.
Conway’s Law
I’m a seasoned lead software engineer. I have done projects (so far) within 29 companies both large and small. Over the years I’ve seen only one agile process. Below are a few things I have seen. Many are symptoms of what’s in the poll. A few are not.
Melvin Conway observed that our processes mirror our communication. I like to think the law is more generally applicable to the extent even that like psychologists we tend to build our interactions with the whole world, and structure it as much as we can, to mirror our internal communication (thought) processes.
Sadly, the mere act of implementing agile processes does not make my thoughts more agile, me any more compassionate, nor ordinarily my company’s communication better. That takes more work. (Implementing a process might have a chance at that last one if the additional work is done.)
Cannot see the form?
Please click here
When Bureaucrats Run a Project
The worst example by far was (inevitably) when I was one of the closers trying to fix Obamacare. (A “closer” is a term from baseball. That’s the pitcher a team sends in after the seventh-inning stretch to throw twenty fast balls and make sure no one gets on base.)
- Anyone who provided, at any time (including retrospectives) any negative feedback about the process, or operational suggestions, was quickly terminated. Every scrum team had scrum leaders, project managers, product managers, personnel managers, equipment managers, and “thought leaders.” At least one of those had some function that caused them collectively to act as a political commissar. Everyone watched their backs all the time. Squealing on others was considered good behavior.
- Every team was held responsible (in some way) to the current “thought leader.” We got a new thought leader about once every two months.
- Scrum teams and the people within them had no actual authority for anything, not schedule, not backlog, not communicating…, only how many “points” they would assign their stories. Welcome to the worker’s paradise. (As it is duly constituted by those who are better than you and thus know more and have more political clout.)
- QA and Dev had separate scrum teams.
- Scrum teams had 23 people. (And three managers too!)
- Contractors were second-class developers as compared to regular employees. (Here in our worker’s paradise, we like our caste system, thank you. Everyone brought in to fix the problem created by the regular workers was a temporary contractor.)
- Team cohesion was maintained and enforced even to the detriment of overall mission success. (In one case, side conferences were held in hushed voices speaking Tamil, thus preventing the new white guy from knowing what the plan was—leaving him to sink or swim with predictable results—and then telling the product owner and scrum leader that he couldn’t perform with predictable results.
- Of course, deliverables were defined by the US Dept. of Health and Welfare (D.C.) where words are weighed (by the ton) and not so much understood. This approach is probably the best single reason to use genuine agile. Priorities and deliverables changed with the wind, but the bureaucracy stood firm against that storm and ensured all the new information was properly queued long before engineers ever knew.
Self Delusion
The more common setup seems to be a company process that is simply chaotically out of control and managers are self-deluded. I’ve been in more projects like this than I can count. Here are some of the symptoms.
- Velocity is the only allowed measure of individual employee contribution. (Not team velocity — individual velocity.)
- Corporate management (chickens all the way) hijack scrum meetings about twice a week, and then pontificate for 45 minutes while the pigs rock from foot to foot, try to stay awake and wish for a chance to visit the water closet.
- Corporate trains end-users of the new system (often project managers), but denies any training to the engineers and developers charged with integrating the new system with existing enterprise software.
- Once I saw a company fire one of their engineers for telling their customer service team what the project’s current deliverables and expected schedule were.
- Another company had the CEO tell a team’s architect not only what to build (requirements) but exactly how to design and build it. (Down to providing disastrously non-functional pseudo-code.)
- No time is ever given for retrospectives, and if one happens over a beer then no action or adjustment is ever performed.
Conclusion
All of these abusive agile symptoms are of some suboptimization caused by “tyranny of the ego.” Someone with institutional power wields it in a way that makes her/him feel more powerful, even though it’s detrimental to their larger cause. Their outer non-agile process mirrors their own internal dysfunction.
How we think, what we believe, and why we think that, can often be more damaging to any process than mere lack of understanding.
Related Posts
Agile Failure Patterns In Organizations
Cargo Cult Agile: The ‘State Of Agile’ Checklist For Your Organization
Download the ’Scrum Anti-Patterns Guide’ for Free
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
