I have just spent a couple of days with a customer that is looking at Jazz, and Rational Team Concert in particular, in a proof of concept. The customer is great. They are intelligent, fun to work with, and they have a good understanding of what they want to do, and how they want to get there. There is only one problem.
They set up their proof of concept environment on “borrowed” hardware from their infrastructure team. At the end of last week, the infrastructure team reclaimed the database server, but never asked the team if they were still using it. So my customer came in one morning to find that nothing worked, and after some quick troubleshooting they discovered that their database was gone. Two weeks of work on a project was gone, in a single instance of non-communication. A bad day.
Then they discovered that their database had never been backed up. A REAL bad day.
So now we have to recreate the proof of concept environment, and quickly.
Since we had a copy of their process template, and copies of their build.xml scripts, we have made significant progress in restoring their environment in less than two days. This was pretty easy to do, and didn’t require much effort from the team, just myself, their project manager, and their lead architect.
We have been able to restore (and improve upon) their work items, their workflows, and the governance of their process. Their architect has been able to recreate their build environment, as well as the automated testing and code coverage pieces. We are now importing the code from their original source code repository, ClearCase, and re-establishing their synchronization with ClearCase (which is being utilized by the rest of the organization). We still have some issues around publishing and saving code coverage results, but in two days we have essentially recreated their entire development environment.
What We Relearned
I really like Jazz, but this highlighted a couple of things for me. The most important one is that when doing a proof of concept, it is vital that everyone know what is going on. It’s OK to do these proofs of concept on borrowed hardware, but make sure that your organization is aware of how long you will need these resources.
The next lesson is the same one I relearn every time I kill the hard drive on my laptop. Backups make sense.
What I Really Learned
Some of the more subtle things that I learned have to do with the ability of people to adopt the Jazz technology. This team had just lost 2 weeks worth of work, which is not a trivial loss. It would have been easy to just pitch the proof of concept overboard, blame the tool, and continue working the way that they always have. However, this team liked the Jazz environment enough to shrug off what could have been a substantial blow to the project, and continue on with Jazz. They even used this as an opportunity to further refine the workflows that they had previously had in place. This was a powerful message to me.
The second thing that really struck me was the relative speed with which we were able to redeploy the Jazz environment. We has just lost all of our server setup, customizations, all of our work on the process, the project organization, and our work item customizations. If this had happened to us with an integrated set of tools, the work to redeploy and reconnect everything would have taken us a week. This was the significant nugget of wisdom that I was able to pull out of what could have been an unfortunate situation.