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.

21 June 2008

Defining Moment

When coaching a team new to Agile, you're always looking for a defining moment. This is a point in time when the proverbial light bulb goes on over the team's head about not only how they should be doing Agile practices, but why. It roughly equates to the Transforming Idea in Virginia Satir's Change Model, and is a reasonably good indicator that the team is about to move from the Chaos stage to Integration and Practice.

This past week I was giving an introductory workshop to a team I'll be coaching for the next couple of months, and I used Jean Tabaka's Doggy Day Care Brochure example as a simulation of an Agile project. To my utter astonishment, this team had that defining moment within the first 30-45 minutes of a 90-minute exercise. The project planning was carried out with one person as the Customer, a couple of devlopers as Testers, and the actual Customer, a manager and a business analyst as developers. Everyone latched onto the concept, and immediately liked using index cards for planning. During "implementation" on a whiteboard, the developers noticed that their estimates were sometimes wrong, the testers found some implementation issues (including an edge case in the pricing!), the customer realized that a new story was needed. For the second iteration, someone who had to step out to another meeting returned and joined in as a second Customer. This really streamlined the process of feeding work to the developers.

During the retrospective, the person initially acting as the Customer highlighted that she felt overwhelmed and that she was a major bottleneck, which is something that many have pointed out as a weakness or risk area of Agile. It was interesting, though, to see someone experience that issue so acutely within a simple exercise!

I usually hope to see a defining moment during the first or second iteration, and certainly don't expect to see it in the initial training! The upshot of all this is that I believe this team is destined for success in their transition to Agile.

20 June 2008

Scrum is not Enough

A post by Ken Schwaber on the scrumdevelopment Yahoo group a little while back caught my eye. It was a response in a thread entitled "Scrum and Architecture", and Ken's response ended with,
In order to employ emergent architecture, every Sprint must leave behind clean, commented, refactored work. Otherwise emergence hits the wall within six Sprints (or sooner, depending on how bad the morass is).
I was rather surprised by this, since it's tantamount to an admission that the Scrum practices alone are not enough to provide a team with a process that's sustainable for anything other than the short term. It's not the content of the comment that's surprising - many people have said the same thing, myself included - it's the person making the comment!

Ken has been vocal in the past about the fact that Scrum deliberately avoids prescribing any technical practices. However this comment belies the fact that he already knows that without solid technical practices Scrum is simply not enough.

Is that the message being conveyed to groups new to any Agile development? I don't believe so. How may teams have adopted Scrum because it's the lowest agile common denominator, only to find out within a few months that "this agile stuff doesn't work"?

So, for the sake of anyone considering a move to an Agile process, let's make this perfectly clear:

Scrum is not enough!