The Importance of doing what you say you do.

I've worked in several organisations, in many different industries and styles. From blue chip insurance companies to telecommunications startups to crown corporations. Each organisation had a different style, be it XP/Agile, ISO-9000, or Wild West.

However, all of the successful ones had one thing in common. They did what they said they did. For example, if they said they used a waterfall development model, they made sure that that really was how they developed software. If they were XP, they followed the practices (all of them) in Kent Beck's book.

The organisations that struggled were the ones that either didn't say what they did, or worse, said one thing but actually worked entirely differently.

Everyone knows these groups. They don't understand why they fail, and they don't understand why they succeed. When they amazingly do succeed it is usually because of a sheer force of will by the team.

At first I thought it was certification that differentiated the organisations. The ISO 9000 certified teams developed better software than the others. But that wasn't it either. I've worked for organisations that didn't have ISO 9000 certification and developed good software, on time, and on budget. I've also worked for ISO certified companies that completely failed to actually deliver working products. It helped that the ISO training I had said that ISO didn't guarantee quality. :)

Certifications aren't key, although they do help. I feel that communication is the key. With good communication, the team can quickly come to a concensus on the state of the project and what the next step is.

I see this all over the place. As teams get larger, communication gets harder. It isn't just that the number of possible conversations increases exponentially, it's that each person finds it harder to communicate.

A small team develops a method of working through peer pressure and shared experience. They do things a certain way because they have always done it that way, and it works. They don't have to talk about it because the communication between them is constantly happening. The small team is able to monitor each other to keep each other out of trouble. For example, if someone decides to rewrite a piece of code, they will tend to avoid causing problems for others since they know what everyone else is working on.

As teams get larger, this communication becomes harder - it no longer happens as a side effect. New members don't share the same experiences, so they make the old mistakes all over again. Even worse, people start spending more and more time cleaning up after each other's changes.

I believe that the key is the shared metaphor -- the development culture. If developers in a team are able to say, "We do that", and everyone understands what "that" is, the team is better off. New staff understand what is expected of them, and what to expect of their team mates. If people share the same language, that saves time allowing the communication of more important things like, "What's Bill doing today?"

This is where codification, standardisation and certification helps. It gives everyone a common understanding. It doesn't have to be CMM or RUP or ISO 9000, it just needs to be understood. If the process you are following is based on another one, it is important to state the divergences.

For example, I worked for a group that said they used XP. However, they didn't do continuous integration, pair programming, short cycles, the planning game, have an onsite customer, work a 40 hour work week, or do test driven development. They did refactor, have a coding standard, have an automated build system that did run unit tests (which were disabled because they failed too frequently), and they did have short cycles (albeit with fixed content). They then went from a 4 person team to 12 people over the course of 3 months. There was a lot of angst because new developers who were hired with the expectations of XP kept running into barriers as they tried to go against the flow of the team and do all of XP. Once the new hires learned how the team was really expected to work, the complaints faded into the background and were dealt with as expected problems instead of process failures.

I've always said that if you don't improve how you do things, you're going to get worse. If a team doesn't "do what it says it does", there's no real way to know where the holes are. Without a common understanding, people may think that something is covered off when it isn't. If you've played any doubles sports (tennis, badminton, volleyball) you'll understand this. This is the point where everyone watches the ball head towards the ground waiting for the other person to play it.

So, "Doing what you say you Do" is all about communication, honesty and self-improvement. This has nothing at all to do with which type of process you use, many are appropriate, including "Hack it until it works". What does matter is that everyone on the the team knows and understands what it is that the team does.