Go Ahead, Throw That Practice Out
August 25, 2019WHAT 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. This French quote from Antoine de Saint Exupéry 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 byproducts 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 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
- Newly discovered bugs keep pouring in from customer test groups
Team leaders have a tendency to keep adding more processes, 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 off 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 understanding why it is 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.
This article first appeared in the book – 97 Things Every Project Manager Should Know and has been reproduced here under the Creative Commons – Attribution 3.0 license.
