Learning Lessons — Can You Make Mistakes at Work?

Of course you make mistakes, that’s not really what I meant. Can you comfortably admit any type of fault in your workplace without undue fear of reprisal? Do you trust your teammates and management enough to discuss problems openly or do you sweep problems under the rug? After all, we know that admitting a problem is the first step to recovery.

A Healthy Environment

Last week my team did a project retrospective on our last four months effort. Half of our team is new to the company and our team is distributed between Austin and Houston, so there were definitely some rough spots to sand down. We came up with a list of problem areas with our execution and some lost opportunities. It was actually a very positive experience, because everyone involved was focused on improving our execution instead of pointing fingers or deflecting blame. Never once did I feel defensive or sense any kind of defensiveness in anyone else in the room.

We’ve already started to implement some improvements in our iteration and project management. Of course we still have to follow through and correct the problems, but at least the team got the issues out into the open and everybody is aware. I’ve heard the phrase “Lessons Observed” in the past to describe teams that don’t act upon their lessons.

The Blame Culture

Much of my IT career has been in a shop where too much energy was wasted on blame avoidance and “CYA”. We didn’t learn any lessons or ever make any corrections because no one ever wanted to admit any kind of failing. It was more or less a waterfall shop (and still is) and management stressed a predictable project date and resource count over everything else. The worst sin was missing a deadline. The result? Sacrifice quality or outrageously pad estimates. I routinely saw projects that were coding right up to the production install because everybody was afraid to miss the arbitrary date. Very scary.

External compliance teams are the worst. They aren’t involved in your project at all, but they get the last say on the success of the project by putting out a metrics laden scorecard. One of the primary measurements is a bug count read out loud in a nasty meeting at the end of the project. The typical response was to hide bugs. Developers would quietly negotiate with testers to fix bugs without reporting them. That’s an awful practice, but it seemed more like survival at the time.

Now they’re climbing up the CMM ladder (I think they’re about to be level 3). It turns out CMM is a great work avoidance tool. You need what? Did you fill out the correct paperwork? Sorry, I can’t do that until I have the TPS form signed and approved.

Avoid the Embarrassment Meeting

Be careful how you use metrics. Metrics reveal information and trends about your effort, but they’re never the entire story. Avoid the “embarrassment Meeting” described by Steve Maguire. Misuse of metrics to punish people leads to stupid behavior that doesn’t contribute to the project.

An agile process alone isn’t enough. I worked on an XP-ish project with an absolutely miserable jerk of a project manager that routinely abused the development team with metrics. The developers varied wildly in skillset, and we were struggling. Every iteration close meeting featured a full review of exactly how the development team missed their estimates on a story by story basis. One time he went away to a conference for several days. Coincidentally the developers had what we all considered to be our best iteration. We completed stories on time, we got a lot of refactoring done that had been put off, and we even managed to make some overdue improvements to the NAnt build. The project manager came back from his conference, looked at *his* metrics, and loudly declared that we still weren’t doing any better. I wanted to punch him.

An iteration later, I excitedly showed him a story that was finished ahead of the estimate. His response? We had sandbagged the estimate in the first place.

After some external intervention from higher management, we made some adjustments to our estimating and planning process that lowered the misery on the project considerably. It wasn’t pleasant, but the mistakes were recognized and corrected. A healthier team would have made the correction faster though. I sincerely wish I had done something to alleviate the problem instead of fuming, but I didn’t feel comfortable in the environment and didn’t feel like I had a voice in the project.

To state the obvious, that was a dysfunctional environment. Martin Fowler has some pointed comments on the usage of metrics here.

Does Agile Development Help?

I want to say yes, but the real answer is “it depends.” I think this is really more of a people issue than a process or organization problem. An iterative process is definitely advantageous because it gives you so many more chances to reflect on your project and make adjustments mid-stream. However, if you don’t trust your team or feel comfortable making yourself heard this opportunity will be wasted. A team with poor chemistry is probably going to fail no matter what else is in place.

One of the tenets of agile development is the self-organizing team. It is everybody’s responsibility to continuously improve the team’s work, not just the project manager. Being empowered to make changes in your process means you’re responsible for the process. Don’t ever assume anyone else knows something you don’t. If you think your team is doing something wrong, say so, no matter what position you have on the team.

Collective code ownership does help in this regard by removing some psychological barriers to code inspection. Classic code reviews can be nasty affairs. A row of accusers sitting across the table from a solo defendant is the image that comes to mind. With true collective ownership, the team can calmly talk knowledgeably about improving “our” code instead of pointing fingers to “his” code.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.