People are the Lever

A story of Service Design and Value Mapping

for Developer Quality Assurance.

The easy way to Shift Left

PeopleTech, at DevQ

16 February 2017

Our cast of actors

Our feature team is aligned with Agile (we do stand ups and Scrums; stories and features) and DevOps

Johnny B. Good Coder

Focus on delivery

Likes to get on with the job

Enjoys coding

Smiles when his code works

Quality Jane

Likes to be challenged

Likes to use investigative techniques to ensure quality

Wants to add value

The Stage of our software delivery

Turning Coffee into Code

Act 1 Scene 1

Deploy into an environment that has all the other pieces of code, systems and other props required to get this piece of code executing. (It is this misguided thinking that we need to produce quality code is an End-to-End environment that is the same as production)

Turning Coffee into Code that plays well with others

Act 2 Scene 1

Quality Jane has great scenarios with which to observe the behaviour of the code. What happens is that code is not playing well with others and unable to pass some basic checks.
A report goes back on the strange behaviour of the code (aka bug report, issue list, defect list).
IT IS A FEEDBACK LOOP on what is happening and how the code behaves.

In the meantime, Johnny B Good Coder is on the coffee-to-code hamster wheel churning out code for each feature for some arbitrary dead line (let’s face it sprint intervals are arbitrary “sounds good” numbers). The FEEDBACK LOOP (aka bug report, issue list, defect list) is an Interruption. Our mind must shift from what we are doing to remembering what was done. The stage needs to be rearranged to replay a previous scene.

This is part of everyday software delivery life and it is the killer of effectiveness and efficiency.

A mindless churn to get code live

Act 3 Repeated Scenes

Not only does this long feedback loop kill our capability to deliver good software on time and in budget. We then compound the issue by creating a cyclone of long feedback loops until forced to release into production. (I have always loved the notion “software is never released it escapes“.

The consequences: –

Note the iceberg on the stage. What is not visible is the behaviour of the code that detracts from the quality of the software (however you may define quality).


Agile and DevOps tell us that software is created by people and that we need a change in our culture. So let’s look at what this long FEEDBACK LOOP has done to the people and their culture: –

Johnny B. Good Coder

Focus on delivery

Likes to get on with the job

Enjoys coding

Smiles when his code works

Quality Jane

Likes to be challenged

Likes to use investigative techniques to ensure quality

Wants to add value

A destructive culture

Interruptions are disruptive



Puts in the hours to get code working

A destructive culture

It is not about checking

Hates boring repetitive work (adds no value)


Frustrated that her value is not realised nor appreciated

Stressed with the “mad rush” to get code live

Our feature sets in a barrel

Act 4 Scene 1

Our service design and value mapping approach identifies the pain felt, understands the cause and creates small incremental changes. In this case, a cause is the time taken between creating code and finding an environment in which we can exercise the code with tests. If we dig a little deeper we see that each iteration of the process of testing and changing code follows a waterfall approach. In which the code becomes a barrel that tries to survive the waterfall. The feedback loop of the quality of the software has to travel back up the waterfall. The code is changed in a different environment (“works on my machine”) before being put in the barrel and sent over the waterfall – again.

Shift left to no waterfalls

Act 4 Scene 2

This feature team has a test harness on a server “sitting in the corner”, together with a variety unit tests lying around.

This diagram represents the value chain we have co-created with the team. It is a value chain that provides immediate feedback to everyone.

The test harness is brought into the IDE and the CI Server. Unit tests are dusted off and integrated into the test harness. The wall between Coding and Testing is removed and a single DevTest team is created. (We prefer the term Quality Engineering to Testing and Behaviour Ideas to Test Cases). Our feedback loop is now measured with a clock.

For a detailed video with service virtualization of SWIFT Financial Messages and the application of Lean, Agile and DevOps principles,  have a look at

Moral of the story

Closing Act

To change culture have an easy transition path

Our change in culture results from having an easy transition path to a common desirable place.
Most times you need a small intervention to achieve big differences. Another analogy is a drop of oil on a sticky wheel. It is not about hours in a workshop figuring out what to do. It is about a small effort to make continual incremental adjustments that result in a habit.

Think of the norm in a different way

Words make a big difference; this narrative is carefully chosen to create a sense of a team working towards a common goal: – that of creating software that delights customers.
OUT                                                                                             IN
Quality Control                                               Quality Engineering
Tests                                                            Behaviour scenarios
Bugs                                                            Feedback loop

Silos is the sickness

We have moved from a silo approach to a team approach.

In the silo approach code is passed from one phase to the next. (It is not what you call yourself it is what you do that determines the change to Agile and DevOps. (Sally Field in Forest Gump – stupid is what stupid does).

In the team approach each team member brings their value to create a great product (Remember Fowler, a guru in the early days of Agile – great teams build great software.).

In the value chain we have co-created, John B Good Coder can tap into different thinking about what can go wrong in producing software that delights customers. That different thinking being the thinking of Quality Jane.


Automation at the start has a greater return than automation at the end of software delivery

Think Service Virtualization for Shifting Left, where behaviour scenarios are created and easily consumed at the start, and throughout, the software delivery pipeline. The term Application Behaviour Virtualization is a better description of what a team should be doing to achieve great quality in software. Automation has its greatest value at the start of coding and the least value at the end of the software delivery.