What a week! I've had a deadline that has been approaching for a number of weeks where my team has had to make some new functionality available in our software to meet compliance with a standards body in one of our markets.

We've had ages to get it done and the initial estimates for time gave us plenty of buffer for unforeseen problems. All in all it should have been fairly easy to do and definitely not the source of pain and lack of sleep that it was.

As the deadline approached I was doing the right things - checking on my business analysts, developers and testers to make sure that things are progressing and being assured that all is under control. I checked their work and monitored their progress - ie I followed "normal management practices".

Why then, this week did each of the people assigned to the job need to work 60 hours in 4 days including all nighters to get the job done? Why did I have to stay there with them, cut code and do testing to help them get it complete? Why does this sound like a classic "death march project" symptom? Why?

I can point to poor existing software on which the changes were being built, I could point to changes in the specifications being passed through late by the regulating body, I could point to a lack of test coverage and test cases, I could point to poor skills or poor application of skills, I can even point to myself for not seeing the problems earlier. In fact, I could point to a whole bunch of things but at the end of the day they are merely symptoms of an underlying problem, and one with which I have been trying to deal with since I joined the company.

"What is that problem?" I hear you ask. The answer is "Culture".

I'll be sitting with my team next week to debrief and think about the problems and why they occurred and more importantly what they think the current culture is and how we can change it.
I'll blog about the results of this and my thoughts after it's done.

Time for sleep now :-)

Update:

After the debrief with the team, the things that came up were not that surprising. They talked about communications, code quality, unclear specifications, etc.

Since these things have happened before (deadlines rushing up, last minute fixes, etc) I asked what needed to change to stop it happening again. Unfortunately, while they found it easy to point out the symptoms, they couldn't come up with anything for a solution.

Upon reflection, it's probably an issue related to being "inside the problem" versus seeing the problem from outside the box. When you are too close to an issue you often can't see the root causes since you are tied up in the day to day and the minutiae.

The only way I can change this is to drive home a sense of quality before anything else, and taking responsibility for poor code. I've finally made the developers see the value in code reviews and it is now something they want to do versus being something they are forced to do.

Similarly the analysts now expect change to happen versus being frustrated that it does.

While it was a difficult few days to get through, I think there are some hidden intangible benefits to it that are starting to become apparent. My job now is to encourage the change in attitude as this will result in a fresh quality focused culture - and that makes everyone's job more enjoyable in the long run.