This article fine tunes the development process, focusing on the techniques and strategies that software teams can use to become consistently successful. There are a few principles the software project leads should keep in mind. Among the foremost is the idea that the programmers should be working only on the tasks that either directly or indirectly improve the product. The lead should lead the way by clearing the way of any foreseeable obstacles. Any work that interferes with progress, should be shield ed from the development team. To make it easy to determine which tasks are strategic and which are wasted effort, leads should identify detailed project goals and priorities. The more detailed the goals and priorities are, the easier it is to spot wasteful work. Only when the leads are clear about what they and their team should be doing can they fulfill the project's needs with the least amount of effort and frustrations.
The simple formula for software development is : figure out what needs to be done and how it should be done, and then sure that every team member stays focused on the projects goals, coding priorities and the quality bars that the lead have come up with. Simple work systems can produce dramatic results. As the systems are put in place, explain the purposes behind them so that the development team can understand what aspect of the product the systems are meant to improve. To elicit the best strategies for working effectively, leads should pose the problems they are trying to solve in increasingly refined questions. Leads should also develop the ability to ask precise questions to increase the quality of the answers. The development team should also be reminded that even the best strategies do not apply to every situation. Leads are to incorporate negative feedback loops into the strategies they develop, but be sure to consider the side effects and the long term effects. The best feedback loops enhance the desirable aspects over time while simult aneously reducing the negative effects.
To keep a project on course and running smoothly, a lead must constantly monitor the project, looking ahead and taking care of problems while they are still small. By seriously looking ahead of the team for problems that can derail the project, a lead can foresee all sorts of problems that can blindside the project. To prevent wasted effort, a lead should assess every request in order to identify the real problem or goal and should be sure that every task fulfills the project's goals and priorities.
The lead must create a development environment that fosters the kind of enthusiasm if he wants the software development team to go on a creative roll. The lead should work to eliminate unnecessary reports and meetings and other corporate processes that hinder the development effort. If a meeting is necessary, schedule the meeting so it does not break up an otherwise large block of time. And when a meeting is called the lead should be sure ahead of time exact ly what he wants to accomplish, and make sure that it is accomplished; remembering that conditional decisions are better than no decisions. If programmers are given the opportunity to work unhindered by overblown corporate processes, they have a much better chance of catching a creative wave and moving the project forward. However, postmortem reports are invaluable when they are done correctly. Postmortem should explain exactly how the known problem can be fixed or exploit known improvements. The critical point is that leads should always work to address their actual rather than formal needs.
In most companies, the development teams needs to maintain a schedule so that groups in the company can coordinate their work with the programming effort. But as important as schedules are for coordinating the work of various product teams, they can have a devastating effect on development on development if they are not devised and used wisely. A schedule that is too aggressive will lead to slip hysteria, in which programmers t ake short-cuts to meet the schedule in the short term, jeopardizing the product in the long term. By using project milestones instead of task lists to schedule, the lead can shift the focus to completing subprojects, which creates "wins" for the team and emphasizes progress. The schedule should be aggressive enough to keep the project running at a brisk pace. If the schedule is too aggressive, programmers will make stupid decisions despite their better judgment. Any programmer who has decided that he does not have time to thoroughly test his code is guilty of putting the schedule ahead of the product.
Leads should streamline the development process to a point at which every team member is focused only on strategic work. Leads should also focus on training so every team member is regularly learning a wide variety of broadly useful new skills. A team member should never be allowed to stagnate by limiting him or her to work on one specific part of the project. When training the team members , maximize their value to the company by first training them in the most widely useful skills and save the project-specific skills for last. By ensuring through work assignments and overt educational goals that programmers actively learn new skills, leads help the project and the company and advance the programmers' careers. To ensure that the skills of the team members are expanding on a regular basis, the lead should see to it that every team member is always working on at least one major improvement goal. The best growth goals emerge from a strong, immediate need. Because such on-the-spot goals lend themselves to immediate action for a definite purpose, the programmer is likely to give them more attention than he would give to abstract goals devised for an annual review.
Most impressive results can also be obtained by focusing the team members on correcting harmful attitudes and promoting beneficial ones. The lead should watch out for the "its too much work" and "its too hard" reflex actions. And ask if the programmer considered whether the task was important and whether it matched the project goals and priorities. If he or she is responding reflectively, try to refocus the person to the merits of doing the task so he or she can evaluate the idea freshly and fairly. Programmers should be taught to view the product as a end user would, that everything goes into the box as a single product. The lead should take advantage of the principle of leverage by using it whenever possible. Leverage is how a little well-placed effort can yield a much greater return. If a project start s to slip, the natural tendency is to hire more people and to get the team to work longer working hours. One person might work far fewer hours and produce more than somebody who work twice as long. The lead needs to determine the causes to protect the pr ogrammers from their own and upper management's assumptions of the tonic effects of long hours. People should be praised for working well, not for the number of hours that they are in the building. Hiring more people or demanding long hours only masks t he problems affecting the project. Leads should find and fix the problems, not cover them over.
Adapted from "DEBUGGING THE SOFTWARE DEVELOPMENT PROCESS" by STEVE MCGUIRE (Microsoft Corpn.)