It’s possible that some of the projects your group undertook in the past were less than completely successful. Even on successful projects we can often identify things we would do differently next time. As you embark on your new leadership role, take some time to understand why earlier projects have struggled and plan to avoid repeating the same mistakes. Software managers don’t have the time to make every possible mistake on their own. Jump-start your own success by learning from what has worked—and what has not—before.

Begin with a non-judgmental assessment of the last few projects your group undertook, whether successful or not. Your goal is not to allocate blame but to do a better job on future projects. Conduct a retrospective to learn what went well and what could have been done better. (See Chapter 15, for more information about retrospectives.) Lead the team in brainstorming sessions or use an impartial facilitator to analyze each current project in the same way at major milestones.

In addition, become well acquainted with established software industry best practices. A good place to start is with Part III of Steve McConnell’s Rapid Development (1996), which describes 27 such best practices that apply to many projects and situations. Also beware of repeating the 36 classic software development mistakes McConnell describes. Your team members may resist new ways of working, but your role as leader is to ensure that the team consistently applies the best available methods, processes, and tools. Actively facilitate the sharing of information among team members so local best practices can become a part of every developer’s tool kit. See Chapter 14, for more about best practices and lessons learned.