How to bring down a Scrum team by doing agile

2021-04-30 15:30:47
Mr. K.
Original 90
Summary : 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 possible that the team will fall.


How bring down a Scrum team by doing agile

Years ago, I was a programmer. Although I was very poor at that time, I have never been desperate for money, because I know that there will 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 know that people at my age shoule/must wear a safety helmet when riding an electric bike, otherwise, students driving a BMW and Mercedes-Benz might know it is their teacher, aka me, riding it.


I still remember I tended to be posing and pretentious and acted like what I was not when I first became a technical manage. I often used those “high class” management methodology.


I used to spare no effort to promote agile, and constantly tried to convince the team, the leader, and the boss to do it. Who would I pretend to show it off, if they don't understand how agile it could bring?

Later, I understood. If I pretend to be pushy, God will punish me. Even if the God is too lazy to do it, my boss will do it. Uh, don't ask how I knew it.

When it comes to agile, I have my own unique insights. I believe that as long as I work hard, there is no team that can't be defeated by agile.


After going through all the failures, I can share problems about doing agile.

1. Don't believe in agile

When it comes to agile, the team are thinking, "A stupid leader messing around again!" "Agility is fast! What 10 developers did before is now have to be done by 5 developers! Everyone is going to be laid off."


When the team think like this, you can be bold and agile. Let employees push quickly without understanding agile, and now you plant a time bomb.


As the saying goes, everything is difficult at the beginning, and because of the difficulties 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, while I am a little bit worse. I am just extremely smart. Since I am so smart, what agile coach is needed? Want to train again to take advantages? It's not that easy.


A lot of truths are "unjustifiable", and Agile is. Lessons still have to be learned, and earlier is better than late.

3. Disrespect the Scrum team

Remember, the Scrum teamare not people with no feelings. It is necessary to introduce advanced management tools such as Agile and OKR into the Scrum team in batches, which will surely cure the disease and greatly enhance the competition effectiveness, regardless of the feelings of the team.


Do you know why the senior leaders are very friendly to the developers, while the grassroots leaders are very harsh on his subordinates?


Let's put it this way, have you ever seen anyone angry with their office supplies?

4. Do not tolerate mistakes

Everyone is a growup in the workplace. They talk about the 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 so many Luise Vuitton purses are made every year?

5. Avoid difficulties

Once agile is implemented, the problem comes. Can temporary requirements be inserted? Do you want to write the document? 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.

6. Take changes as experiment

Isn't being agile just holding daily standup meetings and drawing 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? Disrupting the rhythm of the Scrum team and affecting the normal development of the business, you might kill yourself.

7. Too radical

Agile is very good. So many amazing companies have joined Agile, can we not copy homework?


All projects are changed to agile mode, with maturity level L0 today and maturity level L4 tomorrow. Only unexpected, nothing impossible.


Remember two laws:


  • Agile is perfect;
  • If you have any problem, please refer to the first.


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’ sister-in-law’s brother-in-law is fighting with her sister’s sister again? Which development brother secretly took a look at the test girl in the crowd...The matter of Chen Guzi’s rotten sesame seeds must be divided into ninety-eight.


It's just around the corner to make the Scrum team atmosphere bleak and destroy the Scrum team's great cause.

9. Intensification of contradictions

The relationship between product and development is like Doudizhu, a Chinese poker game. You two are a team, and next round you two become enemies.


Sometimes the team members are like couples. When they are in love, they often lament what virtue they have accumulated in their previous lives; after getting married, couples often wonder what evil they have done in their previous lives.

10. Lack of product planning

Since doing agile, the product has completely released itself. Development is agile, and capabilities have been released, so why product planning is needed?


The world's products can be copied and safe. Powerful product managers are all engaged in C2B----Copy to BAT.


Copy Ali first, then Tencent, Du Niang will not work, then copy Pinduoduo.


Remember, developers should never quarrel with the product requirements, because after arguing all morning, requirements have been fully understood. You do not have time to code then.

11. Technical architecture out of control

With such a 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 is not tested by the test, it may be an operation and maintenance problem...


In short, programmers don't put too much pressure on themselves and cause losing their hair. It really doesn't work, prepare to delete the library and run away.

12. Lack of tool support

Automatic construction tools are nothing unusual, and the same is true for manual construction. Polish it, and you must have the spirit of craftsmanship.


Don’t buy agile management tools. Microsoft Excel is good. It costs hundreds of thousands every year to save bonuses to brothers. Isn’t it fragrant?


Automated testing is also a prodigal gadget. The tests are automated, so are so many cute test girls going to be laid off? Be yourself. You know, the beautiful test 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 rectify the useless team building. What's wrong with a lone wolf programmer? A good programmer can top 10 mediocre programmers. It doesn't have to be a group.


What is the team t-shirt, team slogan, and cultural wall? 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 possible that the team will fall.


As the saying goes, you don’t know how expensive you are if you are not in charge. There are some things to keep trying, even if the car is overturned, at least the experience is summed up.


There are no shortcuts to agile implementation, which is all made step by step. After wind and rain, you may not necessarily see the rainbow, and you may catch a bad cold.


See also


Write a Comment
Comment will be posted after it is reviewed.