Where Do Practices Come From?
The idea of practices is not a new one. Practices have always existed in software development and, it seems, that every software development company in the world promotes its own set of "best" practices. However, no one has taken the time to define exactly what practices are or how to describe them in a sensible, reusable way. The reality is that there are hundreds of practices available for us to choose from, if only we could separate them from one another, understand the benefits they offer, and know when they should be used.
In the software development community, practices—like processes—usually come from one of three prominent camps:
- Software engineering, which includes the Unified Process, Booch, OMT, Responsibility-Driven Design, Shlaer/Mellor, User-Centered Design, Open, and Feature-Driven Development, among others.
- Process assurance, which includes CMMI, SPICE, Six Sigma, and TSP/PSP.
- Agile, which includes XP, Scrum, Crystal Clear, Adaptive Software Development, and Organizational Patterns of Agile Software Development.
Many of these tangle together a number of (and sometimes share) practices. For instance, Scrum is a practice that is already presented in a separated and reusable fashion—as a management practice for the planning and execution of iterative projects. It is completely independent of the engineering and other practices that a team is going to use. This separation and the ability to mix-and-match Scrum with other practices is one of the reasons it has proven so popular and been so widely adopted.
Compare this with how iterative project management has been traditionally presented in the Rational Unified Process—as a tightly coupled, inseparable part of a much larger process that doesn't seem to be usable without the Unified Process lifecycle, use cases, components, or a strong focus on architecture. This has always made it almost impossible for customers to take the practices they want without having to take all of the other practices as well.
Thus, there are many places where you can already find practices: There are many well-formed practices already available, there are many practices embedded in existing processes, and there are many tacit practices experienced professionals communicate by coaching and example.
A good place to look for well-formed practices is in the way that training is presented and processes rolled out. The normal way to train people is one practice at a time. This is also the way that most successful process rollouts are undertaken.
Practices evolve from people doing their jobs and sharing their experiences. What we need is a better way to capture and share these practices, one that avoids "religion" and self-promotion, allowing each practice to stand on its own.
So in the future, instead of having experts contributing yet another process, they would contribute separate and distinct practices. Each practice will be complete and help teams drive their projects forward.
