Do you suffer from DID? Part 2

I Think Its Happening Again!

When is one likely to suffer a DID episode? If you recall from my previous post one who suffers from DID, "Transitions from one identity to another are often triggered by psychosocial stress." If its true that stress triggers DID, then simply reduce stress in order to reduce the likelihood of future episodes.

First, identify what causes stress on the team. It could be anything from an unstable code base to a physically uncomfortable work area, whatever the cause bring it out to the light! Motivate your team to take an hour out of the schedule to identify the stress points, preferably in an informal environment but make sure that everyone knows this is a serious meeting!

Once your team has identified what your impediments are, get rid of 'em! Don't try and change everything all at once because you might find yourself getting overwhelmed and not fix anything. Focus on one problem at a time until its out of the way and then tackle the next one.

Identify "The Problem"

I once worked on a project where I was the "new hire", the rest of the team was composed of a few junior developers, our project lead, and the project manager. The project, which was a few months behind schedule, was for a strategic client and success would mean we would land several other deals with their teams across the globe! The developers where only working on the project two weeks and on my first day we were moved into a "war room" to start "crunch time".

war room (noun):

1. a room at a military headquarters in which strategy is planned and current battle situations are monitored.
2. any room of similar function, as in a civilian or business organization.

crunch time (noun):

1. a period of intense pressure; a critical situation: "It's crunch time for high-tech companies."

In our case, the war room consisted of a corner with a bunch of broken down cubicles. I thought great, this will improve communication in the spirit of "sit-together" and "whole team". However when mixed together with summer season crunch time (12-hour work days plus Saturdays), our communication manifested itself as annoyance, disruption, arguments, and often silence.

Our team would blow off steam drinking alcohol, which allowed us to let our guard down and started revealing all of our concerns about the project. Everyone would exclaim how much we hated the project because of changing requirements; impossible deadlines; brittle code; slow computers; no A/C on the weekends; long work days; 3 am international conferences calls; slow feedback from a manual QA process; and many other things we don't have time to mention.

Although we would get together outside of work to "get things off our chest", it did not improve the quality of life or make the software any better. All we did was identify the problem but some teams don't even do that much because they are in denial.

Deal With "The Problem"

It's not enough to speak but to take action! As I mentioned earlier its best to deal with one issue at a time. Start with one you can get done in less than a week and of course the one that is in your control. In my case I was able to deal with the brittle code problem by encouraging my team to use test first development. I knew that writing test cases would help us because...

The more stress you feel, the less testing you will do. The less testing you do, the more errors you will make. The more errors you make, the more stress you feel. [Beck in TDD By Example]

When I took on my first tech lead project, I stood firm and told them that I would not accept any code that was not tested. Tim agreed under the condition that I give him some time to write the code before working on the test cases. I told him that we could work together to set up Eclipse and write some of the test cases when he was ready but told him it would be easier if he wrote the tests first.

The time finally came when we sat together to write some test cases. During our first session the tests revealed that the components he was working on were tightly coupled and we eventually caught a few bugs. Tim was so impressed that he vowed never again to write code without tests!

The Results

For the first time, our team was confident with the code we were releasing and having a suite of regression test gave us the support we needed to start delivering code faster! The project manager was amazed to see the JUnit report and how fast we were able to deal with bugs and adjusting to add new features! Simply writing a few test cases helped us reduce our stress exponentially. For the first time we were making promises that did not require us to work 60 hour work weeks!

Today, I am proud to say that a few of my former team members continue to use TDD and have moved adopt other agile practices. Tim, for example, is a Scrum Master who practices XP and he is a contributor on the Eclipse BRT project. If you are reading this aren't you glad I turned you on to it?

So why don't you give it a shot? Identify what's wrong and fix it one problem at a time! I guarantee that it is going to reduce your chances of having another DID episode!