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
Encouraging individuals and teams to participate actively in
the pattern programme, through appropriate reward and recognition schemes.
Establishing specific roles and responsibilities in relation
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.
Connecting Patterns with the Enterprise
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.
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
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?
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.
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.
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
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?
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
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.
Once the situation has been analysed, there are several possible outcomes:
A similar process can be triggered by the identification of a design defect
during system testing.
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.
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.
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.
Designers receive encouragement and recognition for their good use of patterns.
Designers share knowledge and ideas about what patterns are appropriate,
and how they can be used.
Pattern managers discover any opportunities, gaps or shortcomings in the
usage of patterns.
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
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.
This page last updated on June 8th, 2000
Copyright © 1999, 2000 Veryard Projects Ltd