Use source control.

How do you know when you're done?

This process step, taught to me by Rob Gingell at Sun, sounds so obvious and trivial that it seems crazy that many people don't have answers to it as they work on their project. So to me, this is one of the most valuable process improvements I have used -- make sure everyone knows exactly what needs to happen before they consider their work done.

Over the years since Rob has taught me that, I am always running into projects that are simply slipping their schedule, week after week, without a clear set of steps that need to happen before they can consider it done. No completion critera. Amazing.

The third time rule:

When customer asks for some feature for first time, it gets just ignored.
When customer asks for same feature second time, it is put into long-term To-Do List.
When customer asks third time, - it's implemented.

This simple rule filters out about 90% of unneeded or just occasional requirements and lets the team to concentrate on topic.

Only if customer asks for the feature more than two-three times, this feature is really worth to be implemented.

Note: Customers must be aware of this rule being applied to the project.

Unit testing. Without a doubt, and in particular the use of TDD. After the initial paranoia (and it is to be expected - see the Satir Change Model ^[1]), the team caught on. Productivity soared. Morale soared. And unsurprisingly, so did the product quality (and I assume user satisfaction, but Product Management didn't tell us that...)

Automation.

While the process of building the product was already automated (via make), the process of creating product images (CDs or DVDs) was not. Nor the testing, nor the test management (producing reports to keep manager-types happy), nor the unit tests.

I'm still working on it, but over the years, I've managed to "steal" resource to automate things (by "stealing" I mean "I told my manager I was deferring work s/he has assigned to me and doing this first" as opposed to "I asked my manager to let me work on automation").

I've met with varying degrees of success. I had the test management completely automated at one point (well, as automated as it could be without the tests themselves being fully automated), but then I moved on to the next item, and testing got reassigned to another team who then proceeded to completely munge it up.

I do find it a constant battle, however. Some co-workers think that a one-off manual process is fine. I take every opportunity, however, to beat them over the head with the utter lack of foresight, when (not if) someone asks us to do it again. Even when they originally told us it would never be requested again.

I banned the use of System.Threading (except in cases where the entire team could be convinced it was necessary). This significantly cut debugging time, and produced more stable applications.

Have a bug/feature request database and don't start on anything until it's entered in the database.

You'd be amazed how many "high-priority" features aren't important enough to create a change request for.

Akin to Srikanth, one of the first major changes I implemented was a move from Visual SourceSafe to Subversion. While the team to my knowledge had never suffered from database damage (knock on wood), I felt that the lock-modify-unlock cycles were severely hampering productivity, and making some changes basically impossible to commit in time ("sorry, I have this file checked out exclusively on my desktop at home"). Plus, many useful tools are available for Subversion that aren't for VSS. Everyone is certainly quite happy about the change.

My team had just done a 100+ hour task of my own design that we (and our customer's bosses) thought would be really useful. We all looked forward to it, and we told our users how great it was going to be. When it was deployed, surprise surprise: Our users didn't get it, weren't interested, misused it, etc. We had to tweak it until it was pretty good, but it would have taken a rewrite to really do a good job. Now the users are stuck with it and, while they use it effectively, I wouldn't call them happy. Nor is the customer happy – having to tweak cost them more than they initially bargained for.

I learned this: Carefully define the problem you intend to solve before you define requirements or start coding. That way you solve the right problem. To do this, get the users involved with problem definition. Get face-time in person if you can and just hear them out, and work to define the precise problem they're having. Usually they will tell you their symptoms. Your role is to figure out the root cause and the simplest solution. This will make the users happiest and will probably save your customer some money.

Have fewer meetings - cut down to one or two meetings per week.

Use Comments

Having lunch together has seemed to be a good thing that I'm not sure who suggested it, but it has provided a few good things. There is the comraderie and friendship factor so that each of us works hard so that the team looks good, pitches in for each other and we have each other's backs, and it provides times for some humour to come in that can help break up what can be a rather dry kind of work when it comes to funny stuff in the office. I know there are places like "The Daily WTF" ^[1], "XKCD" ^[2], and "SharkTank" ^[3] but that kind of thing doesn't happen where I work. No, no sirreee ;)

Use Resharper ...

Set deadlines.

This is was obviously for a much more informal team. But we were finding the work we had to do invariably expanded in the time we had to do it - ie without a due date it took forever.

Just a couple of milestones with due dates sped things up greatly.

Introduced a Wiki. Used it for knowledge sharing, technical documentation snippets, faq, managing checklists and status tracking. Once people start seeing the benefits, it really took off.

During crunch time a daily status meeting limited to a half hour worked well. The limited time frame forced people to focus and communicate effectively. When a topic arose that required more time, we tabled it to get through the remaining times and let the team members who were not involved in the larger issue go work on their items.

Do not debug for IE6.