Shift left, build right: Your success factor in building quality into the software development process

The movement to shifting left in software development to find and prevent defects early in the software delivery process is a slow revolution, some twenty years in the making. By involving different members of the team earlier in the development lifecycle, the approach takes what would be a linear journey and makes it more iterative, which helps avoid delays in the release cycle when bugs are being discovered at the end.

What this looks like in practice, however, can vary significantly from organisation to organisation, or even team to team. To get more insight about what this means at Zühlke, we spoke to two of its proponents, Lead BA Matt Moores, and Lead QA Consultant Paul Carey, to hear their thoughts.

Shift left - Rethinking the development cycle

From a Business Analyst (BA) perspective, shifting left can have huge value. “We’re like the glue that sticks the team together, and we need to make sure everyone has enough information to keep them going,” Matt says. But if the team works in isolation and doesn’t have exposure to why and what they’re building early on, information can become lost or diluted. “You’d get to the end of a project and plenty of important conversations would have been lost along the way, and each would move you slightly further off course and you’d only pick up the issues when the Quality Analysis (QA) came in,” Matt continues. “So, for me as a BA, this allows everyone to get on the same page, see the big picture and cut out any assumptions before we even start development,” he concludes.

At Zühlke, the shift left approach shows up in the way developers are brought in early, so they can hear directly from the client what they want and how they expect the features to work. That big picture view means the team can start thinking about the solution from the outset. They are involved throughout the whole lifecycle so they gain more context and understanding, and ultimately more ability to innovate and trial when it gets to the development stage. “In this industry we need to be able to fail fast, learn from it and move on and if we have Quality Analysis happening earlier and earlier in the process, we’re able to do this,” Matt says.

The key to a successful Software Engineering project: Speaking the same language

In order to embrace this way of working, however, one thing is vital: clear communication. There was already enough room for misunderstanding in the old software engineering model as a project progressed from team to team, and phase to phase. Now, if everyone’s inputting at the same time, shifting left can be more of a hinderance than a help if you haven’t defined a common frame of reference. That’s where ubiquitous language comes in. By giving people the ability to describe systems and issues in the same way, you are all able share information that can be easily acted on.

In practice, this just entails choosing a single way of talking about the project. “If we use a ubiquitous language like Gherkin, then Matt can write in a way that is understood by the team and the business and it’ll translate into what the delivery team implement and test,” says Paul. They both note that while ubiquitous language can vary from team to team, the main point is that everyone understands it, and the aim is always the same.

Shifting and the status quo in Software Engineering

So the question is, why wouldn’t everyone be taking this step to the left? For a start there can be cost implications with including more team members upfront. And, of course, some people may just not be willing to operate out of their usual field. “Many people want to work in a certain way because it’s familiar to them,” Paul explains. So shifting left is, in part, also a matter of overcoming this inertia.

On top of this, there are also more theoretical issues. There is, for example, a school of thought that QAs shouldn’t have sight of the code before they come in so they can view it with a fresh eye. “I do understand this thinking, but I think it’s less about coming in cold and more about being objective at the right stages than anything else,” he says.

At the end of the day, shifting left isn’t only about changing people’s focus. It’s about the way you look at your role in a project as a whole. Paul sums this up in terms of the change in attitudes that he’s seen over the last few years. “Now I hear developers saying that they’re not just paid to produce code, they’re paid to deliver something,” he says. There’s a sense that writing the code is the easy bit. The challenge lies in building the right thing, and bringing the team in earlier in the lifecycle to build it in the right way too – and that’s what shifting left allows you to do.