Recipe for chaos in an XP team

Our team failed! We failed in delivering value to the client, value to our users as well as we failed in showing the benefits of XP - eXtreme Programming to not only other teams but our managers as well.
So here I am listing some of the factors which I think lead to the fall of the project, the practices and eventually the team itself.
We were quite fine an year ago. We used to pair, practice TDD, interview users frequently and release awesome features to production almost weekly.
I would not go to the extent of saying we were living in perfect times, since we faced some very common problems -

• Some people felt that TDD made them slow.
• Management kept questioning whether pair programming is really "fast enough" and not slowing us down. This gave birth to some "Duct Tape Programmers" in the team. (That's a real term! Google it.) "The Duct Tape Programmer is someone who is able to cobble together software that solves the immediate problem, but without any concern for the code’s quality or maintainability. Most importantly, management adores them."
• Some developers who were accustomed to work in old ways took a little longer to learn these ways which often caused friction among the developers while pairing.

But all these issues seemed quite trivial or not lethal.
So what went wrong?
Here is the ingredient list to get chaos in any team (works better in a high performing XP team):

• 100 gm of interference from management
• A dev lead who is not given much value by the management
• Odd number of people distributed in different time zones who are supposed to "pair"
• Handful of devs who reject any new way of working - without even trying
• A tbsp of "scrum" processes mixed with "XP" processes.
• Tight deadlines for the development team - to taste!

Let's start with getting the chaos ready:

• Management stopped believing that XP practices (which for them is only Pair programming and TDD) works. Developers started to get a feeling that all these practices are optional and can be carried out as per their convenience. When other devs called it out, the answer which they received from management was "you guys need to decide yourself" and "which ever way is quicker". This caused friction among the devs - those who knew that cherry picking of such practices does not work and those who didn't. (Will have to write a separate post to explain just this point)
• Now comes the dev lead. The guy who supposedly is also required to direct everyone in the team on the practices or find a common ground. But sadly, management decided to play democracy here and the lead could not direct until they have a majority. You would be surprised to know, still the XP guys were in majority - so we continued.
• Now let's use the oldest trick to win any battle - divide and conquer. The team was split into two. 2 devs in one team and 5 in another! Not only this, let's add an year long of work in the backlog for those 2 people and let the other bigger team work on POC in discovery phase. What an idea sir ji!
• Let's introduce another ingredient - "Scrum"! Now people may ask what's wrong with scrum, nothing sir! It's just it is a concept in itself which (if not managed correctly) does not go well with some of the existing XP processes we used to follow. For instance, earlier we did not require a sprint to be started/ended to pick a story. We just worked on whatever feature is on the top of the backlog and keep refining the next set of stories weekly. We never limited or overfilled our current set of work with extra stories than what we were working on, but now we need to perform those extra "ceremonies" and decide/estimate which stories can we pick up-front. (I don't know about you but I smell waterfall somewhere)
• Product owner loves only one thing more than on time delivery, "duct tape programmers" who make on/before time deliveries. The product owner starts giving some side jobs to his "second in commands" and this created further silos of work. If you did not see it yet, cherry picking of processes has started. People can choose to pair on some of the tasks and not to on some of the others. This does away with one of the most important part of pairing - context sharing.
• Let's get the handful of devs we talked about in ingredients. They are the ones who along with the duct tape programmers will take care of TDD stuff. The secret is writing tests after the code has been completed. Because as per them "no-body can figure out from the tests if they were written before or after the implementation". SMH. (Even if all they wrote were negative tests, which will pass even if we delete the whole source folder!)
• Let's heat things up a little now. Let's announce a tight deadline for a new feature which is still being planned. The stories still need to be created, we are just waiting for the architecture and design requirements. Even if it means developers will get hardly 3 weeks to complete development for an epic with 2 months load of work!
• Now its time to put the mixture to actual cooking. Management decides to shift the whole team to offshore - stating importance of co-located teams. Even if it means letting go of 3 experienced developers of the team and hiring 7 new developers at the same time, specially when on-boarding a new developer takes roughly 4 weeks! This will crash the team's morale and kill the enthusiasm of the developers who are going to move out just because of their locations. Which will end with developers not giving their full (or even half in some cases) for the remaining of the project's interest.

Perfect! We are now ready with the chaos in the team. Garnish it with a few resignations and serve hot!
Bon Appétit!