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.


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.




Agility and Discipline Made Easy(c) Practices from OpenUP and RUP
Agility and Discipline Made Easy: Practices from OpenUP and RUP
ISBN: 0321321308
EAN: 2147483647
Year: 2006
Pages: 98

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net