Learn about the new SAFe® DevOps content making its way into SAFe Guidance, and future versions of the Scaled Agile Framework® in this overview of our webinar with Dean Leffingwell, Scale DevOps and Continuous Delivery with SAFe.
The SAFe Continuous Delivery Pipeline
This image illustrates the SAFe Continuous Delivery Pipeline. The pipeline begins with continuous exploration – the process of going through and understanding what we should build and why we should build it. In the middle is continuous integration. SAFe will have a deeper focus on CI which has historically been relegated to the process of making sure code gets into the baseline. The final two pieces are continuous deployment and release on demand.
This continuous delivery pipeline highlights that you want a continuous flow of value as the features are being ideated. You want to have releases ready to deploy but you want to choose when it is that you do your releases.
SAFe Epics & the Lean Startup Build-Measure-Learn Cycle
The Lean Startup focuses on building systems that people haven’t used yet. SAFe will start managing epics through the Lean Startup Build-Measure-Learn cycle. Epics generally involve building systems that people haven’t used yet.
SAFe will begin approaching epics a little differently than we have traditionally with just breaking into features. It is more beneficial to talk about the MVP of epics and then go through the process of evaluating that MVP through the Lean Startup continuous feedback loop.
SAFe & Lean UX
Lean UX is not about pixel perfect designs that navigate well and follow style guides. Lean UX is about hypothesis driven development. And as soon as you say hypothesis, either In the context of Lean Startup at the epic level, or Lean UX, the feature level, it changes the expectations.
Because if we’re talking to our executives and managers, customers and key stakeholders and we say we’ve got a feature, and it has a hypothesis, well that automatically communicates the fact that there’s no guarantee that what we’re about to do is the right thing.
Melding these Lean Startup and Lean UX principles together gives us a stronger view of scope management, and it simply assumes scope management instead of assuming that everything you build is the right thing from the get go.
And that means that our feature definitions need to change. Each feature in SAFe should have an outcome hypothesis. For example, your goal maybe to reduce downtime 80%. Now we know what success looks like, not just what done looks like. It’s not a matter of that we did it, it’s a matter of we delivered the value that we intended to deliver.
Avoid the Branch and Merge Problem
SAFe will start taking a higher level view of continuous integration. We’re not talking strictly about how my code gets in the baseline. We’re talking about how features leave the program backlog and make their way into continuous integration.
What you see in the image above is a mainline that’s continually growing value. That means that every team is working from the latest revision of all the work. This avoids the branches and the branch and merge problem. Now we have a way to think about feature level CI, not just code level CI. Features are driven by an MVP implemented with an outcome hypothesis.
New Two Week System Increment
SAFe will have a system increment every two weeks. We have to be careful how these features move into a more continuous delivery environment. In order to evaluate your system increment and run the system demo, you’ve got to make sure that those features work or are toggled out so they don’t disrupt the existing functionality.
We can’t deploy a bunch of functionality and then hope in a month or two it works. We’re going to bring that integration back together every two weeks and we continually verify it via acceptance test and NFR testing.
CI at the Value Stream Level
The entire solution needs to be integrated at the value stream level for organizations running multiple ARCs (Agile Release Trains). Above you see how during each increment we build the small pieces value and then at the solution level each arc contributes its stuff again to the mainline.
A CALMR approach to DevOps
There was a period of time which DevOps was described as CAM; culture, automation and measurement. Scaled Agile Inc. is extending that to CALMR; culture, automation, Lean flow, measurement, and recovery.
DevOps is a CULTURAL shift first
It is no secret that DevOps is a cultural shift. In the enterprise there are VPs of Dev and VPs of IT service management who have different plans, responsibilities, cultures, and backgrounds. With DevOps these teams have to work together. So we need a culture of shared responsibility.
We can’t look down the DevOps with the assumption that nothing will fail. That requires shifting operations responsibility upstream. At the same time, operations responsibility follows the work from upstream.
AUTOMATE the deployment process
Why is automation so important? It’s the same story we had with testing. If you can’t automate testing, you can’t do agile. How come? Well because in agile we create a small incremental system and in order to know the system works, we have to test it. Manual testing isn’t efficient, so we automatically run a batch of tests. In a similar manner, we need to automate the pipeline.
Enable LEAN Flow
We want to run the smallest economic batch. Reducing batch size is the goal of almost all of our processes. It increases predictability and reduces re-work. The notion of batch size and lean flow is absolutely integral to DevOps.
Build for RECOVERY
DevOps measures everything. You move from asking what’s important to measure, to measuring every function point in the system. You can easily have application telemetry that reports thousands and thousands of data points in the combine system. That’s okay, it’s all automated and we only need that data, right, when something goes wrong.
Architect for Release-ability
The average DevOps conversation is a discussion about deployment automation. But that DevOps conversation needs to be elevated to what happens when something goes wrong.
Visibility is Key
You can’t manage what you can’t see. As we start to think about moving our features through to production we have to start thinking about not just the descriptive elements of how the system is supposed to behave, but how that gets converted to the packages that we actually release.
Kanban for DevOps
Lean, DevOps, and Kanban fit well together. If you want to measure and understand what’s flowing through the system you’ve got to know what’s important to you. So, above you see our default Kanban, this will appear as a new default program Kanban in SAFe sometime soon.
Release On Demand
What does release on demand mean? It doesn’t mean release all the code you have to the user whether they want it or not. Releasing is not a monolithic practice. Develop multiple cadences to release on demand.
It’s not the full system that gets released. You want to start architecting the system in such a way that you can do what you need to independently of everything else. So In the same way that we can release independently over time, we can release independently of each other. We can start thinking about much smaller value streams, value streamlets, that are the things that become the target of your DevOps function.
This overview is just a portion of the guidance provided in our recent webinar. Check out the full webinar on demand to get practical guidance on scaling DevOps with SAFe.
Visit our website to learn more about how VersionOne supports SAFe.
Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.