How to bring down a Scrum team by doing agile

Years ago, I was a programmer. Although I was very poor at that time, I was never desperate for money, because I knew there would be many days without money in the future.

After years of hard work, I finally became a technical manager and bought a car. I also came to realize that people my age should wear a safety helmet when riding an electric bike; otherwise, students driving BMWs and Mercedes-Benzes might recognize that it is their teacher—aka me—riding it.

I still remember I tended to be posing and pretentious, acting like someone I was not when I first became a technical manager. I often used those “high-class” management methodologies. I used to spare no effort to promote Agile, constantly trying to convince the team, the leader, and the boss to adopt it. Who would I show off to if they didn't understand the benefits Agile could bring?

Later, I understood. If I act too pushy, God will punish me. Even if God is too lazy to do it, my boss will do it. Uh, don't ask how I know this.

When it comes to Agile, I have my own unique insights. I believe that as long as I work hard enough at it, there is no team that cannot be defeated by Agile. After going through all the failures, I can share the top problems when "doing Agile."

1. Don't believe in Agile

When it comes to Agile, the team is thinking, "A stupid leader messing around again!" or "Agile means fast! What 10 developers did before now has to be done by 5 developers! Everyone is going to be laid off." When the team thinks like this, you can be bold with your Agile implementation. Let employees push quickly without understanding Agile, and you've successfully planted a time bomb. As the saying goes, everything is difficult at the beginning, and because it remains difficult at the end, you gradually get used to it. Get a "good" start, and you're half done.

2. No Agile coach appointed

Programmers are a group of extremely smart people, and I am only slightly worse. I am just extremely smart. Since I am so smart, what Agile coach is needed? Do we want to train again to get taken advantage of? It's not that easy. A lot of truths are "unjustifiable," and Agile is one of them. Lessons still have to be learned, and earlier is better than later.

3. Disrespect the Scrum team

Remember, the Scrum team members are not people without feelings. However, it is necessary to introduce advanced management tools such as Agile and OKRs into the Scrum team in batches. This will surely cure all diseases and greatly enhance competitive effectiveness, regardless of the feelings of the team. Do you know why senior leaders are very friendly to developers, while grassroots leaders are very harsh on their subordinates? Let's put it this way: have you ever seen anyone get angry at their office supplies?

4. Do not tolerate mistakes

Everyone is a grown-up in the workplace. They talk about results. If they don't do well, they will be punished severely. How can you tolerate mistakes? If you make a mistake without being punished, why are so many Louis Vuitton purses made every year? (To buy as apologies!)

5. Avoid difficulties

Once Agile is implemented, the problems come. Can temporary stories be inserted? Do we still need to write documentation? Does the project need to be reviewed? When facing problems, you must first calm down. Don't worry if you can't solve the problem immediately, because you won't be able to solve it tomorrow either.

6. Treat changes as an experiment

Isn't being Agile just holding daily standup meetings and drawing on whiteboards? What's so strange? First, try to find a few Scrum teams; who knows if it will work? Doesn't Agile advocate "shoot first and aim later"? Let's run first. But the question is, maybe what you triggered was an atomic bomb? By disrupting the rhythm of the Scrum team and affecting the normal development of the business, you might just kill yourself.

7. Be too radical

Agile is very good. So many amazing companies have joined Agile, can we not just copy their homework? Change all projects to Agile mode, going from maturity level L0 today to maturity level L4 tomorrow. Expect only the unexpected; nothing is impossible. Remember two laws:

• Agile is perfect;
• If you have any problems, please refer to the first law. How can there be problems with Agile? It must be our problem.

8. Criticize and attack the Scrum team

Why did humans create languages? To spread gossip. All criticisms and suggestions must be said in private, never put on the table. The more mysterious, the better. What kind of boss’s sister-in-law’s brother-in-law is fighting with her sister’s sister again? Which developer secretly took a look at the QA girl in the crowd? The matter of old, rotten sesame seeds (ancient history) must be dissected into ninety-eight pieces. Doing this will make the Scrum team's atmosphere bleak and destroy the Scrum team's great cause in no time.

9. Intensify contradictions

The relationship between Product and Development is a constant game of shifting alliances. You two are a team this sprint, and the next sprint you become sworn enemies. Sometimes team members are like couples. When they first start dating, they wonder how they got so lucky; after getting married, they often wonder what terrible sins they committed to deserve this.

10. Lack of product planning

Since doing Agile, the product team has completely let themselves go. Development is Agile, and delivery capabilities have been unlocked, so why is product planning needed? The world's products can just be copied safely. Powerful product managers are all engaged in C2F—Copy to FAANG (Facebook, Amazon, Apple, Netflix, Google). Copy Apple first, then Google. If Amazon doesn't work, then just copy Meta. Remember, developers should never quarrel with product stories, because after arguing all morning, the stories have been fully understood, and you will have no time left to actually code.

11. Technical architecture out of control

With such fast-paced agility, how can there be time to engage in technical architecture? All temporary solutions are applied, patches are applied when problems occur, and patches are applied on top of the patches. When an incident occurs, it must be a product design problem, or it wasn't caught by the testers, or it may be an operations and maintenance problem. In short, programmers shouldn't put too much pressure on themselves and lose their hair over it. If it really doesn't work out, prepare to delete the database and run away.

12. Lack of tool support

Automatic build tools are nothing unusual, and the same is true for manual builds. Polish it manually; you must have the spirit of craftsmanship. Don’t buy Agile management tools. Microsoft Excel is good enough. Saving hundreds of thousands every year to give as bonuses to the brothers—isn’t that great? Automated testing is also a prodigal gadget. If the tests are automated, are all the cute QA girls going to be laid off? Be a decent human. You know, the beautiful QA girl is the reason I go to work every day. Otherwise, what is the difference between going to work and going to the grave?

13. Cultural gap

The team culture should go with the flow; don't bother with useless team-building. What's wrong with a lone-wolf programmer? A good programmer is worth 10 mediocre programmers. It doesn't have to be a group. What are team T-shirts, team slogans, and cultural walls? Just kill me.

Final Words

It is not difficult to use Agile to bring down a Scrum team. As long as half of the above 13 items are done, it is highly likely that the team will fall. As the saying goes, you don’t know how expensive things are if you are not in charge. There are some things you must keep trying; even if the car flips over, at least you have summed up the experience. There are no shortcuts to Agile implementation; it is all achieved step by step. After the wind and rain, you may not necessarily see a rainbow—you might just catch a bad cold.