The following is an Experience Report I presented at Agile 2009 in Chicago (Part 4 of 4)

Damage Assessment

In the end, the product shipped on time, which was the most important constraint.  This project has now been filed under the ‘what not to do’ category, and has joined our cautionary tales section in the Scrum Team training curriculum.

In the spirit of Agile it is said that we learn more from our failures than our successes.  If this is true, then we must have learned a great deal from this project.  Here is a summary of our key lessons learned:

First, believe your estimates.  When it was over, we totaled up overtime hours logged against the project, and time saved by eliminated some regression testing.  The end date of the project would have been October—exactly as we predicted in the beginning.

Second, we made some important discoveries about how to look at critical features.  Any feature, no matter how critical, can be broken into smaller and smaller parts.  Once you do that, you will find some pieces of functionality that are crucial to that feature, and some that are not.  Eliminate the parts that are not crucial, and you can still deliver the critical feature.  This is a well-known tactic of backlog management and we have started employing it religiously in subsequent projects.

Third, you get what you measure.  If you focus on how many hours a team member is spending in the office, they will spend all the hours you require in the office. If you focus on completed features, then the teams will focus on completing features.  You drive the behavior of your teams by what you consider to be important.  If you make a date the most important thing in your project, then you will surely hit the date.  Just be sure you’re willing to give up the other things that the teams stop focusing on to achieve your target.

Fourth, understand team dynamics.  After serving on the project as a team member instead of a lead, I can say with complete certainty that every agile leader should spend some time in the ranks of the team.  It is a completely different experience to be on the inside and try to encourage team behavior.

Fifth, education is key.  We now require line managers and product owners to take training along with their teams.  We have added more in-depth material on agile release planning.  Our biggest challenge is figuring how to educate senior management in why Agile works the way it does and demonstrate the benefits they’ll receive if they let it.

Finally, bring Agile into your process.  We have started working with the QA group to define an agile variant of the Process.  It’s not perfect yet, and still contains too many artifacts of its waterfall roots, but it is another step on the evolutionary path.

Overtime vs. Team Commitment

Every person has an optimal pace.  If you impose overtime, you put stress on the system.  When stress levels increase high enough, you send the person into a panic state.  The fight or flight instinct kicks in, and they fall back on instinct.  Cornered humans are just as dangerous as cornered animals.

When focus was shifted to completing the features, every member of the team put in extra time to meet the deadline.  But the effort was at a pace that was comfortable for them, at a time of their choosing.

Overtime should not be imposed on the team from the outside, but holding a team to their commitment should be.  When a team truly commits to completing their sprint goal, they really will do what it takes to succeed – including putting in extra hours.

Destroying Team Unity

I’m most troubled by the damage done to our sprint teams by this project.  We spent two years convincing them to work together, and freely share information.  We had gotten them to the point that they were more concerned about disappointing their teammates than they were about looking foolish asking for help.  After going through all that, and then to rip it away, was like a cruel joke.  Management essentially took a mindset of “we live and die as a team”, and discouraged every activity that supported those behaviors.  Instead, they encouraged individual behaviors that reinforced self-interest.  When this project ended, the team members were burned out.  And the next project started up all too soon.

The Long, Slow Road to Recovery

In the next revision, I resumed my role as lead.  The teams I got back were broken.  For the first few sprints, they were visibly coasting.  I couldn’t really blame them.  They had been betrayed.  Their own productivity was measured and used as a bludgeon.  They couldn’t easily forget that it had happened.  We struggled to convince them that there was still value in making and keeping commitments—to sustain a strong effort throughout the project.  We fought to restore the concepts of self-direction and servant leadership.

It took four months.  Four months that we could have been running at normal efficiency, instead of what remained in the aftermath of the death march.

It was as if they were starting from scratch all over again.  Actually, it was worse.  They were coming from negative territory.  At least the first time around, they were giving Scrum the benefit of the doubt.  Now they know what can happen if it is misused.

As of the writing of this document, we are nearing another project conclusion.  The deadline is getting close, and a few critical stories remain on the backlog.  During sprint planning, I brought up the revised release plan and showed the teams that the previous rounds of sprints hadn’t advanced us as much as we had hoped.  I suggested that we might want to consider…

One of them cut me off.  “Go on.  Say it.”

Say what, overtime?  That’s not what I’d say.  I’d say look at where we are, and where we need to be at the end of the sprint and see if you think there’s a way to do something about it.   Do what you need to do.

I know we’re not out of the woods yet.  They’re still jumping at shadows.  By the time I present this topic at Agile 2009, the project will have ended.  I hope to have good news to report.  But today, with four days to go in the sprint, that burndown chart is looking really sweet.  Go Team.

 

Return to Top: Weaponized Scrum Main Page