Shifting Left

September 2020

When delivering complex software, there are so many ways that things can go wrong. All mistakes have one thing in common - they all start with a misunderstanding. These misunderstandings impact quality (we ship software that doesn't meet customer expectations) and time spent developing features (we have to rework the solution to get it right). A good development team wants to avoid these problems and here I want to explore what I believe to be the best defence against misunderstandings of all kinds: VALIDATION.

validation definition image

note that the increase in use correlates to the rise of software development

It is essential that the team have a shared understanding of both the problem being tackled and the planned solution to that problem. This is more difficult than it seems as team members may come into contact with the problem at different times and each conversation about the problem is going to have inconsistencies.

Most likely, a business analyst will be the first to discover the problem through conversation with the end users. They will enter into some kind of requirements gathering phase and will gain a solid understanding of the problem which is hopefully consistent with the end users understanding.

The problem will then usually be discussed with key stakeholders to ascertain whether the business should invest more time in solving this problem - maybe there are higher priority items, or the solution falls outside the business area of concern or some other market reasons to go no further. For this discussion to work, the key stakeholders will need to gain an understanding of the problem - not necessarily in much detail, but enough to function as decision makers in this capacity.

Assuming the problem is given the green light to be tackled, a delivery team will be tasked with solving it for the end users. There may be an initial refinement meeting where the business analyst explains the problem to the team, commonly in the form of a user story (AS A... GIVEN I... THEN I...) so that the team can technically refine a solution to the problem, often without further input from the business analyst.

It is usually only once the solution has been agreed upon and understood by the team that the question of validation will be looked at (sometimes this won't even be done until the solution has been worked on and handed over to QA). This is generally where test plans are put together, manual or automated.

The lack of any validation until the very end of this process means that there is a high risk of a misunderstanding occurring, primarily for two reasons: First, since the end user is not part of the discussion aside from the very beginning this is essentially a game of telephone with all the room for error that brings. Second, the nature of the problem itself may change during this work meaning the customer need is different to what was originally discussed (maybe increased demand at the end users site means they need to provision for 100 thingamajigs per hour rather than the 50 originally requested).

In order to mitigate this risk, we nee to explore ways to add validation steps earlier in the process. By SHIFTING LEFT our validation questions, ie: have them occur earlier in the progression of work, we could add checking gates to ensure work can only progress if it is safe to d so. There are a number of methodologies which aim to bring this shift about such as TEST DRIVEN or BEHAVIOUR DRIVEN DEVELOPMENT where test plans are worked out in advance of implementing solutions, usually in the technical planning phase of the process. For the record, I am a major fan of TDD; the benefits are immense and it is a fantastic tool to have at your disposal but it does not protect against the risk of misunderstanding, only misunderstanding between the person implementing the solution and the person defining the test case. I have read many articles on shifting left that describe putting QA before development work rather than after it, but I think they miss the bigger point and fail to see where the risk of misunderstanding occurs.

Much better then is to have the team share in the goal of mitigating risk at all stages instead of it being seen as a function of QA. It is essential that the question of validation is thought of all the way from initially exploring the problem to the final delivery of a solutions. Teams should therefore work to upskill in this area and look at how to best achieve validation and frequently challenge each other to improve this skill. By adopting a philosophy of CONTINUOUS IMPROVEMENT teams can become more proficient in this skill over time. If this approach is successfully applied then there should be a higher confidence in the correct deliverables being produced and a reduction of quality related issues being raised by customers.

It is important to note however that this desire for validation should not mean that all questions are answered up front - only enough work to progress the item along the refinement process should be completed and checked and no more. Teams should be free to explore the different aspects of the problem and best solutions without being hampered by validation checks - validation should be only a tool to ensure the goal is being met.