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…
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!]