A counter example that I often see is when a development team (or perhaps their managers, or both) use Agile as an excuse to deliver less than what the customer expects, and convinces the customer (against their will) that we need to deliver more frequently in order to be more Agile. While I certainly agree that frequent delivery is very important to an Agile team, it's much more important to me that as an Agile team we give our customer's the dial that let's them decide whether rapid delivery or more features is more important. I also think it's important for everyone to regularly get together and negotiate where the dial ought to be, but that the arguments made towards where to move the dial are grounded in what is going to maximize the amount of value (whether economic, knowledge or otherwise) will be delivered. There's certainly a lot of different contexts involved here, and it really depends on where a particular product is within it's lifecycle. If it's much earlier, and you have a smaller audience, then you can get away with a lot more trimming. As the product evolves, so do expectations of what it takes to deliver.
Instead I tend to see people use "we're Agile now so we need to deliver fast and small" as the argument regardless of context. Unfortunately, I've seen this lead to customers being unsatisfied, and turning their frustration towards Agile development, rather than the people who abuse it.
To me, the most interesting question is why this sort of thing happens. I have two theories...
My first theory is that this is grounded in short-term thinking, and if you were to trace back to root cause most likely comes back to a poor strategy for trying to get ahead in the infinite game of "Corporate Survival." More specifically, these are people who banking on maximizing output rather than outcome, and try to capture as much credit as they can based on quantity and not quality. I'd like to think that there is a karma component to this game that eventually compensates for these types of moves. Maybe that's just wishful thinking on my part. :)
The second theory is based on more innocent examples that I've seen, where I think that the root cause comes from insufficient trust and lack of safety. I've seen a tendency for people to get too consumed by doing what is expected by their role or job description and expect others to do the same. It becomes taboo for someone to ask someone in a different role to do something that they don't expect is part of the other person's role. Conversely, it's also taboo to do anything for someone that isn't defined by their role. Unfortunately this leaves a lot of gaps on the conversations that need to happen between people in order to deliver a successful outcome. Eventually people make decisions by default when they don't feel safe enough to ask the right questions. I feel that good leaders are able to spot when this is going to happen and break down impediments that come from this type of thinking.
Finally, I think delivering fast is important, just not at breakneck speed. Delivering fast, and guaranteeing customer satisfaction allows people to delay decisions to the point where one has the best information for making a decision. It's a formula that has worked well in many industries (not just software development). But if what you are doing is making you sacrifice one for the other, then perhaps you might want to take a step back and see if you have other options. But after exploring all my options, if I had to decide between customer satisfaction and instant gratification, I'd definitely choose customer satisfaction. How about you?
