Welcome to the first of a series of blogs on how we can apply design patterns to everyday development life, rather than just to the code.  To start this series I have chosen the classic Gang of Four ‘Adapter’ pattern to look at how we can work in an agile manner within a non-agile organisation.

Intent

• Convert the way in which you interact to a different interaction method which meets what people expect.  Adapter lets people work together who couldn’t otherwise because of incompatible working styles.
• Wrap an existing working style with a new interface.
• Impedance match an old working style to a new one.

Also Known As

Wrapper

Motivation

An existing person or department offers compelling functionality that you would like to reuse, but their “view of the world” is not compatible with the philosophy and architecture of the system currently being developed.

As an example consider the case of an agile leader working within a traditional organisation where individual performance reviews need to be completed.  This is a problem often discussed and faced, particularly in organisations with internal development teams but whose main business is not producing software.  Refusing to provide individual reviews may not be acceptable to the business.

An agile leader may choose to give all team members an ‘individual’ performance review which is based on the team’s performance – so that all team members get the same review and grading.  The Adapter pattern allows the agile leader to appear to be a hierarchical leader whilst still enabling agile practices.  The aim is for the agile leader to appear to be a hierarchical leader in order to allow the organisational system to continue without conflict.

Applicability

Use the Adapter pattern when

• You want to work with an existing person or department and its interface does not match the one you need
• You want to allow a person to cooperate with unrelated people with incompatible working practices

 

Structure

Participants

The objects participating in adapter pattern:

• Client – collaborates with objects conforming to the Target interface.
• Target – defines the domain-specific interface that Client uses.
• Adapter – adapts the Adaptee to the Target interface.
• Adaptee – provides compelling functionality  which needs adapting to that expected by the Client.

Implementation

Agile in a Waterfall World

What do we do when the software to be produced is part of a larger waterfall project?  We will be asked to provide estimates and deadlines for fixed scope work.  This is a problem which is faced by many teams who have decided to work in an agile way within a waterfall organisation.  A common mistake is for the team to respond saying that agile doesn’t have fixed scope and dates, that the team will deliver the most value they can within the timeframe.  To traditional Project Managers this sounds woolly and like we are refusing to make a commitment, so they can’t draw up their plan. This is the root cause of most conflict in this scenario.

In my experience the best answer in the short to medium term is to use the Adapter pattern and provide the interface which the Project Manager expects.  But also, to let them know that you will be building the software iteratively and so they don’t need to plan in a detailed manner.  Give them some milestones along the way so that they can draw their plan but try to make them at a feature level, so that the detail of exactly what completes that feature can be determined later.  This allows them to feel more comfortable with the change and for them to measure whether progress is ahead or behind schedule.

Is this approach ideal?  No.  But it’s a step in the right direction.  It does mean that the team needs to do some up front planning.  The main thing is to make sure that the planning is not at a detailed level and that the whole team is involved in coming up with the plan.

Consequences

Use of this pattern allows people to bring in changes to the software development approach without challenging every other team and department that they work with.  Accepting that others haven’t chosen this change and that it is the responsibility of the team to adapt their external interfaces, allows the changes to be introduced without major disagreements and conflict.

However, ideally the Adapter pattern should only be used as a tactical solution to reduce conflict in the short to medium term.  It’s important that a more strategic approach is also taken to change things in the longer term so that the interface expected by the Client shifts as experience teaches them that agile is not scary and woolly but actually gives them more information and earlier feedback as to progress.  Don’t tell them this upfront – show them through delivery.  Long term use of the Adapter pattern will lead to a limited implementation of agile and an inability to achieve the maximum possible value.

See Also

• Design Pattern Life Lessons : Observer