Little d devops
Tuesday, 26 February, 2013 — devops
Asking “What is DevOps?” is a question I’ve heard some variation on frequently over the last couple of years as it’s blown-up as a career niche. There’s been a counter-movement. DevOps as a term is about as well-defined as Agile is for software development, which brings me directly to my point.
There’s what engineers I work with call “Capital A Agile.” Think dogmatic practice of Scrum, where absolutely everything has been processed out to the hilt:
- Sprints are always n weeks
- Releases are always n sprints
- Sprint teams always have n Engineers and int(n/2) QA Analysts
- The retrospective is always at 3 pm on the Monday after the sprint finished
Process isn’t bad. Defining process is great and on the whole, having guidelines similar to the four above is healthy. What’s less healthy is the word always in each of these. Capital A Agile is a process smell, particularly when additional rules get layered on regarding grooming sessions, and so on.
Conversely, “little a agile,” will probably have less strict process definition:
- Sprints last two weeks
- Releases are two sprints
- We aim to have teams of four to six engineers and two to three QA analysts
- Our standing meetings are …
- All points are renegotiable when the need to be
Keeping with the sprit of the Agile Manifesto, process is important, but not as important as healthy interactions within the team.
To that end, think of Scrum and Kanban as process and planning design patterns. Just as it isn’t smart to force an inappropriate design pattern where it shouldn’t be in software, it’s not smart to force more process than the team requires to deliver what the business needs.
How does this relate to DevOps? Just as Agile practices within a company can ossify, so too can DevOps. Think instead of little d devops, loosely-coupled and evolving best practices for getting developers to think of software all the way through production, indeed of deploying to production as a beginning and systems administrators and infrastructure engineers facilitating an entire team to be able to own what ships, how it ships and how it lives once shipped.