A paradoxical scenario plays out all too regularly in a good number of software development studios. The organization hires great developers who have done great things in the past and put them on a project only for them to woefully fail.
Before you go on and judge the team as incompetent perhaps its time to look inward and see maybe the teams fail because of your own managers and the systems under which the developers work in.
In this entry we will be looking at some of the most common ways that software projects fail owing to process failures.
Knowing exactly what is to be built plays right into our need for control. Control over the budget, over the schedule and the time. For all but the most trivial projects, this endeavour is doomed to fail. The reasons for this inevitability are varied, I have previously talked about it in One design to rule them all.
Thankfully the industry has elegantly solved this problem. The answer lies in agile software development. In agile and its practises (XP, Scrum) you don’t need to know everything. You leave room for flexibility as your team knows more and more about the project. See Scrum in 4 easy steps.
Negative peer influence
Throughout our formative years we were warned of this beast called peer pressure. Usually was related to drug abuse, teenage pregnancy, crime and all other decadence of youth.
Yet in our professional lives peer pressure is still as real and even more powerful.
The truth is, the opinion of the group will more likely be shaped by the loudest mouth around. This can negatively affect productivity of your most valuable team members especially if they are the silent type. In case you are wondering a good number of developers are the silent type.
To overcome this kind of peer influence. You need to ensure that your decision making process actively defends against it. An example would be by using anonymous feedback mechanisms and acting quickly to discipline errant members.
It is natural for team members to feel closer to each other as compared to the other members in the organization. This tendency however can rapidly degenerate into lack of respect or even worse outright hostility between teams.
To beat silos you need to encourage cross team collaboration in a way that highlights the strengths of the team. Self organizing teams working in flat hierarchies are the ones most likely to deliver this kind of collaboration.
Vendor lock in
It’s very easy to get tied into a particular vendor products especially when the products initially boost your production speed. When this happens you lose agility and are forced to build your products around what the vendor allows you.
Some level of commitment will obviously be needed to make any progress but ensure to have done proper due deligence and design your own solution in such a way that the dependency is clear. See Hexagonal architecture.
By and large developers are smart people. Left to their own means they will come up with the most complex design possible for the particular problem you are trying to solve.
Unfortunately the cost of implementing the design may just not be worth it especially for smaller projects or on the onset when the product is not yet clearly defined.
A close cousin to over engineering is gold plating. In this case, the developers put in extra features in the hope of impressing the boss or the client.The strategy largely fails as the client will either be confused by the cruft or refuse to pay for the time used to develop it.
Documentation is critical to a successful product. Over documentation however steals valuable developer time. It is also worthwhile to note that end users expect the product to be simple enough to use without referring to any documentation.
Invest in good UX to mitigate the need for more documentation, let the product and the code self document. See Name well or go home.
On project onset you likely have months to get the work done. In this cases procrastination sets in
Then towards the end of the project the developers are suddenly on fire working 100 hour weeks to get the project done. This is an unhealthy practise that leads to a phenomenon called the Death March.
The death march is an unfortunate situation where everyone in the team knows the project is headed for failure but continue on anyways.
To deal with this, work needs to be done in defined time box. Scrum allows for this by the practise of arranging work in sprints.
Believe it or not super developers are not good team members. The reason is the rest of the team starts blindly trusting on the developer’s super human technical ability to get things done.
Very quickly, this developer will turn into a bottleneck for the entire team grinding work to a halt.
In addition the reverence paid to the super developer may mean you miss out on the creativity of the rest of the team as they wait for all the answers to come from the one person.
If in this situation the best course would be to ensure the super developer shares their knowledge with the rest of the team.
Poor communication strategy
The best way for humans to communicate is face to face period. Using email as the primary means of communication means a lot of the nuances get lost in translation.
In case you run a distributed team, try create an environment that imitates a co working space as much as possible. Tools like slack and hangouts are perfect for this task.
Bad managers come in many forms. The most common being the micro manager and the hands off manager. Both types of managers are bad for the team.
This types of managers drain the energy from the team and suppress their creativity.
Again agile techniques with the concept of self organizing teams and natural authority come into play. Here you let the team be responsible for its own success and let positive peer pressure work for you.
Have any of the factors mentioned above affected your projects? Tell us in the comment section below.