Go Ahead, Throw That Practice Out

What do successful teams do that others don't? They constantly question their own practices and try to eliminate wasteful ones. They mercilessly refactor their processes along with their software.

"Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher." - Antoine de Saint Exupéry. This French quote means “Perfection is attained, not when there is nothing more to add, but when there is nothing left to take away”.

Why don't teams apply this principle today? Why is it that over a period of time, the value of the end product gets thinner and thinner and the process and by-products get bulkier and bulkier? Why do the lines of code expand, while the useful features of the software become fewer and fewer?

Key indicators that things are “broken” in the software development processes:

• the software bloats up in terms of lines of code and useless features,
• the team building the software keeps growing in size,
• the process they use gets more and more prescriptive, dogmatic, and rigid,
• the team is experiencing “death by planning” meetings,
• the amount of documents and supporting artifacts increases exponentially,
• and newly discovered bugs keeps pouring in from customers test groups.

Team leaders have a tendency to keep adding more process, more checks, and more audits, thinking that an increasingly stringent process will solve the problem. In my experience, it's never a process issue. Adding more processes will only make it that much more difficult for the team to see the root cause of the real problem.

Why is it that most teams are afraid to throw away practices that are not really helping the team? Why do teams start of with as many practices they can think of, instead of adding the practices just-in-time?

This could be a symptom of the team not really understand why they are using the process in the first place. Or it could mean that someone who does not fully understand the software development process is forcing a heavy-handed methodology upon the team. In either case, the project becomes a "house-of-cards" ready to disintegrate into a useless pile of code bits. Trying to change anything, without understanding the true reason the project is expanding without adding value, is useless.

In my opinion, a good project manager should have a healthy grasp of how the team is working. He/she should be able to stand back and evaluate how each process imposed on the team impacts the throughput of functional software.

A knowledgeable project manager should sift through all the possible activities a team might be asked to do and retain only those that are vital to the success of this specific project. Once the leftover practices from projects past are swept away, the team's productivity and throughput should get better in a short period of time.

"Less is More" is a very important philosophy when it comes to process.