After reviewing one too many books where agile project management techniques are rolled out perfectly to a reticent but soon to be enlightened group of programmers, I was reminded of a quote from an old science fiction novel, “Show me a completely smooth operation and I’ll show you someone who’s covering mistakes. Real boats rock.” It’s understandable – many of the people writing the books are selling a methodology, training, or consulting services. They’re not going to talk about their failures and mistakes in great detail. That’s a loss, as I believe that others’ mistakes are a great opportunity to learn, especially in the space of agile project management where teams explicitly try to drive on the narrow road between unstructured chaos and draconian order. Since I’m just trying to ship a product, I can’t talk much right now about the technical details of the project I’m working on, and I’m a manager and largely overhead anyways, I figured I’d spend some time talking about things that have gone wrong in rolling out some of the specific practices.

Some background

About two and a half years ago, Nautilus started experimenting with agile project management techniques. Today, we’re using scrum for about twelve people split into two teams. Over the course of retrospectives, it’s changed a bit – probably enough to cost me my certification, were I the kind of person who collected such things. I generally feel good about where we are and how we execute today, though I’m both hopeful and a little bit afraid of how things will go as we continue to staff up. I’m not going to go into details, but the team has put together many hundreds of thousands of lines of code and tests, over a bunch of assemblies. It’s not a group the size of a standard Microsoft product unit, but neither is it a group of a five people doing XP for a month in a conference room.

My first mistake as a manager: force-rollout of TDD

Before becoming a manager, as with most everyone at Microsoft, I was an individual contributor engineer. I wrote code and tools, and quite a bit of it. I also prided myself on being the sort of person who checked things in without bugs the first time. So, when test-driven development (TDD) became trendy, I was one of the early people to jump on the bandwagon. To this day, I believe that authoring tests before code is the best way to author code and ensure that it’s doing what you want it to do, force reflection on the design of the system, and prevent the authoring of unnecessary complexity.

But trying to force it onto my team nearly got me lynched.

I went through the presentations on TDD by the book, extolling its virtues and showing how to do it even on a mature codebase. Then, I attempted to push its use on the team as required practice. Bad move. My team contains many engineers with at least one decade and many with two decades of experience writing production code to very high quality. I was nearly laughed out of the building, to comments along the lines of “if I want to sit down, I don’t throw myself onto the floor first to ensure the need for a chair!”

After reflecting for a bit on the history and culture of the company, I realized that the issue was largely one of development style: people here like to map out today’s and tomorrow’s requirements and then design a system that will fit both. The idea of creating a system that only works for one version or writing code that you’ll need to throw away (but might forget to!) is like asking a working-age Swede to put milk or sugar in their coffee – it simply isn’t done. I went back to the team with developer test code coverage goals and details on the architecture reviews we were putting in place to ensure we were building not only just the right stuff, but stuff that was consistent across the whole platform. That not only went over well, but has been embraced by the team and is now such a matter of course that we actually encounter a little bit of culture shock when we work alongside or deliver to teams that don’t hold the same bar. So, we don't do TDD uniformly across the team, but we do all produce developer tests to a high code coverage number and go through architectural reviews.

The lessons to take away: understand the culture of your organization deeply to avoid embarrassment, and be clear about what you are really trying to achieve.

Coming soon! Or, well, eventually, possibly, maybe…

  • Over-driving the scrum burndown chart
  • What happens when people want to walk out of the daily stand-ups
  • Taking dependencies on an old, mature organization
  • Delivering to a new, young team

Shameless plug

Want to work on the coolest team in Microsoft for a manager who isn’t afraid to admit his mistakes and make changes? I’m looking for a developer to build a user interface framework on Avalon for building developer tools. What could be more fun than that?

[Update: got feedback that the end results weren't clear, so I added a statement to clarify them!]