Category list

Chapter 8. Making Practical Use of the Best Practices

You have hopefully been inspired by a number of the best practices in this book. You may have picked up new ideas on how to develop software more effectively and had a chance to reflect on opportunities for improvements within your team. But how do you actually use these practices? Which practice should you adopt first? Should you adopt the practices one at a time, or should you adopt many at once? On what type of project should you adopt your first practices?

This chapter aims to answer these and other questions related to adopting the practices described in this book.

Which Practices Should I Adopt First?<title/>

Introducing a practice is an investment.

The reason for introducing a best practice into your organization is to obtain business benefits measured in improved project results. Introducing a practice is an investment. As with all investments, you need to make a business case with a return, such as, higher-quality , lower cost, and/or shorter time to market.

To determine which practice(s) to adopt first, create a shortlist of problems to fix.

You can choose many different starting points for adopting best practices, and most of them will provide you with value (see Figure 8.1). But are some better than others? To determine which practice(s) to adopt first, you need to create a shortlist of problems that you need to fix. This can be done using either of the following two approaches. The first approach is to walk through the problem statement for each practice and see which problems resonate with you. Do you experience the problem described? If you do, put the problem and the related practice on the shortlist.

Figure 8.1. There Are Many Roads Leading to Good Results.

Most practices will provide you with benefits, but some will have higher pay-offs than others. You need to decide what your end goal is and then determine the best way to get there.

The other approach is to consider the issues your team has faced in the past and assess their impact on your business. If the impact is big, write the problem down. This book contains many practices, so to help you to find the practices that fix problems in a certain area, we have organized them around key principles. If you are trying to find a cure for a specific problem you are experiencing, review the principles to see which one(s) are the most relevant. Then go through the practices for the relevant principle(s) and put them on your shortlist.

Once you have a shortlist of relevant problems and related practices for your project or organization, the next step is to identify the value of fixing them. If it is hard to attach real numbers to the value of fixing individual problems, articulate their relative value. After a while, you should have a prioritized list of practices to adopt.

But what if you are doing fine, but there is a drive to "do better"? You can use the same approach as described above to identify the practices to adopt first, but with a more positive spin. Rather than looking for problems, you are looking for opportunities for improvements.

Will you ever be "done" adopting practices? We will answer that question in the next section.

Start with the Basics

For each of the practices, the "levels of adoption" describe basic, intermediate, and advanced adoption (see Table 8.1). When adopting a practice, start with the basic level, gain some familiarity and success with the basic practice, and then consider whether a more advanced adoption makes sense.

Table 8.1. Summary of Practices by Adoption Levels.

Each practice can be adopted at the basic, intermediate, and advanced level. Choose what practices to adopt at what level based on the needs of your project.
#	Practice Name	Basic	Intermediate	Advanced
1	Manage risk.	Decide what risk to address in each iteration.	Update risk list and make visible.	Use risk management tool and traceability.
2	Execute your project in iterations.	Deliver incrementally. Replan based on feedback.	Plan iterations based on risk.	Use mini- and super-iterations
3	Embrace and manage change.	Do partial implementation. Keep documentation simple.	Use Unified Process lifecycle. Refactor. Manage change.	Automate change management and use CCB.
4	Measure progress objectively.	Measure and re-estimate each iteration.	Chart progress.	Automate measurements and record in a database.
5	Test your own code.	Use coding guidelines and standards.	Developers actively test their own code.	Formally inspect code. Use static, structural, runtime analysis, and performance test tools.
6	Leverage test automation appropriately.	Provision each test machine.	Create automated test suites.	Automate stress and performance testing.
7	Everyone owns the product.	Openly share info . Evaluate 10% complete work.	Cross-functional collaboration. Assess progress through working code.	Use scalable collaboration platform and enterprise architecture.
8	Understand the domain.	Include customer in project, and use a glossary.	Visualize a domain object model.	Leverage business rules and business process modeling.
9	Describe requirements from the user perspective.	Identify scenarios.	Capture use cases, and link scenarios to use cases.	Chunk use cases into separately managed requirements. Continued Practice Name Basic Intermediate Advanced
10	Prioritize requirements for implementation.	Prioritize most essential requirements for each iteration.	Balance priorities of architecture, business, and customer.	Systematically manage requirements categories and attributes.
11	Leverage legacy systems.	Ensure continuous improvement of systems in maintenance.	Plan incremental improvement.	Establish long- term enterprise vision and plans.
12	Build high-performance teams .	Clearly communicate project vision and responsibilities.	Establish trust, encourage constructive feedback, and communicate openly.	Couple performance evaluations to established values.
13	Organize around the architecture.	Organize around features. Architect oversees architecture.	Organize vertically and horizontally. Approve architectural changes.	Formalize changes through an Architecture Control Board.
14	Manage versions.	Manage version-controlled files Manually manage change sets.	Set up isolated workspaces, with activity-based delivery.	Share version-controlled components across products.
15	Leverage patterns.	Learn patterns and provide examples.	Use reference architectures and document patterns with UML.	Use pattern automation and enterprise-wide patterns.
16	Architect with components and services.	Apply component and service design principles.	Model components, services, and interfaces.	Create detailed component and service specifications.
17	Actively promote reuse.	Common templates/representations, form communities.	Educate on available assets.	Fund creation of assets.
18	Model key perspectives.	Use informal sketching.	Document UML architectures.	Use model-driven development.
19	Rightsize your process.	Decide on process to use as you go.	Document the process you use.	Improve the process after each iteration.
20	Continuously reevaluate what you do.	Each person assesses his or her own working procedure.	Do iteration reviews and retrospectives.	Centrally coordinate process improvement.

The goal should not be to adopt the advanced practices on every topic.

The goal should not be to adopt the advanced practices on every topic. Basic adoption suggests that the practice can be adopted with a smaller effort, or by people with less advanced skills. Because they require low investment but offer high potential for results, these basic levels are usually worth adopting. Advanced adoption means more investment and complexity in applying the practice, usually involving a higher cost; therefore, there is a greater burden to make sure that a particular project needs to take on this cost. Figure 8.2 shows the relative cost (investment) of sample practices and their relative value by adoption level. The gradient indicates the return on investment (ROI), with a steeper gradient indicating a higher return. In this example, practice A and B have a higher ROI for adoption of basic levels than for adoption of intermediate and advanced levels, whereas practice C has a lower ROI for adopting basic than for adopting intermediate and advanced levels.

Figure 8.2. Relative Cost and Value by Practice Level.

For each organization, each practice creates a unique cost-value profile. Some practices make more sense to adopt than others. In most cases, as you move to higher levels, the relative cost increases , while the relative value decreases. Thus, each organization needs to assess whether the optimal level for each practice is basic, intermediate, advanced, or none.

A smaller project that wants to follow a low-ceremony process would apply the most basic or intermediate level for most practices. However, the advanced level does not always mean more ceremony or overhead. It may instead indicate that you need a higher degree of skills, or more advanced tooling. As an example, adopting advanced change management practices may allow you to work with a minimum of ceremony, because the tools handle all the bookkeeping. Use the symbol associated with each practice level to understand how the practice relates to the process map.

As your team adopts a practice, commit to using the practice for a certain number of iterations and then review the results to see whether you want to continue. Some practices may take some time to get right, and giving up after one iteration typically does not allow you to learn the practice well enough to assess its usefulness properly.

Create a short-term plan for how to improve over the next iteration or the next few months.

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

One approach we have found very useful when doing process improvement is first to assess how well we are doing today. This assessment should involve all team members , so that they (1) get a sense of ownership of the assessment results and (2) buy into them. Second, have the team agree on where they would like to be in the future. Choose a time line that is beyond any immediate deadlines, but not so far away that it becomes irrelevant to what you are doing today. It is often good to have a roughly one-year horizon. Lastly, do a short-term plan for how to improve over the next iteration or the next few months. Do not have a horizon longer than three to six months, or you will not take any immediate actions. Table 8.2 provides an example using the practices in this book as a driver for your process improvement effort.

Table 8.2. Example of a Process Improvement Plan.

This plan has been produced in three steps. Step 1 is to assess how well the team is doing relative to a practice. Step 2 is to have the team agree on what is a desirable end goal. Note that the team may choose never to adopt some practices, or to adopt them only at a basic or intermediate level. In Step 4, the team produces a short-term plan for what to improve in the next three months.
#	Practice Name	Where Are We?	Where We Would Like to Be	Short-Term Plan
1	Manage risk.	Basic	Intermediate	Key focus. Couple with Practice 10.
2	Execute your project in iterations.	Intermediate	Intermediate	N/A
3	Embrace and manage change.	Basic	Advanced	Key focus. Manage change request more effectively.
4	Measure progress objectively.	None	Intermediate	Not a focus now.
5	Test your own code.	Basic	Advanced	Key focus. Apply test-first design.
6	Leverage test automation appropriately.	Intermediate	Advanced	Good if we can improve. Send Karen on training course.
7	Everyone owns the product!	Intermediate	Advanced	Not a focus now.
8	Understand the domain.	Basic	Intermediate	Start by using a basic domain object model.
9	Describe requirements from the user perspective.	Intermediate	Intermediate	N/A
10	Prioritize requirements for implementation.	None	Intermediate	We need to involve our customers and architect in prioritization work.
11	Leverage legacy systems.	None	None	N/A
12	Build high-performance teams.	Basic	Advanced	Not a focus now.
13	Organize around the architecture.	None	None	N/A
14	Manage versions.	Intermediate	Advanced	Focus. We must do a better job on parallel development!
15	Leverage patterns.	Basic	Intermediate	Deploy tool with patterns and get mentor to assist.
16	Architect with components and services.	None	Advanced	Not a focus now.
17	Actively promote reuse.	Basic	Intermediate	Not a focus now.
18	Model key perspectives.	None	Intermediate	Not a focus now.
19	Rightsize your process.	Basic	Advanced	Download EPF and check it out. Jane
20	Continuously reevaluate what you do.	Basic	Intermediate	Have Ken run retrospectives for each iteration.