The purpose of this page is to illustrate our approach to software process improvement and process change management.

We use a basic roadmap for change management, which comprises five streams across four phases. The specifics of a given process, method, technique or technology are placed as appropriate into this template.

We manage change in five loosely coordinated streams of change activity.

Although you can sometimes make good progress in one stream, you won't go very far without catching up on the other streams.

Managing the Pattern Programme

Setting goals and targets.

Creating and satisfying management expectations.

Balancing effort against results.

Coordinating effort in the other streams.

Delivering a satisfactory ROI on the programme as a whole.

Establishing a Pattern Capability

Enabling individuals and teams to work effectively with patterns, through training, mentoring and coaching.

Empowering individuals and teams to work autonomously and creatively with patterns.

Encouraging individuals and teams to participate actively in the pattern programme, through appropriate reward and recognition schemes.

Establishing specific roles and responsibilities in relation to patterns.

Building a Pattern Infrastructure

Installing pattern repositories and other tools

Implementing templates and procedures

Establishing support networks and metrics.

Doing Pattern Work

Defining and refining patterns. Transforming negative patterns into positive patterns.

Finding and eliminating negative patterns, in legacy systems or current design work.

Using positive patterns in new design.

Managing patterns

Connecting Patterns with the Enterprise

Embedding patterns in architectures, policies and corporate standards.

Coordinating work across the enterprise through patterns.

In a perfect world, everything would be in place before you started. But this approach leads to endless delay. If you want to do patterns at all, you have to get started with the minimum essentials, and improve later. Of course this means that you may not get all the benefits of patterns from Day 1, but at least you have a chance to get some benefits, and start evolving the capability.

Phase 0: Preliminary Assessment

The purpose of the preliminary assessment is to confirm the planning priorities. As consultants, we can suggest typical priorities and indicate which areas may need to be addressed first, but these priorities need to be confirmed for your organization.

In some cases, it may be decided to bundle other general software process improvements in with the implementation of patterns. There may be a serious problem in an area that is only indirectly affected by patterns, but the implementation of patterns provides an opportunity to fix other problems as well. This may be tactically appropriate in a given situation, but it complicates the plan, and will make it more difficult later to evaluate the costs and benefits of implementing patterns.

Phase 1: Getting Started

In phase 1, the emphasis is to get something started. This usually includes one or more pilot exercises to demonstrate how patterns work in your organization. Within most organizations, there are some people who are keen to develop new ideas and skills, and are willing to accept the uncertainties and challenges of new tools and methods. They are known as 'early adopters'. It is a good idea to involve them in the pilot exercises.

An initial set of procedures will be formulated for use by the pilot teams. These will be in draft form, with limited automated support. During Phase 1, the benefits of patterns will be small and localized. Phase 1 typically takes about 3-6 weeks.

Phase 2: Getting Ahead

In phase 2, the emphasis is on extending patterns from the early adopters to other parts of the organization. The successes of the pilot need to be captured and disseminated, so that other developers and project managers feel confident that they can achieve similar (or even better) results.

In phase 2, we should be able to write down some procedures and guidelines, based on the experience of the pilot exercises. At this stage, it may be appropriate to consider automation of these procedures, using desktop tools.

During Phase 2, the benefits of using patterns should increase, and the organization should start to receive a positive return on its investment. However, some of the longer-term or strategic benefits of patterns may take longer to realise. Phase 2 typically takes 1-2 years. In a large organization, it can take considerably longer.

Phase 3: Getting on Top

By phase 3, the use of patterns should be well established across the organization, and fully embedded in working practices. The full benefits of patterns are now available to the organization.

Programme Planning and Management

It's difficult to plan something in detail if you've never experienced it. So it's often useful to start by making some practical progress, for example in pattern usage or training.

But before you get too far into the programme, it's important to consider the management issues properly, and produce (negotiate) a detailed plan. In any case, it's always a good idea to set the expectations yourself, if you get the chance, rather than wait for someone else to impose their expectations on you.

• What are the expectations of the programme? How soon are results expected?
• How will the programme be evaluated? What will count as success?
• What are the specific opportunities and threats in your organization?
We can help by running a planning workshop with your key managers and technical experts. We usually bring along a "strawman" plan, to get the discussion going, but we expect you to tear our plan to pieces and replace it with your own.

The plan usually covers the immediate phase in considerable detail, and broad-brush outlines of the subsequent phases. We are happy to participate in regular progress reviews and replanning sessions.

Pattern Identification Workshops

Pattern identification often follows out of regular quality assurance activities. We typically run some sample design inspections, to take people through the process (and discipline) of converting hunches into properly articulated negative patterns. We expect this practice to become embedded in the routine of peer review and inspection.

Many experienced designers initially find it easier to identify negative patterns than positive patterns, especially in the context of a design inspection. They start with a hunch or intuition that there's something wrong with some element or aspect of the design being inspected, and are then called upon to explain themselves.

• What are the precise ways that this design can fail?
• What are the risks?
• In what ways might this design be difficult or impossible to implement or test?
• In what ways might this design be difficult or impossible to maintain?
• What evidence (if any) can be produced in support of these claims?
• What pattern of error does this design defect represent?
The designer can then be invited to explain how she/he arrived at the disputed design, and possibly to defend it. There are several possibilities.
• There is some peculiarity about the requirements that makes it difficult or impossible to avoid this negative pattern.
• The designer is aware that this pattern is normally regarded as bad practice, but has used it in this situation with due caution.
• The pattern is inherited from some legacy system or interface, which the current design has to accommodate.
• The designer is unaware of some relevant system issue, holds some false beliefs, or is making some unchecked assumptions.
• The inspector is unaware of some relevant system issue, holds some false beliefs, or is making some unchecked assumptions.
• All of the above.
If properly managed, and with due attention to the feelings of the participants, this can be an extremely valuable exercise in knowledge sharing and skills transfer.

Once the situation has been analysed, there are several possible outcomes:

• There may need to be some specific education or training, to address common areas of ignorance or confusion.
• The documentation for this design product may need to be improved, to make specific reference to the negative pattern and its resolution.
• The use of the negative pattern in the design may reveal a specific problem with the user requirements..
• It may be useful to conduct a systematic search for other occurrences of this pattern, elsewhere in the design.
• Some changes to standards and guidelines may be appropriate.
A similar process can be triggered by the identification of a design defect during system testing.

Sometimes design inspections can also result in the identification of positive patterns, either by recognizing a particularly neat solution to a particular design problem, or when the inspector proposes an alternative solution to an identified design defect. However, until people have considerable experience with patterns, it is difficult to define patterns that are sufficiently clear and generic to be useful.

Pattern Usage Workshops

Designers are invited to a pattern usage workshop, to display and discuss their use of patterns within their own work.

They may draw patterns either from the corporate pattern repository, or from public domain materials (such as books and webpages).

There are three main objectives for this workshop.

1. Designers receive encouragement and recognition for their good use of patterns.
2. Designers share knowledge and ideas about what patterns are appropriate, and how they can be used.
3. Pattern managers discover any opportunities, gaps or shortcomings in the usage of patterns.
Pattern workshops are held at intervals during the pattern programme, so that the increasing usage of patterns can be monitored and encouraged, and pattern usage can be reinforced.

Pattern Transformation Workshops

Pattern transformation is the process of finding positive (healing) patterns to fix common negative patterns.

We can also take failed patterns - pattern definitions that your people find difficult or misleading to use in your specific context - and make them clearer, more powerful and more relevant.

Where a particular negative pattern has been recognized as a common bad practice within current design practice, you need to provide positive advice to designers. Instead of doing X, do Y. Y is now a positive pattern. It is often a lot easier to define Y from X, rather than from thin air.

Sometimes it may not be possible or appropriate to provide a single position replacement pattern. Instead of doing X, do Y1 or Y2 or Y3, ....

Where a particular negative pattern is widespread within legacy systems, then we need a replacement policy.

If the situation is severe enough, it may be necessary to fix all occurrences of this negative pattern immediately, or within a controlled timescale. (This was what happened when people discovered the pervasive use of two-digit year fields in computer software and hardware, shortly before the year 2000.)

In less severe cases, it may be enough to advise those looking after the system to watch out for this pattern, and to replace it whenever an opportunity arises in the course of other maintenance activity.

Training, Coaching & Mentoring

We can provide a short training workshop, to introduce people to the concepts, techniques and tools of identifying, using and managing patterns.

We can also provide coaching and mentoring, either to individual software developers and testers, or to those responsible for particular aspects of the pattern programme.

top home page contact us
	This page last updated on June 8th, 2000 Copyright © 1999, 2000 Veryard Projects Ltd http://www.veryard.com/sqm/pattprog.htm