In-Depth
6 Tips for Productive Software Development in a Tough Economy
Software development teams face fewer resources, shorter schedules and smaller budgets to get the job done. But even in these difficult times, project managers can employ several strategies--some at no cost--to increase efficiency and quality. Here are six development strategies that have proven benefits whether you work on agile teams or traditional waterfall teams:
1. Work in iterations. In traditional waterfall development, teams move through different phases in a rigorous fashion; a process that is almost guaranteed to cause mistakes. Problems can result from not anticipating business changes; unexpected feedback from users who are unhappy with feature implementations or clients simply changing their minds. Even in a waterfall methodology, work in approximately one month iterations – even in the design stage. Set goals for the team for each iteration such as "the team will complete 5 of 30 requirements in this iteration". This lets you know, every 30 days, whether the project is still on target and the effects of changes on the overall schedule.
2. Use technology to eliminate manual work where it speeds up the process. This one may be a bit controversial for agile teams but it makes sense in any organization of size where information must be communicated to people in multiple locations. Task boards may work for the dev team, but not for stakeholders who need to know the status of the project. A number of tools can help; I'm partial to Team Foundation Server if your team is developing in either Visual Studio or Eclipse. This saves time because you don’t have to re-enter data or consolidate everything into a few reports; you can spend more time dealing with and fixing problems. It's also easier for the developers on your team because they don’t have to walk over to your desk or fill out forms after the fact explaining what they did; they can use tools that are already integrated into their dev environment. Another benefit is more accurate information about the project's status because the reporting is usually done when the developers are actually doing the work.
3. Communicate frequently and honestly with customers. No, I'm not saying that project managers intentionally lie to their clients. But what does tend to happen is they do not tell clients everything. For example, you may tell the client that there were some bugs found in one of the requirements and it will take the team a bit longer to fix it. But what if the reason for the bugs is because the design was wrong, do you tell them that? Many times we try to hide the "unnecessary" details from the customer. Trust me ¬-- you do not want to do that. If you do, it becomes much more difficult to have the conversation later on when there is a second or a third delay because the magnitude of the design defect keeps growing. Lay it all out on the table for better or worse. If you do then customers are much more willing to a) trust you and b) listen to what you have to say when you tell them that there will be a slip in schedule for whatever reason because they know that you aren’t holding anything back. And if you are working in one month iterations, you should be communicating status to the customer no less than once a week.
4. Let developers interact with customers. I can’t say how many times I have seen this misguided approach to software development. A rule gets put in place that only business analysts, architects and project managers can communicate with the client or end users. This leads to a situation that can be summed up in one word – operator. Did you ever play telephone tag when you were a kid? One person whispers a sentence to another who tells it to another and so on until it gets back to the original person. Only when it gets back to the original person, the original meaning is completely mangled, which causes hysterics. This is where agile teams really excel – they remove blocks to communication. Adopt this practice in waterfall projects.
5. Do team building with geographically distributed developers. If you have the budget, organize team activities. It’s best if you can fly teams to one. The time and money spent on this type of interaction will help build relationships that increase efficiency and communication. Barring that, get photos of the team and post them with names and biographical information at all of your development locations. Set up video conferencing, so teams can see each other. Do anything and everything you can to build friendships among the geographically distributed team; it will yield benefits in every aspect.
6. Require automated builds, nightly builds are better. What do automated builds have to do with project management? Automated builds surface problems early and often; especially when software requires integration between multiple components and multiple teams. Frequent build breaks are indications of problems. Examine code churn metrics and automated test results that should run as part of the build. All of these contribute to higher quality software with minimal work. This allows you as a project manager to get some objective measures of quality and do proactive risk management of the software code.
Running successful development projects is all about risk management. The tips presented here can help you take proactive steps to minimize risk. Working in iterations provides quick feedback – waiting until the end of the project is too late. Manual processes take more time and are prone to errors. Communicating frequently with customers improves the relationship and allows customers and the development team to respond to changes when they occur rather than weeks later. Improving the flow of communication to developers removes mistakes in the communication chain and increases the speed at which information flows. Team building improves relationships and communication among the development team. Nightly builds surface problems early and often so that you aren't finding out about them late in the process when you should have known earlier.
Implementing these tips is not as difficult as you may think but in some environments it definitely requires a cultural shift. People may give you some resistance when you try to implement changes, but can they offer good reasons to keep the status quo? Processes that decrease efficiency need to be improved otherwise teams will not be able o keep up with the pace of business. And that’s what really matters.