As avid blog readers, you no doubt remember the background on Project Pittsburgh, but I’ll summarize. After the shipment of the last release of our product (during the Milwaukee leg of our Baseball Trip 2010), we started immediately on our next release. During the early stages of that release, it was decided in early 2011 that we would be merging our product (and development and test team) with two peer products (and their teams) into this convergence (confluence) product nicknamed Project Pittsburgh. Project Pittsburgh has been moving right along through nine completed development sprints which completed before Thanksgiving. Since then, the entire team has been focused on finding and fixing defects – almost three full months of nothing but testing and fixing bugs.
The daily routine is pretty, well, routine. You get assigned a defect, work on the fix, unit test the fix, run a test build that generates a new version of the product that includes your fix, run the test build through the Test Automation framework, and then integrate the fix. Lather, rinse, repeat. Grab the next defect and move along son!
The project managers establish these planning deliverables called Defect Takedown Projections – these are weekly targets for the number of open defects that each component team on the project needs to hit in order to ensure the software can be shipped at its release date. The targets are based on Open Defects As Of Monday Morning. So if your team hasn’t met its weekly target by Friday afternoon, you will work the weekend. Even if your team is in good shape, you get loaned out to other teams that are more challenged (particularly when you have worked on three or four of the component teams during the sprints). So there went January weekends (and the start of February as well). Oh well, it is good to be gainfully employed, but, Geez Louise, these days really tend to run together when all you are working on is defects.
One of the casualties of this long release cycle was our official product name. As I kidded about in this post, there seems to be some room for improvement in the IBM Product Naming Process. Well, last spring, the Product Naming People did their magic and out of the oven came our official product name: ITUSC (as officially described here). So ITUSC it is. Or was at least from last May to last week. Apparently, Very Important People were not all that stoked about that TUSC name, so in early February we received marching orders for a new official name (which I am not permitted to divulge at this time – Business Conduct Guidelines, remember). So, the last week has involved changing all the ITUSC references in the software and publications to our new official name. Really exciting stuff.
A couple of weeks ago, an email came to my inbox from one of our lead engineers, Dan. One gets so many emails during the course of a day that one will do a quick review of the title to determine whether it gets immediate attention or is just a notification. For example, we get emails from the problem tracking defect anytime a defect that you are working on is updated and we get emails from our automated test system when a build is successfully installed and we get emails when a build passes our Build Verification Test (BVT). Very low signal-to-noise ratio. Anyways, I quickly scanned the subject of Dan’s email which was titled:
Subject: Frank’s Laptop Died
The purpose of the email, of course, was just to let the rest of the team know that one of our team members would be offline for awhile due to an equipment malfunction. Given my state of mind and my hasty subject scan, my immediate thoughts were:
- Damn. Project Pittsburgh claimed another one. Too bad Frank couldn’t hold out another couple of weeks to at least see this stuff ship. He was a young man when this project started.
- Who in the hell is going to work on Frank’s defects now?
