What's in Your Head (of Tree)?

Head of Tree. Tip of Tree. It's your source code repository, where you check in your latest and greatest source code. Could you ship it to a customer at a moment's notice? Actually, would you ship it to a customer? I understand your hesitation. The latest code still needs to be tested. You have to shake out the bugs, and then beat the release into shape. And then after a stabilization period, you're ready to release-- probably weeks to months later, right?

At Cassatt, we switched to a new development process in PD at the start of the year. Head of Tree, or HoT as we affectionately call it, is always shippable. Asynchronous projects are used as the vehicle for developing new functionality or fixing bugs. Each project has a well-defined scope and is completely self-contained for completeness. When a project is launched, its completion criteria-- the required functionality, expected quality criteria, associated application payloads and documentation-- are all defined up-front. Only when the project meets all of its completion criteria, can it integrate to head of tree.

In this new model, a project can not integrate if it introduces new bugs or regressions. So, all projects must integrate with zero bugs. So as new functionality is introduced, the overall quality level of the head of tree is maintained. Since many projects introduce new automated tests in addition to new functionality, the overall quality of head of tree can increase over time.

Transitioning to this new process was a significant cultural change for the Product Development organization-- and it wasn't easy. Starting in the last quarter of 2006, the PD management team defined the new process and worked through the details. We flattened the organization and centralized decision-making to one Product Team. And there were many small bumps and hiccups along the way. At times, we were still working "the old way" in the new model, and we had to make a conscious effort to change. At times it felt like we were working more slowly in the new model, but we found that there were fewer missteps and almost no "steps backward" to move forward. And by slowing down, we took the time to review architectural changes to the system and understand their impacts. With each new project, we got better and more efficient at defining requirements, planning, developing and testing. Along the way, we developed new metrics and reporting tools to monitor the projects and the head of tree.

It's now been six months since we transitioned to the new model, and we have seen several tangible benefits.

1. New functionality can be developed and released to customers quickly. There is no need to "wait for the rest of the release" to complete.
   
2. Projects can be sized accordingly to complexity and/or effort involved. A "large" project can complete in 3-4 months, and a "small" projects can complete in 1-2 months. Simple bug fixes can be handled in a lightweight manner, requiring only a few days.
   
3. Requirements are defined and understood before starting development. We have even decided to not proceed with some projects because the scope was not appropriate or the ROI was not sufficient.
   
4. Development has become more predictable. We maintain an integration schedule for the next several months and let our Field know when to expect new functionality. The upcoming integration schedule is reviewed weekly with Sales and Professional Services.

In a future posting, I'll provide more details about the process and also talk about some of the metrics we use to monitor progress. Until then, have a happy Fourth of July, and stay safe!