|
When processes can't cut it, practices offer an alternative.
April 05, 2007
URL:http://www.drdobbs.com/architecture-and-design/enough-of-processes-lets-do-practices/198800543
Ivar is one of the "fathers" of components and component architecture, use cases, UML, and the Rational Unified Process. Pan-Wei and Ian are chief scientists at Ivar Jacobson Consulting. The authors can be contacted at www.ivarjacobson.com.
As we saw in the first installment of this multipart article, there are many problems with the current generation of software-development processes—denied commonality, incompleteness, out-of-sync processes, knowledge acquisition, and down-right stupid processes, to name a few. No wonder most developers don't like processes.
The good news, however, is that there is an alternative—practices, and there are hundreds of them. Some are generally accepted, others are unique to a particular methodology. But they all have something to offer, even though they can be hard to mix-and-match or use together. In our new approach, which we call "EssWork," these practices can be defined separately, and then composed into a simple ways-of-working where they are applied together. This allows teams to select the practices that they want, which are then assembled to describe their individual way-of-working.
In this installment, we examine what makes a good practice and identify the benefits of adopting a practice-based approach.
A "practice" provides a way to systematically and verifiably address a particular aspect of a project.
It is important to note that:
Because of these qualities, practices can be developed, learned, and adopted separately, and they can be used in conjunction with other practices to create easily understood and coherent ways-of-working.
In short, a practice is a proven way of approaching or addressing a problem. It is something that has been done before, can be successfully communicated to others, and can be applied repeatedly to produce consistent results.
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:
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.
As you might expect, there are practices to address all the different areas of software development and team working, including:
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.
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.
Every process can typically be considered a collection of typically tangled and tightly coupled practices. Once existing practices are separated, methodologists can focus on capturing best practices in a reusable and extensible format without repeating or replacing existing practices.
Treating processes as collections of practices fundamentally changes the role of the processes. They just become a short-hand way of referring to a known set of mutually supportive practices, and their adoption acts as a useful starting point or goal for projects.
Instead of learning or adopting an entire process, practitioners learn about individual practices and adopt these practices incrementally to improve their way-of-working. First, they select the most appropriate practices to address their needs and help them cope with the challenges of their current situation. Then, they adopt these practices in whatever combination and at whatever speed suits them. Most importantly, they add new practices to their existing way-of-working without changing everything or throwing away the practices they already know.
If they want to, teams can start afresh with a new way-of-working, but experience has shown that it is more effective to transform the way-of-working one practice at a time. When it comes to process improvement, a big-bang approach doesn't work. Trying to change everything, all at once, is a high-risk strategy. Even if you want to move to a totally new way-of-working, it is easiest and safest to do it one or two practices at a time. This minimizes the disruption caused by changing working practices, and provides a focus to the coaching needed to embed the new practices in the team. It also allows you to directly address your problem areas without having to change the practices that are already working well.
In the future, you will combine practices from many sources to create the way-of-working you need. Rather than talk about the process you follow, you will talk about the practices you use. If someone tells you about a new practice, you will be able to try it without affecting the practices that you are already using. You will even be able create and develop your own practices, then blend these with standard practices to create truly new and innovative ways-of-working. You will not be tied to any one process camp or ideology; you will be able to mix-and-match practices from any source to continuously improve and tune your way-of-working.
In the final installment, we describe the innovations needed to make a practice-based approach really work, and how EssWork can help teams realize their investments in learning, developing, and documenting best practices.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.