There are 5 worst practices that if stopped immediately will improve your productivity by a minimum of 12% and improve quality by a minimum of 15%. These practices are so common that people assume that they are normal — they are not, they are silent killers wherever they are present.
We often hear the term best practices enough to know that we all have different definitions for it. Even when we agree on best practices we then disagree on how to implement and measure them. A best practice is one that increases the chance your project will succeed.
How often do we talk about worst practices? More importantly, what about those worst practices in your organization that you don’t do anything about?
When it comes to a worst practice, just stop it.
If your company is practicing even one worst practice in the list below it will kill all your productivity and quality. It will leave you with suboptimal and defective software solutions and canceled projects.
To make matters worse, some of the worst practices will cause other worst practices to come into play. Capers Jones had statistics on over 18,000 projects and has hard evidence on the worst practices1. The worst practices and their effect on productivity and quality are as follows:
|Friction/antagonism among team members
|Friction/antagonism among management
|Inadequate communications with stakeholders
|Layoffs/loss of key personnel
|Excessive schedule pressure
Excessive Schedule Pressure
Excessive schedule pressure is present whenever any of the following are practiced:
- Senior management declares the project deadline
- Formal estimation methods are used but senior management ignores them
- Informal estimation methods (i.e. SWAG) are used
Excessive schedule pressure causes the following to happen:
- Poor and incomplete requirements are captured causing extreme scope creep
- See Shift Happens
- Sub-optimal architecture is built
- Highly defective code is written
- Little quality control is done during testing
- Few, if any, artifact inspections are done
This alone can create a Death March project and virtually guarantee project failure.
Effect of excessive schedule pressure is that productivity will be down 16% and quality will be down 22%
Not only is excessive schedule pressure one of the worst practices it tends to drive the other worst practices:
- Friction amongst managers
- Friction amongst team members
- Increases the chance that key people leave the organization
If your organization has a habit of imposing excessive schedule pressure — leave!
Friction Between People
Software development is a team activity in which we transform our intangible thoughts into tangible working code. Team spirit and collaboration is not an option if you want to succeed. The only sports teams that win championships are those that are cohesive and play well together.
You don’t have to like everyone on your team and you don’t have to agree with all their decisions. However, you must understand that the team is more important than any single individual and learn to work through your differences.
Teams only work well when they are hard on the problem, not each other
Friction among managers because of different perspectives on resource allocation, objectives, and requirements. It is much more important for managers to come to a consensus than to fight for the sake of fighting. Not being able to come to a consensus will cave in projects and make ALL the managers look bad. Managers win together and lose together.
Effect of management friction is that productivity will be down 13.5% and quality will be down 18.5%
Friction among team members because of different perspectives on requirements, design, and priority. It is also much more important for the team to come to a consensus than to fight for the sake of fighting. Again, everyone wins together and loses together — you can not win and have everyone else lose.
Effect of team friction is that productivity will be down 12% and quality will be down 15%
Any form of friction between managers or the team is deadly.
Inadequate Stakeholder Communication
Inadequate stakeholder communication comes in several forms:
- Not getting enough information on business objectives
- Not developing software in a transparent manner
If you have insufficient information on the business objectives of a project then you are unlikely to capture the correct requirements. If you are not transparent in how you are developing the project then you can expect excessive schedule pressure from senior management.
Effect of inadequate stakeholder communication is that productivity will be down 13.5% and quality will be down 18.5%
Loss of Key Personnel
To add insult to injury, any of the other four worst practices above will lead to either:
- Key personnel leaving your organization
- Key personnel being layed off
Badly managed organizations and projects will cause the most competent people to leave the organization, simply because they can more easily get a job in another organization.
When organizations experience financial distress from late projects they will often cut key personnel because they are expensive. The reality is that laying off key personnel will sandbag your ability to get back on track. The correct thing to do is to find your least effective personnel and let them go.
Effect of layoffs/loss of key personnel is that productivity will be down 15.7% and quality will be down 21.7%
The loss of key personnel has a dramatic effect on team productivity and morale and a direct effect on product quality.
Any of the worst practices mentioned above will cause a project to be late and deliver defective code. Even worse, the worst practices tend to feed each other and cause a negative spiral. If you are in an organization that habitually practices any of these worst practices then your only real option is to quit.
The most deadly situation is when there is the following cascading of worst practices:
- Excessive schedule pressure (leads to)
- Management and team friction (leads to)
- Loss of key personnel
If you are in senior management then none of these practices can be allowed if you want to avoid canceled projects or highly defective products.
1Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.