Shift left is a term that is often applied to testing in agile teams, but the concept is perhaps larger than that. Shifting left is a practice of bringing the determination of quality of a deliverable as early in the development process as possible. Consider the development process to be a pipeline running from left to right, with user stories or use cases being fed in at the left, and delivered, working software coming out of the pipe at the right. With this in mind, we could consider shift left to mean that we should test the software as soon as possible. However, I think we might benefit from deeper thinking on the subject.
The point of the shift left principle is to improve the quality of the delivered solution as soon as possible. The cost of resolving a bug or issue is significantly reduced the earlier in the development process we are able to do so. The ultimate goal of agile is to deliver incremental value improvements to a customer as often as we can. Rapid delivery cycles shorten the feedback loop, maximising the benefit from any feedback we get. The more time we can avoid spending on resolving live issues, the more time we can spend doing development, and thus the sooner we can deliver value.
Before agile techniques were as widely embraced as they are today, it was common for development to be delivered in large batches, with the development from multiple tasks or teams being put into a large release. This large release would often then get 'thrown over the wall' into the QA department. QA were then expected to test all of the new functionality, as well as perform regression testing to make sure that existing functionality had not been adversely affected by the changes made. This often resulted in the testing of a release being a lot of work. Since it wasn't uncommon for the release into QA to be late, we often left the testers insufficient time to do the in-depth testing they wanted before a release deadline was reached. That doesn't achieve the goal of delivering quality software, because if this time squeeze occurs then the team are left with a difficult decision - release on time but without the proper testing, or miss the deadline. Nobody wants those to be the only available options.
Nowadays, we take an alternate approach; we use shorter release cycles. Not only that, we may have testing performed in the development environment, perhaps even alongside one or more developers. This is all positive. On the surface, this might be what we recognise as shift left - but it is not the only way we can benefit from the idea.
If the goal is to improve the quality of the delivered solution as soon as possible, then there is more we should be doing. What if we can reduce the number of bugs before they even happen? Surely that is best of all. This is where we should look to improve next.
I can offer two approaches that can help achieve this:
- Automated development
- Design
Automated development might include a number of improvements to consider, and as such is something I will cover at a later date. Today, what I want to touch on is design.
Design is a process that I feel is a little undervalued in a lot of teams at the moment. It feels like in the move from waterfall to agile we have thrown the design baby out with the long release cycle bathwater. Whilst we should of course minimise the overhead of development, doing some design can make the development task more effective, and also more efficient - and yet a lot of teams bypass it almost completely. There seems to be a misconception that agile and design don't mix.
I wonder how such a misconception arose. Nothing in the Agile Manifesto says that design is to be discouraged; indeed one of the 12 principles of agile software states "Continuous attention to technical excellence and good design enhances agility." Perhaps it is a desire to run fast that makes us step away from processes that can help, and perhaps have helped in the past. Sometimes, we should not forget what we have already learned altogether when trying new approaches.
The design and architecture of software leads to quality traits. Well designed software will meet its goals for scalability and reliability and is likely to suffer from fewer security vulnerabilities. Furthermore, it is also an important part of achieving maintainability. It is the maintainability of software that allows for a consistent run rate as the solution matures - and a consistent rule rate is identified as a valuable trait in another of the 12 principles of agile software.
Note that I am not suggesting that anyone undertake the large, up front design stages akin to those seen in projects undertaken with waterfall methodologies. There may occasionally be a benefit to a brief, up-front design task when starting a significant new piece of work - especially when starting a new system or subsystem - but these are not likely to be appropriate very often. Instead, we should undertake the process of evolutionary design; we should do small pieces of design to fulfil the needs of a particular task, as part of that task.
Doing design is not at odds with the principles of agile software development. They work together to achieve the goal the team is striving for - delivering value to customers as fast as possible. Design is as far left as we can get, and it's a great place to head off problems - before any code is even written. We do not need to fix a bug or patch a security vulnerability if we avoided it by taking a moment to think of how we might sidestep them before we start.
Is your team doing enough design to meet its goals?
If the answer is no, then fear not. In future work, I will demonstrate an efficient approach to design you might consider. Be sure to look out for that, hopefully you will find it beneficial.