There are many ways for software development teams to fail. That’s why retrospectives are so important. Learning from mistakes, your own or those of others, is one of the best ways to improve.
Last year I posted “10 Reasons Why Projects Cascade Into Chaos”. This is such an important topic that I want to expand on that list here. Learn what not to do and the path to success becomes clearer.
Here are 10 traps that snare even the best software teams.
1. Missing the mark on customer needs.
At times, we get so caught up in software technologies, features and functions that we lose sight of what the end users really need from us. If you meet the customer’s most important needs, her tolerance for missing features and small defects will increase. If you don’t, you’ll fail.
2. Mismanaging customer expectations.
Once you understand needs, it’s time to start managing expectations. The final deliverable may not satisfy every need. The proposed solution may be lacking in some respects. Keep those expectations reined in and strive to exceed them!
3. Creating a leadership void.
In agile software development, we emphasize teamwork and collaboration while downplaying the role of managers. That’s fine, but don’t take the concept too far. Great teams need great leaders to encourage the teams to perform at their best. This can be someone on the team like the Scrum Master or technical lead. It can also be someone affiliated with the team like the Product Owner or a stakeholder.
4. Using inadequate software tools.
I’ve seen companies pay their software developers a lot of money then balk at spending $10,000 for a development tool that would improve productivity and quality. I know money comes out of different budget buckets but don’t expect great results when the tools are mediocre.
5. Not sharing information.
The number one purpose of daily standup meetings is to share information. In addition, use whatever means you have available including private blogs, forums and microblogging platforms to get information out into the open for everyone to use.
6. Using metrics improperly.
I’m a big fan of metrics and I know that they can be seriously misused. Metrics that are too detailed are subject to abuse. People learn how to work the system to their advantage. For example, lines of code are easy to manipulate. The best metrics are fairly high-level and focused on outcomes or end results. These are much harder to manipulate. Detailed metrics should be used only temporarily to address a specific problem area.
7. Abandoning the plan under pressure.
Planning is hard work. Plans need to be adjusted along the way as new information becomes available. If your plan isn’t working, revise it. Don’t ignore it or toss it. You’ll end up working without a plan and who knows where you’ll end up!
8. Falling victim to multitasking.
I’ve said it before on this blog and it bears repeating — humans cannot multitask. We can switch contexts giving the appearance of doing two things at once but productivity and quality suffer. Is that what you want?
9. Reinventing the wheel.
Many software teams have a strong bias toward writing all of their own code from scratch. Yet there are many frameworks, libraries and open-source artifacts available to them. It’s worth a little time to research what is available, what has been done before, and what can be reused.
10. Playing time games
These are desperate tactics that take many forms: Managers who demand longer work days and/or weekend work time; Teams that add new members late in the project expecting the new person to “hit the ground running”; Or, adding new procedures that make it difficult for anyone to introduce changes or request assistance (“…you need to fill out form 17263 in triplicate and get it approved”). Stop the games.