"The greatest risk we face in software development is that of overestimating our own knowledge." —Jim Highsmith,Adaptive Software Development, page 14
In his most recent book, Jim Highsmith takes an alternative approach to managing software projects, saying that adaptability is much more important than a repeatable process. "CMM," he says, "is a workflow model, based on the belief that complex products can be effectively attacked by breaking a large process into ever-more-refined subprocesses...The secret to managing complex adaptive projects is to apply increasing rigor to the results, not to the process."
If you are working in an environment where there is tremendous pressure to ship quickly, and where change happens constantly, then you may have seen some successful projects emerge from very fuzzy beginnings. Highsmith has suggestions for creating a project environment that not only helps people live with those fuzzy starts, but also helps people create a project and a product of which they can be proud. One of his suggestions is the use of iterative lifecycles. In Chapter 4, he discusses iterative lifecyles, along with mission-driven, component-based, time-boxed, risk-driven, and change-tolerant, which are all characteristics of adaptive lifecycles.
Many of us become great at only one type of development, and don't know how to do other types of projects. I've met many project managers who understand how to create a new product but don’t know how to then do iterative development on several point (or minor) releases afterwards. To be truly effective project managers, we need to see what this project's requirements are, and adapt our development activities to meet those requirements.
In addition to the lifecycle discussion, Highsmith includes eight guidelines for applying rigor to project work. He focuses on how to make the collaboration between groups work, not on how to make each group work better by itself. This part shouted at me: Break down the silos!
One of the eight guidelines is "Increase rigor on components from the outermost boundary crossings first, and then work inward." If you become more rigorous about the handoffs between groups, and then between people, and lastly within one person's scope, you will increase the quality of the project's work. You could define milestones that everyone can then work toward for the project. Or, if you decide just to inspect all product fixes after the "code complete" milestone (whatever you use to define the end of development, and the start of only test/rework), then you’ve worked on creating more rigor between people.
In my experience, management is the most critical component of a project and the hardest to change. I particularly enjoyed Highsmith's discussion of how some managers, stuck in command-and-control, have a static view of the world, which prevents them from making sense of their current environment.
Adaptation is a necessary and critical skill of competent managers. The book contrasts traditional commandand-control managers with leader-collaborator managers—those managers who learn how to make sense of the world, even if it doesn't conform to their well-understood beliefs.
Highsmith shows the reader how to recognize when development practices need to change and how to acquire the skills to adapt. For a fresh approach to software development, be sure to check it out.