Over the last couple of episodes; I've introduced the concepts of Minimum Viable Product as a way to think about software development to improve your return on investment. I've then introduced Lean and Agile to provide background and backup for why that Minimum Viable Product mind set works. And in last weeks, I introduced the Cloud as an enabler to Minimum Viable Product in practice. In this episode I want to introduce one last term in this set of episodes - DevOps
Or listen at:
Published: Wed, 25 Sep 2019 16:25:41 GMT
Links
Microsoft definition of DevOps
The State Of DevOps report 2019
Transcript
Over the last couple of episodes;
I've introduced the concepts of Minimum Viable Product as a way to think about software development to improve your return on investment.
I've then introduced Lean and Agile to provide background and backup for why that Minimum Viable Product mind set works.
And in last weeks, I introduce the Cloud as an enabler to Minimum Viable Product in practice.
In this episode I want to introduce one last term in this set of episodes;
DevOps
The term DevOps is a contraction of traditional IT teams of Development and Operations.
In their traditional roles, Development and Operations would be siloes teams - dealing with each other through various handoffs.
Traditionally it has been common for a lot of friction to be generated between the two teams. Not least as they will have been incentivised different.
Development will have been incentivised on getting as many features into production systems as quickly as possible. This would drive a high level of change.
Operations will have been incentivised on keeping production systems as stable and reliable as possible. The would drive a low level of change.
Many organisation, through diametrically opposed incentives, put the two team on a direct head on collision course.
Which then obviously produces considerable waste and inefficiencies.
The contraction DevOps is a recognition that those two teams need to acting as a single multidisciplinary team with the same incentives.
As a brief aside; this contraction is currently fashionably way of expressing breaking down of traditional barriers and team silos.
In episode 8, introduction to Agile, I mentioned the terms DevSecOps;
This is a contraction of IT Development, IT Security and IT Operations.
A recognition of those teams acting as a single multidisciplinary team with the same goals.
Since its early inception, I believe that the DevOps has grown to mean something much more.
Personally I like the definition from Microsoft:
"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users."
They aren't talking about just the IT teams of Development and Operations - they are talking about anyone that is needed to deliver value to the end user.
This is pretty much a direct aim as set out in Lean, Agile and MVP. Get all the people you need together to get the value to the customer.
The Microsoft definition also talks about process and products.
And that includes anything that will assist in that goal of enabling continuous delivery of value to the end users.
For example, automation tools would be included in that.
The Department of Defence document I described in the episode 8 specifically calls out automation - or lack of - as a sign that a project is not Agile:
"if manual processes are tolerated when such processes can and should be automated"
Think about this in terms of a production line - you want to automate everything you can for efficiency - and free your people up for intelligent work.
A classic example for this is testing.
Yes you can have an individual repeatedly test a software product every time it changes - using a collection of known test scripts. But if that is a repeatable task, it will generally be more efficient to invest in automating it.
Through various products, you will be able not only run the tests considerably quicker than an individual, they will be something you can run repeatably over and over again without tiredness - at any time you want.
Thus allowing the team to re-test continually.
If manually testing it taking days to complete then the team is unlikely to ask for it very often.
If the testing happens in a matter of minutes, the team will likely run many times a day as then are making changes. And this is what I referred to a "Build Integrity In" when I introduced Lean in episode 7.
By being able to re-verify that the software continues to work as expected, then defects are picked up quicker - and thus considerably easier to resolve - thus having considerable lower impact on the cost of the project.
And it also frees us that individual to do much more valuable experimental testing (what-if scenarios) or helping to train the team on a quality mind set.
For me, DevOps very much has its ancestry within Lean and represents the natural evolution of the work that has come out of the Agile community.
And DevOps comes with a collection of practical process that an organisation can adopt.
In the book, the Phoenix project, DevOps was introduced as having 3 underlying principals, the three ways.
The three ways are:
- First Way: Work always flows in one direction - downstream
- Second Way: Create, shorten and amplify feedback loops
- Third Way: Continued experimentation, in order to learn from mistakes, and achieve mastery
The First Way, flow is every similar in concept to the Lean way of things. It promotes the increased flow of work through the system.
The Second Way, feedback is very much in line with the learning advocated by both Lean and Agile.
The Third Way, experimentation is aligned with Lean, Agile and Minimum Viable Product in the acknowledgement that failure is valuable.
The DevOps Handbook was released at much the same time as the Phoenix Project and intended to provider a set of prescriptions to help an organisation along its journey into DevOps.
Both books are excellent and I will talk about concepts they introduce in further episodes.
Finally in this DevOps introduction, I want to introduce the State of DevOps reports.
The State of DevOps report is the result of an annual survey to monitor the trends and success rate of organisations adopting DevOps.
Its been running now for 6 years, with the last three having obtained a significant level of statistical rigor in its production.
The 2019 edition took input from 31,000 professionals worldwide.
They categorised organisation based on their adoption of DevOps mindset, practices and processes - ranking them from low performers through to elite.
They found that when comparing the elite performers to the low performers, the elite group had:
- 208 time more frequent code deployment
- 106 times faster to deployment
- 2,604 times faster to recover from incidents
- And 7 times lower change failure rate
This all means greater flexibility within their market.
A quote from the report
"We see continued evidence that software
speed, stability, and availability contribute
to organizational performance (including
profitability, productivity, and customer
satisfaction). Our highest performers are
twice as likely to meet or exceed their
organizational performance goals"
I'll revisit the 2019 report in a dedicated episode in the future. But for now I wanted to provide it as evidence that DevOps is a valid and accomplished movement.
I'll provide links to the report in the show notes.
In this episode I've provided an introduction to DevOps, what it is and how it links into Minimum Viable Product, Lean and Agile.
I've also introduced prescriptive aids like the DevOps handbook and statistical evidence that organisations are succeeding through DevOps with the State of DevOps report.
Both of which I will expand on further in future episodes.
In the next episode, I want to recap series so far and then talk about what that all means for the Culture of the organisation.