What Kinds of Practices Are There?
As you might expect, there are practices to address all the different areas of software development and team working, including:
- Software engineering practices. Practices for developing components, designing user interfaces, establishing an architecture, planning and assessing iterations, or estimating effort.
- Social engineering practices. Practices on teamwork, collaboration, or communication.
- Organizational practices. Practices on project milestones, gateway reviews, or financial controls.
In time, all of these practices will be made available plus many more. Figure 1 illustrates a selection of the practices we would expect to be available in the future. Some of the practices will be complementary, such as Scrum, pair programming, and use cases. Others will be competing with each other, such as use cases and user stories.
Figure 1 also shows that there are technical and crosscutting practices. Technical practices deal directly with the production of the software or the other artifacts (such as requirements) needed to support the development of the software.
Crosscutting practices are subtly different. Rather than focusing on the method you use to produce the software (such as iterations, use cases, and components), these practices address the softer side of software development (such as pair programming, team working, and communication). They don't directly describe how to produce software, but fundamentally affect how the team works and how the other practices are applied.
Many popular software development practices, especially the kind of social engineering practices promoted by the agile community, are crosscutting in this way. The ability to capture and compose both technical and crosscutting practices lets us address all aspects of software development in a simple, scalable, and extensible fashion.
Figure 1 also shows a selection of peer practices and extension practices. The peer practices are full-fledged practices that can be applied separately and offer direct value to teams and their customers.
Extension practices build on peer practices to make them more scalable by addressing specific risks or adding complementary techniques. Teams will start by selecting the peer practices they need to drive their work, then add any other peer or extension practices as needed to scale up their way-of-working. The best kind of peer practices are those that focus on the essential elements of the practice, and leave the corner cases and specializations to be handled by other extending practices. This keeps the peer practices lightweight and agile, and prevents teams from inadvertently adopting practices that are more complex than they need to be.
The great thing is you only need to use the practices that you want. If you think existing management practices are a waste of time, then you leave them out. By only drawing on the practices that you need, you can assemble the right way-of-working for your team, project, and organization.
What Makes a Good Practice?
A well-formed practice addresses a specific aspect of software development or teamwork. A practice provides guidance to characterize the problem, the strategy to solve the problem, and instructions to verify that the problem has indeed been addressed. It also describes what supporting evidence, if any, is needed and how to make the strategy work in real life.
Put simply, practices describe what to produce, how to produce it, and the competencies needed to perform the practice. Practices also provide patterns to tailor and tune their use. The use of patterns allows practices to describe things such as appropriate work patterns (for example, collocated teams, distributed teams, or virtual teams) and ownership patterns (common ownership or ownership by component). Applying the patterns easily allows a team to adapt the practices to their specific needs.
To be a well-formed practice—one that can be applied safely and consistently—a practice must verify itself. So if a practice describes how to write code, it must also describe how to test it. Or if a practice describes how to capture requirements, it must also describe how to verify that the system produced meets these requirements. If the practices don't do this, then their ability to be applied successfully is compromised. This need for practices to include their own verification can be seen in the initial set of practices that we have developed to demonstrate and prove our approach.
If you examine the set of practices in Figure 2, you will see that there is no testing practice. This is because testing is an integral part of all the technical practices. For example, the component practice takes a test-first approach, developing unit tests before the components are developed.
Together, these eight practices form the Essential Unified Process (EssUP), a lightweight version of the Unified Process. EssUP includes the five technical practices found in all Unified Processes, and some new crosscutting practices that draw on other areas of experience such as CMMI and agile methods. (For more information on EssUP, see our article "The Essential Unified Process," DDJ, September 2006; www.ddj.com/dept/architect/191601687.)
These practices can be applied separately or in concert with one another. Many teams are already using these practices. They all use different combinations and mix these practices with their own existing practices. Figure 3 shows how the EssUP practices can be mixed and matched with other practices to support different teams and objectives.
This initial set of EssUP practices is designed to focus on the essentials of each practice—ensuring that they are lightweight and compatible with agile values and thinking. If more rigor, ceremony, or documentation is required, then additional extension practices can be added. These extension practices build on the essentials to address specific problems and areas of risk.
