DevSecOps and Agile – conflict or partner?
DevOps, or DevSecOps as it is now often termed (including Security as a key factor), is a key movement in software development which integrates the development of software with the deployment and operations in production systems.
Conceptually, DevSecOps has a lot in common with Agile development. DevSecOps comes from similar Lean roots. The greater focus on production systems in DevSecOps means a stronger, more visible link to Lean Manufacturing.
The infinity loop
DevSecOps integrates the traditional software development flow with the operational running of production software.
Traditionally software deployment would be viewed as a sequential, linear process. The development flow (code, build, test) would happen in isolation and hand over to the operations flow (release, monitor, operate).
The “infinity loop” visualisation shows these as an integrated whole. Development flows through deployment into operations, and feedback from operations flows through planning into development.
Like Agile, there is no “owner” for DevSecOps so there is no single definition of what DevSecOps is. Again, like Agile, this is a practitioner-led movement based on practical learnings. There is no DevSecOps equivalent to the “Agile Manifesto”. The highly influential book “The Phoenix Project- A Novel about IT, DevOps, and Helping Your Business Win” first brought the discipline to visibility. The author, Gene Kim, later formalised the ideas more as “The Devops Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations“.
The Three Ways
A good starting point for a definition of DevSecOps is the “Three Ways”, described below in “The Phoenix Project”.
The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations.
“The Phoenix Project” – Gene Kim
The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework.
And the Third Way shows us how to create a culture that fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery.
Let’s look at these three ways in more detail and how they match up with Agile principles and the ideas in the Plays.
Flow
As seen elsewhere in the Agile Plays, Flow is central to Lean Software. Most of the principles for enhancing Flow which are used in Agile are also promoted in DevSecOps.
Working software in small batch sizes is a key factor in DevSecOps, as is minimising Work in Progress. Visualising the flow and looking for areas of waste in the value stream are also key principles.
Until code is in production, no value is actually being generated, because it’s merely WIP stuck in the system.
“The Phoenix Project” – Gene Kim
Feedback
Agile development emphasises getting working software to the customer rapidly. Customer collaboration allows rapid feedback. This allows us to pivot and retarget as needed.
The best accounts receivables team on the planet can’t save us if we’re in the wrong market with the wrong product strategy.
“The Phoenix Project” – Gene Kim
Continuous learning
Agile is designed for complex environments and promotes a culture of experimentation and learning. In complex environments there is a need for responding to change. There is an expectation that development will involve learning and retrospectives.
Improving daily work is even more important than doing daily work.
“The Phoenix Project” – Gene Kim
Does DevSecOps complement Agile?
There are many areas of alignment between the principles of Agile and those promoted by DevSecOps. Both Agile and DevSecOps have strong backgrounds in Lean Software but DevSecOps builds on this with one significant new factor.
The Agile Manifesto was developed in 2001. There is always discussion of whether it has become outdated, but it has continued to be relevant mostly because it is defined at a high level and focusses on value not techniques.
Software development has of course evolved since 2001. One area of huge change is how software is deployed. The Agile Manifesto talks about small batch sizes and delivering frequently. However, the examples are of one delivery every couple of weeks.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Principles behind the Agile Manifesto
With modern cloud-based continuous deployment, we could deploy in minutes and we might deploy code daily or more frequently. Deployment and Operations have become a much more critical part of the value stream, and the ideas of DevSecOps ensure that we focus on including this when we consider “developing software”.
Extend not conflict
DevSecOps does not change the Agile principles, although it may reframe them. Flow, Feedback and Learning are at the heart of Agile. However, it does reinterpret the details and the emphasis. It extends Agile from focussing on the software development flow. We should of course be considering the full value stream and all of delivering value to the customer.
DevSecOps ensures that Operations is included in that value stream. It also focusses on specific practices which a team needs to employ. In that respect it is more like an Agile implementation (such as Extreme Programming) offering a specific set of engineering practices.
The DORA model specifies some key capabilities for DevSecOps. We can split these into areas which align closely with existing Agile priorities (although at a level of detail below the Manifesto) and ones which represent a new focus. In particular, these emphasise the deployment, as well as development, of code.
Many observe that DevOps is a logical continuation of the Agile journey that started in 2001
The DevOps Handbook – Gene Kim
Key factors in Agile
- Code Maintainability
- Empowering teams to choose tools
- Generative culture
- Loosely coupled teams
- Streamlining change approval
- Version control
- Working in small batches
- Continuous integration
- Test automation
- Test data management
New focus in DevSecOps
- Documentation quality
- Continuous delivery
- Database change management
- Deployment automation
- Flexible infrastructure
- Monitoring and observability
- Resilience engineering
- Pervasive security
Good practices
The activities which you are already practicing as an Agile Leader will stand you in good stead for DevSecOps.
Looking at the capabilities in the DORA model, it is clear that DevSecOps brings some specific new areas of focus. These are especially around extending into deployment.
Agile works with cross-functional teams. DevSecOps extends this to ensure that Operations is represented as well as Product. The teams need strong Operations feedback and to use this to learn and build knowledge about how the application performs.
Using the DORA software metrics with your team will help you to assess how you are progressing.
Leave a Reply