Our thought leadership articles started with general views of aspects of The SQA and Testing marketplace. We then looked at the continuing move to using “agile” approaches and the impact of these drivers on the ongoing evolution of SQA and Testing. We also separately looked at the evolution of “hybrid” roles and the evolution of the “full stack” QA engineer and where the experienced tester stands today. We then did some more focused articles around TEM, TDM and Production Testing. In this, the final article in the current series, we are covering the various dimensions of Process Improvement at both the macro and local levels.
At a macro level, there have always been groups and organisations seeking to address the perennial challenge faced by IT organizations in delivering the solution the customer/user really wants in the best timeframe, to budget and with the right quality.
The “operating model” for software development has always consisted of the three elements of Process, People and Technology and all have evolved and become more interdependent over time.
This has happened at a macro level through the evolution of development frameworks, formalised waterfall SDLC, RAD, Information Engineering, Client Server, RAD, CASE, DSDM etc. as technology grew. Most were seen as the “silver bullet” for software production and delivery problems addressing users’ real needs.
An evolution from the clearly defined “IT roles” to hybrid business/IT roles to hybrid technical roles to current “full stack” everything roles. In addition, in an age of continuous “everything” we have the age of continuous learning.
Continuing exponential increase in power, reduction in size in hardware, and a move to SOA, services, microservices, mobile apps and a proliferation of supporting tools on the software side.
For Process Improvement, it has always been important to have some level of repeatable process, a set of relevant measures and some targets as to what constitutes improvement. As process approaches and technology have evolved so have the dimensions of measurement as we discussed in our previous paper. The traditional focus of Process Improvement has been to investigate the relationship between the sets of metrics at a portfolio level and to put in place improvements in the overall development life cycle. A crucial element of this is the ability to identify the “root cause” of failure in order to direct improvement action in the correct area of the operating model.
With all the changes across all the operating model areas has come greater interdependency, complexity and most significantly, a multi-fold increase in delivery cycle times. To enable this requires measuring the entire system - end-to-end - to understand how value flows and where it is constrained, and most importantly, to correlate those metrics with desired business outcomes.
Process Improvement normally involves – gather metrics/data, reviewing these inputs, comparison/analysis with respect to expected/desired outcomes, reviewing action, agree next actions and updating the action plan. This process can be executed small scale and rapidly or flexed as required. This approach allows for continuous optimization in the pursuit of delivering greater and greater value to the organization, faster.
There are three inter related elements of Process Improvement today.
1. Doing the “right” things
This “digital transformation” has made developing the “right” product fundamental to success. The focus in this area is on improvement in the processes of market and customer sensing, data analytics, product selection, value management etc. Action items which require an agile response are added as Improvement Backlog Items.
Assuming we are doing the right things then the focus of developing the product “right” is on speed, quality and sustainability.
2. Doing things “right” - Business Process Improvement
Digital transformation has also impacted significantly on business processes. “Right first time” fulfilment processes, remote/automated customer service, outsourced support functions etc. are all elements of end to end processes. Process improvement is often interlinked with “Lean”, Six Sigma, etc. as organisations seek to have quality, rapid, cost effective IT enabled business processes. Most process change is as a result of IT enabled change initiatives and these also create backlog items.
3. Doing things “right” - Software delivery process
This area was traditionally seen as the primary area/focus of process improvement. Improving the speed and quality of the software delivery process was seen as the key enabler of successful delivery. Process productivity and quality was rigorously measured but this somewhat ignored the fact that it is of little value to build the wrong thing faster. As the challenge to build the right thing as well as building right became more and more important as digital transformation and customer focus gained momentum, software delivery process improvement has a more balanced place in the end to end process.
The Agile Manifesto emphasizes the importance of continuous improvement through the following principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” This is normally done by holding a Sprint Retrospective as the last task in the sprint. It is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. These are short, an hour or so, focussed sessions and the team takes the actions forward.
Metrics are important as they give quantitative insight into the team's performance and provide measurable goals for the team. While they're important, listening to the team's feedback is equally important. We live in an age of continuous/lifelong learning so incorporating “self-improvement” of team members is another key element of continuous improvement. Both the quantitative and qualitative feedback elements are necessary to drive change.
As agile is “scaled” and there are multiple agile teams involved, the challenge of balancing formality (a consistent agile approach across all teams) with agility (flexibility/autonomy/tool choices) has to be considered. The purpose of Process Improvement is to have a systematic, consistent and managed approach to assessing, accepting and implementing changes to a framework. As a framework is used by a community of practice it must be changed with their involvement and in a defined manner understood by all. Equally it must be updated regularly but not so frequently that the community that uses it gets confused.
If we look at Scaled Agile Framework (SAFe) - an agile framework for an enterprise which is not limited to smaller teams and guides enterprises in scaling lean and agile practices - the Inspect and Adapt (I&A) is a significant event, held at the end of each Program Increment (PI), where the current state of the Solution is demonstrated and evaluated by the team. Teams then reflect and identify improvement backlog items via a structured, problem-solving workshop. In the second part of the I&A event, teams collectively review any quantitative and qualitative Metrics they have agreed to collect, then discuss the data and trends. For addressing systemic problems, a structured, root-cause problem-solving workshop is held by the ART. Root cause analysis provides a set of problem-solving tools used to identify the actual causes of a problem, rather than just addressing the symptoms.
This seeks to manage the formality with flexibility.
Changes identified can be across each of the operating model areas:-
People – role definition, training, mentoring, recruitment
Process – business process/software development process
Technology - Software tools, technical environments
Where the process improvement changes require team effort appropriate backlog items are created. Some of the changes may require adjustment to the metrics being gathered.
A full-scale Process Improvement requires sustained focus, commitment and energy.
Our focus in this series of articles has been on quality and in the various ways the different elements of the operating model (people, process, technology) seek to ensure that quality is an intrinsic part of delivery process. Quality is about “fitness for purpose” and starts and ends with the customer. If it is not fit for purpose from the customers perspective, even though the technical quality may be excellent, it will not hit the mark. Understanding the real customer need and how the business can satisfy the need, rapidly and profitably is the real challenge for quality delivery.