Shift-Left has become a slogan for delivery. What do most people mean by that? If you’re really serious about it, I’ll walk you through different aspects of real-life shifting. Seriousness is essentail.
Learning From the Past
Let’s start by going back 30 years ago. Big projects, multi-year release cycle. That wouldn’t fly today. (Or is it? If you suffer, talk to me!)
Anyway, in the 90s there were some efforts to tackle this. In a few years they would call those “agile development”. The idea is to deliver software in consistent frequency, incremental fashion. Agile development in the 90s and the noughties, focused on teams. It looked great to management consultants., who were looking for new ideas, as the old ones didn’t work. From Scrum, SAFe and LeSS were born, promising a transformative experience that will result in great delivery cadence, building the right product, and lots of other great promises.
There’s something that didn’t transfer well though. We can change org-charts any way we like, and that can help. Multi-skilled, cross functional teams can focus on the work and produce it. They work closely with Product, split stories, and build.
But can they do it at the right quality, as they sprint away, every two weeks? I hate to burst bubbles (unless they’re bubble wraps, I really like those). But it wouldn’t work then either, without something called XP. That’s the Shift-Left OG.
Scrum was great, but it didn’t touch any of the technical issues. In fact, it got momentum from teams that were doing eXtreme Programming. Apart from the cool name, XP talked about the actual technical practices. And Scrum was deliberate in saying – “I’m the process part, look at XP for the technicals”.
XP Is The Grand Dad of Shift-Left
For example, TDD came from XP. Test Driven Development helps write less code, all covered by tests. That means you deliver quality code, all the time. That’s the goal, right?
With XP came automation as a supporting process for quality delivery. Having tests suites allow us to make modification without running a full regression suite manually. Again, supporting the goal of quick, sustainable delivery.
But not many people know what XP is today. Sure, we talk about automation, but as a tool, not as a supporting process, without any goal other than “push it quicker”.
Once we got the technology, we thought everything would work. But there are still teams delivering “too slow” (not going to argue that, organizations will always want more and faster), but also quality sucks.
You see, sustainable delivery, means we retain the quality over releases. That means a lot of work to make sure that at release we have a full automation suite.
And that’s not enough either. Because when developers hand off not-so-tested code (let’s call it potentially buggy), that code comes back like a boomerang. Until that code stabilizes it will not be released, so although maybe delivery is consistent, the amount of working features coming out is low.
The Lost Formula
How did they do it in the 90s? Well, first, let me remind you that those XP teams were very few. They were the exception. But they automated their tests and they kept their code clean. Well, the developers did. Less boomerangs.
Oh, a missing thing in the 90s: Testers. The profession was almost non-existent then, only starting out. So the developers were planning, writing and executing their tests.
Today we have developers working hard to deliver, testers return it. Things get nasty. Oh, and those developers cost more than testers. So let’s throw more testers at the team, try to help them cover the mistakes.
And now organizations look at their teams, and wonder what they can do that worked 30 years ago. And consultants gave it a great name: Shift Left.
Let’s take a break. Next time, we’ll discuss the challenges and options you have for Shift Left in the organization.
In the mean time, take a look at my Clean Code workshop. Clean code is one of the engines of shifting left.
0 Comments