The Shift Left Principle and DevOps

I’ve become a big fan of the “Shift Left” principle.  The premise behind “Shift Left” is that we move things that we typically do in later stages earlier.  It is human nature, but many people tend to defer particularly tough issues.  The analogy of “Kicking the can down the street” comes to mind.  Ultimately this leads to significant problems when we eventually try to address the issue.  The graphic below illustrates what happens.  It’s also an indicator that more agile approaches are needed.

There is a trend that is gaining popularity in shifting left is the concept of “Shift Left” Testing.  After recently seeing success with Shift Left Testing, I starting thinking about other things we might apply “Shift Left” thinking to in our DevOps practices.  Come to find out, there are a few really good ones!  Let’s look at Shift Left Testing and then explore some other “Shift Left” ideas we can adopt in our DevOps practices.

"Shift Left" Testing

With Shift Left Testing, the focus is moving testing (and specifically integration testing) as early as possible during development.  Test Driven Development is a key agile practice we see that emphasizes that creating test cases should be prioritized very high.  “Shift Left” Testing is different because the focus is on integration testing.  In my experience, I’ve seen a lot of significant issues arise when we start integrating “things” together. By moving integration testing as early as possible, we tease out integration issues earlier.  This is a good thing because it is much easier to address integration issues in the earlier phases when we can make architectural adjustments.  In order to get value out of doing Shift Left Testing, we need to make it easier for teams to do this – and DevOps is the way to make this happen with automation as well as service virtualization.

"Shift Left" Design Thinking

This can be a big one.  There have been many industry studies done that show what happens when a team doesn’t fully understand what the business needs are and the associated requirements.  In fact, there are estimates that show that 70% of software projects fail due to poor requirements.   I’ve personally seen situations where people spend weeks and months building the perfect project plan without fully understanding the business requirements.  Imagine how that ends up!  While requirements management has been around for decades, there are some newer approaches that enhance our collaboration that really help “Shift Left” our entire team in understanding business needs.  Among the top on my list for approaches is IBM Design Thinking.  I’ve witnessed IBM Design Thinking first hand and it is an amazing technique that really aligns the entire team.  Once the entire team comes together and leverages design thinking approaches to build the vision, good things happen earlier.  With an aligned vision achieved through IBM Design Thinking, we see less churn as we proceed through the Hills and Playbackes, we execute as a team more efficiently towards the shared vision.

"Shift Left" Deployment

Believe it or not, there are a few ways to “Shift Left” deployment and operations.  In the end, establishing a Continuous Delivery pipeline is the answer.  In the world of “Born in the cloud” applications running on a “Platform as a Service” environment such as IBM Bluemix, the ability to deploy continuously is pretty easy.  Doing this for other applications may seem more difficult.  However, for these types of “legacy” applications, there are few techniques we can use to shift deployment to the left.  A few of these techniques include:

1. Operations "Approved" Templates and Patterns 

Many organizations have checklists that need to be used to be validated before any application can be deployed into production.  Unfortunately, I’ve seen a lot of manual steps that operations have to go through to approve a production deployment.  In a “Shift Left” mindset, we should try to codify these checklists into approved templates that development can use earlier as a basis of development. 

2. Automated Tests That Validate Operations Checklist

Using Test Driven Development, building test cases that validates operation approved patterns helps build confidence (and should accelerate the approvals in deploying applications).  Build those test cases!

3. Automation

Automation is key capability we need and is the backbone of any “Shift Left” practice.  Automating a consistent deployment of an application across all the stages (DEV, TEST, PROD, Public Cloud, Private Cloud, etc.) will help build confidence in the deployment.  Sharing the results with operations will help build trust in building a culture that supports continuous delivery and helps us do this Shift Left paradigm shift.

Learn more from the newly updated Application Deployment and Release for Dummies ebook to find out more.

I’m sure there are other applications of the “Shift Left” principle.  I’d love to hear your thoughts on other things we might “Shift Left!”