22 June 2008

Crunch == Poor Management

I was conversing via e-mail with an old colleague of mine about getting together for lunch sometime this coming week. He responded, "We've got a bit of a crunch on, so we may need to delay for a week or so".

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.
So, it's actually quite easy to understand why the team is in a crunch mode right now. There was a point a little while back where management declared that no one could take vacation over a space of a couple of weeks surrounding a release. While that may not sound like much, the mindset that went into that decision is telling. They are living in fear and don't know how to work any other way.

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.

2 comments:

Anonymous said...

Thanks for this great post. I'm on a team whose management firmly believes that crunches are necessary. I've spearheaded the use of "real agile" on my team (current managers pretend it's "agile", but it's not) from the 'bottom up'. I told them that all a crunch means to me is that you, as a manager, promised too much to our clients and were not clear to the rest of the team about real deadlines. I recommended that to avoid crunches, we should promise less, more regularly, and shoot to over-deliver.

You're right that crunches are 'manufactured' by poor management; usually, the problem with the manager is that he doesn't know how to negotiate deadlines or how to say 'no' or 'this must wait till next week'. So, for his/her insecurity and lack of real "cojones," the rest of the team suffers.

Dave Rooney said...

Yeah, I hear you! I have some good friends still on that team, and they're still crunching. One of them described an upcoming release, saying that there was a light at the end of the tunnel... and this strange horn sound coming from it. ;)