Sure. It is often due to dysfunction, but it can even happen to good teams. Imagine you have to fix a simple bug, like the description of an option in an HTML

Sure. It is often due to dysfunction, but it can even happen to good teams. Imagine you have to fix a simple bug, like the description of an option in an HTML page. Imagine that: the codebase is a bajillion lines of Java or C++ that no one person truly understands any more. Imagine that: fucking up is considered bad. Maybe you're protecting important user data, or maybe it's just code for the online store, and even an hour of downtime can wipe out the day's profits. The team is so big that your feature is scheduled for deployment along with four or five others this week. As usual, management has skimped on QA so there are not enough of them to go around. Also, QA was added late, so there's no fast automated test suite. It takes them a full week of manual and semi-automatic testing to go through all regressions. After that week of testing in development is over, then it goes to staging, where it's tested with real live data and staging subsystems. At least somewhere in this, something breaks (something is always breaking) and a fix is produced. Then the new build is tested all over again, with the basic smoke tests as well as any test suites that are applicable to that unit of code which broke. This is causing another trainwreck because we promised feature X to client Y by end of the month. What do we do? Emergency team meeting! Let's rebalance the work schedule. Meanwhile, your change, which just a simple HTML fix, languishes as this build goes into its second round of testing. Oh, and did we mention that you have to have submitted your code in time for translation into six languages? I'm afraid that the French translator did not produce a satisfactory translation in time, so we're going to have to hold your change back. Can you revert this and put it in next week's build? Thanks.