Good observations by all, and I agree wholeheartedly (especially with the last one ). The advantage of self-hosting is very very powerful, and the visibility and subsequent awareness (by all team members) gave everyone more of a “personal stake” in the endgame.

BTW, if you mentally “stack” M4D1 + M4, and M5D1 + M5, in the first chart, you’ll see even better a high-point around M5 (with each of M4, M5 and M6 being extremely busy) which makes the resulting picture even smoother. I was pleasantly surprised when I first saw this chart.

james

Excellent post. I think the visibility was key, especially given the fact that the team was so distributed. Any team can benefit from the developer and business visibility that RTC provides, but for distributed teams I believe it is a must have.

Great post Scott, along with the fact that we were releasing Release Candidates every friday provided more credibility to our statement that we have workable code at every milestone. Add to the fact the we had nothing to hide from a delivery perspective and that most of the team members are all distributed. To orchestrate such a smooth end game, is something to celebrate about.

This was a really interesting post, thanks for sharing. It’s funny, with all the effort we put into metrics (i.e. burndown charts, velocity, etc, etc), sometimes the most important metric is just what your wife thinks :)

hey dad great article! i liked it but mention me next time!

Scott:

This was great – so many times you hear about what went wrong in a project. It’s great to hear about what went right.

Mike

Hey Scott, I’ve recently had some new perspective on this. I am in the middle of a tough endgame with one of our new cloud products and was talking to Jamie Thomas about the difference between the Team Concert 1.0 endgame and this current cloud endgame.

In hindsight, one of the biggest benefits Team Concert 1.0 had was that the architecture had basically stabilized several years before we had to ship. I remember one of the toughest pushes for Team Concert was getting to the “unzip install” for OOPSLA 2006. If you recall it was really tough to get all of the components into a simple package, but that same basic unzip install persists to this day. After that there were some incremental architectural changes (e.g. progressively changing operations to be process-enabled, optional Installation Manager-based installer) but the architecture was pretty stable.

Another thing Team Concert 1.0 had going for it was that the architecture was extremely homogenous. Everything was a plug-in and everything was based on the same core APIs and extension points. In the case of both early WebSphere Application Server and our new cloud product, they are the combination of several components that were designed in isolation from one another and then later integrated to form the product.

So while your blog entry above rightfully points out some process aspects that led to a smooth endgame, in hindsight I think it also was largely due to the architectural stability and self-consistency.

@ Bill – This seems to be a lesson that we refuse to learn:
“the cost of reusing whole products is often much higher than to rewrite”
An ironic example was that a year ago we already had the core pattern engine from vApps built natively on top of HSLT. I year later the integration between the two products is not nearly as clean, effective, simple, and robust.
Prior to acquisition, most of our end games were much like Rich’s story. Although, we weren’t self hosted. We had a small team of “A players” all in one location – literally in one big room. As problems came up – they were visible to all and quick discussion followed by quick decisive action ensued.
The counter point to your comment about architecture is that many cloud based apps like instagram have great stories about swapping in/out major parts of their architecture very quickly.
There is no substitute for competence and no substitute for being in the same place. As for architecture changes, I think there is also no substitute for decent code. Nasty code that no single individual actually knows will always be fragile and difficult to change/evolve. You can only evolve code you know and that is well written. From my experience, picking up lots of open source code can be very effective because you can see the code. If it’s nasty you steer clear. If it’s good, clear, and workable – then you can do it very efficiently.

In summary, there is no substitute for competence, collocation, and code – the 3Cs :-)

Thanks for the interesting conversation, Bill and Andrew, although I have to add that we were not advantaged with Collocation. The RTC 1.0 team was simpler than CLM is today, but it was already spread across at least 5 sites spanning nine timezones. Component teams were largely collocated, but we had to learn to collaborate and integrate across sites to build the product.