It is quite difficult to pick up a piece of a marketing material without using the phrase “Shift Left” in the first paragraph. The idea of doing something better and quicker by attacking the guts of the problem earlier makes sense and fits with most peoples’ ideas of good practice.
The problem of course is that the noise of marketing has now obscured the solution. How can you distinguish the processes, methodologies or tools that can actually deliver on this promise from those that can’t, when every tool promises the same thing? If you pick away at the marketing the actual effects of such tools are usually very small and tend to be, in essence, old methodologies dressed up in new clothes. Many of the traditional barriers to project success remain, and you have to work very hard to get anywhere close to the promised results.
Problems with Agile
The issue here is that if you look inside an Agile testing sprint it is in effect a mini waterfall wrapped into a shorter time scale. The design is started, the programmers code and the testers test – IN THAT ORDER, no exception. So any potential benefits of Agile are actually being lost by time pressure at the end of a sprint not allowing the code to be tested properly and having to roll over testing into the next sprint. In other words, as long as testing is performed late and testing bottlenecks remain, true Agility is impossible.
Properly “shifting left” requires a more thorough reconsideration of development processes than adopting one of the many “Agile” tools on the market. It depends on a shift in the full sense, not a reshuffle of existing practices, concentrating effort into the initial design phase. Teams are then able to “sprint”, as all subsequent development materials needed for testing can be derived from this initial work done.
With sophisticated requirements definition tools, the Agile development lifecycle can begin with a non-technical user designing a process or program as an active flow chart. In spite of the simplicity of this design process, the active flowchart is underpinned by all the functional logic involved in a system. From the flowchart, then, all the materials needed throughout the development lifecycle can be automatically derived – at the same time!
Business analysts can derive use cases, verifying these with the user. As these have been derived directly from the requirements, they cover 100% of the system’s functionality, working to eliminate the ambiguities in requirements that lead to costly, time consuming defects making it into production.
What’s more, as the use cases are defined, the test cases can be automatically generated – use cases have effectively become test cases, removing the bottlenecks caused when testers have to manually write, maintain, and execute tests. A system’s requirements can therefore be fully tested, even within a three week sprint.
Shift-Left
Agile project planning and management can also be enhanced, by virtue of the most accurate measures of complexity on the market, allowing you to plan exactly how long a project should take BEFORE you start.
The combination of having the use cases; test cases and metrics available earlier will completely transform the way your IT projects work. Being able to plan exactly how long a project will take allows you to control costs; it lets you schedule your staff more efficiently and it means you hit your deadlines. Being able to accurately predict how long a change will take lets you decide whether it’s worth doing. How often has a supposed small change turned into a nightmare and caused chaos with a delivery schedule?
The biggest positive thing is that you test earlier and you test less, while most bugs are found before you even start coding, and you don’t have to rely on expensive and ever growing test teams. Remember, you can’t test quality into a product; you have to design it in at the beginning!
So next time you want to plan a project draw a flow chart of the processes and see it in action.
