Once upon a time, I was part of that his team and way back about 5 years ago it was a reasonably agile group. Over time that group lost its Customer, and over time became less and less agile. Now, about the only practice used that could be considered agile is testing by the developers. It has never been said explicitly to me, but I believe that management thinks that agile "failed" this team, whereas from my perspective the team failed agile. When the going got tough, the team fell back on old behaviours, and I was the lone voice saying to stay the agile course. So, I eventually "changed my organization".
What caught my attention about my former colleague's comment was that these crunches are expected and normal. To me, however, they are indicative of poor management. Agile methods are no longer new - they have been proven time and again to be effective when the team actually follows the practices and doesn't cut corners when they feel some pressure.
In the case of my former colleague's team, I know their situation and what led to it. I warned them last October that this was going to happen, and it did. It's not because I'm clairvoyant or some Agile Coaching superstar but rather because, given all the indicators 9 months ago, the outcome was absolutely clear:
- Planning was performed mostly at the start of a release, and tracking during was lax at best because the features to be built were far too coarse-grained to be able to provide reasonable estimates for their construction.
- The team did not use iterations, so there were no checkpoints during construction to verify the team's progress.
- Interaction between the team and the Customer was sparse, often once every 3 weeks.
- The Customer very rarely saw the actual system during development - possibly a demo near the end of the development cycle - so there were few opportunities for them to steer the project to suit the business goals.
- Acceptance testing was performed solely by QA people with little involvement from the Customer (although there was some from the Business Analysts), and the acceptance testing was 100% manual. While this was feasible 5 years ago with the initial embryonic system, it is currently the single largest bottleneck for the team's progress.
- The code base has a very high level of technical debt. While the developers aren't at a standstill, they do still have to deal with unintended consequences of making changes. Fortunately, they have tests that cover about 40% of the code base which does give them something of a safety net.
- The developers don't stop production when unit tests are failing. On more than one occasion, releases were performed when "the bar was red" because it was felt that it would be too much work to update the tests to make them pass.
- Retrospectives are very rarely performed, and when they are very little is actually done based on the recommendations that come out of them. I wasn't the only one who made this observation - even some people who could be called the team's worst critics of Agile felt the same way and said so.
The truth is, though, they did know another way, but they abandoned it. If perhaps they had the guts to admit that the way the team used to work was better, then they wouldn't have these problems, and people could live normal lives.
Good management implements, inspects and adapts. Poor management scratches their head wondering why things are so tough, and says things like, "It's like this everywhere". Well, I'm here to tell you, it's NOT like that everywhere.