People are the Lever
A Story of Service Design and Value Mapping for Developer Quality Assurance.
The easy way to Shift Left
Our cast of characters
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
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
-
A destructive culture
-
-
- Interruptions are disruptive
- Stress
- Frustration
- Puts in the hours to get code working
-
Quality Jane
-
-
- Likes to be challenged
- Likes to use investigative techniques to ensure quality
- Wants to add value
-
A destructive culture
-
-
- It is not about checking
- Hates boring repetitive work (adds no value)
- Dedicated
- 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:
http://www.nppdevtesthub.com.au/npp-devtest-gateway/
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.