A Holistic Approach To Shift Left (Part 1/5)

Publish date:

This is the first of a series of blog entries based on a paper that Rik and I presented in the 6th World Congress for Software Quality which took place in London last month.   We elaborated a holistic approach to “shift left” (which was the main topic of the congress) based on Sogeti & […]

This is the first of a series of blog entries based on a paper that Rik and I presented in the 6th World Congress for Software Quality which took place in London last month.
 
We elaborated a holistic approach to “shift left” (which was the main topic of the congress) based on Sogeti & Capgemini’s PointZERO® vision.
 
This series consists of five parts and starts with general thoughts about the “shift left” concept which we used as a basis for our vision on quality improvement. The PointZERO® vision is the starting point of our roadmap to sustainable business success and continuous quality improvement.
 

Why shift left?

After 70 years of experience in quality and improvement methods, information technology still holds enormous optimization potential. Still a lot of IT-projects don’t deliver according to stakeholder’s expectations regarding quality, time and/or budget. The main reason therefore is the known conflict between time, cost and quality which is best visualized as the “triangle of management constraints” (also known as the “iron triangle of project management”).
 


Figure 1: The “triangle of management constraints”

The main challenge in projects is to get the right balance of these constraints, whilst taking the risks in consideration, to ensure the IT solution enables business success. Finding the harmony must be related to all activities in the application lifecycle. This balance is not easy to achieve, as there is an inherent limitation involved: “the charm of the three” which means that it is very difficult to improve all three dimensions of this “devil’s triangle” simultaneously. For example, finding the right mix for the dimensions time and cost often is quite obvious, but for the quality dimension we should have a closer look. What should be reached is a balance where the three dimensions are optimized.
 
Before we discuss this tight rope act in more detail let’s first have a look at what activities are always relevant in the lifecycle, from cradle to grave, of an application (by which we mean an entire information system and the associated business process).


Figure 2 The “Application Lifecycle model”

The application lifecycle is an iterative model that contains various activities. These activities may be implemented sequentially, as in a waterfall approach, or iteratively and in parallel, as in an Agile approach. No matter what approach is used, these activities will have to be carried out one way or another. The lifecycle model is circular to indicate that new developments always are based on experiences from production, where the business process is maintained. The holistic approach to shift left elaborated in this paper can be applied to any context, so it is implementable for waterfall and agile environments alike.
 
The infamous quote, “Testing takes too much time and costs too much money” is often heard amongst business managers. When we investigate why testing is perceived this way, all too often we find that it’s not the testing activities that cause delays and cost-overruns, but it’s the fixing of defects that are discovered during testing that cause these problems. To raise awareness to this phenomenon we use the nickname “fixing phase”. This triggers stakeholders to ask “what does this mean?” The simple explanation is that in IT, many mistakes are made during the early activities of the application lifecycle and it’s normally the task of the late lifecycle activities (like testing and acceptance) to search, find and fix these defects. The obvious question is: Why can’t we, as IT specialists, do it right first time? In our opinion this is due to the fact that there is still not enough focus on quality and risks in the early application lifecycle activities. So we need to shift the focus to the left.
 
Where do we get the inspiration for this term “shift left”? Taking Barry Boehm’s research results on quality costs over the application lifecycle into account, we see it is possible that if a project focuses on an investment in achieving quality at an earlier stage this will imply a positive influence of the quality assurance activities in the project for the time and cost constraints. This is achieved through a “shift left“ (to the earlier activities to the left of the diagram) in which quality improvements are implemented simultaneously with other application lifecycle activities.


Figure 3: Relative quality costs over the application lifecycle

Through these measures, it is possible to improve the overall quality of the system under construction by improving and expanding the quality assurance activities, as well as the quality of every crucial intermediate product by starting these quality related activities earlier in the application lifecycle.
 
This leads to a significant reduction in time and cost as their main driver.  Rework on defects, especially during later activities, can be minimized. Unnecessary rework, as is commonly known, accounts for about one/third of all IT efforts.
 
The message for managers who implement business changes should be resoundingly clear: By preventing faults or by identifying and removing or correcting them at the earliest point after they are inserted, we can deliver better information systems at a lower overall cost and with shorter throughput time. We should all “do IT right the first time” to stop wasting time and money.
 
References:
 
[1] Maurer, Rick, Beyond the wall of resistance: Why 70% of all changes still fail—and what you can do about it, 2010
 
[2] Marselis, Rik and Ewald Roodenrijs, The PointZERO vision, Sogeti Nederland B.V., 2012
 
[3] Vaes, Karim, Devil’s Triangle of Project Management (Online), available at http://www.pmhut.com/devils-triangle-of-project-management (accessed on 2013/12/31)
 
[4] Boehm, Barry W., Software Engineering Economics, Prentice Hall, 1981

Related Posts

devops

Site reliability engineering

Genesis Robinson
Date icon August 7, 2020

Due to the current state of how we monitor, alert, and log our digital ecosystem, it takes...

Strategy and Transformation

The buzz for mastering technology development is getting serious!

Sumit Kumar
Date icon July 2, 2020

There are specific technologies that clearly show their transformative power, even in the...

Customer Experience

From markets to people: rethinking how media measures success

Madan Sundararaju
Date icon April 20, 2020

Digital transformation is rapidly reshaping the media industry, but a change in mentality is...