Recently I’ve been talking to various groups about “technical agility”. That is, the technical aspects of our processes and products that enable us to be “agile” in our software development. I’ve been finding it very useful to borrow terms and concepts from DevOps circles to make certain points. Perhaps unsurprising given how closely related they are, but it adds some novelty to the discussions for those who haven’t been exposed to it yet. I just went through Lisa Crispin’s course on testing in DevOps over at TestAutomationU, and I wanted to take note of two great points I took from it along those same lines.
1. The Agile Acid Test
In this case, Lisa Crispin actually borrows a definition of Agile to describe DevOps, and I think it works as a natural bridge between them in either direction:
Agile teams produce a continuous stream of value, at a sustainable pace, while adapting to the changing needs of the business.Elisabeth Hendrickson, http://testobsessed.com/2010/12/the-agile-acid-test/
While not a verbatim recitation of the Agile Manifesto, Elisabeth Hendrickson makes the point that everything in there can be pulled directly from the principles that the manifesto is based on.
Coincidentally, someone I work with had recently opined that people too readily conflate “Agile” with any number of other ideas (Scrum, Kanban, arbitrary personal preferences) and claim either “this is Agile” or “that’s not Agile” in complete contradiction to the original manifesto and principles. As a result, while prepping for my most recent session on “Technical Agility”, I explicitly went through the twelve principles of Agile to pull out the phrases I could use to help draw the line from Agile to DevOps. What I found was basically a scribbly and unorganized version of Elisabeth’s definition. She put it together much better than I would have.
What I particularly like about Elisabeth’s formulation is how it breaks down into three concrete tests for agility:
- How frequently do you deliver? (“continuous stream of value”)
- Could you continue at this pace indefinitely? (“sustainable pace”)
- How well do you handle change? (“adapting to changing needs”)
This is her “Agile Acid Test“.
Sidenote: “Sustainable pace” is the one of these that I see forgotten most often, but serves a very important purpose. Given any metric or measure, people will manipulate it, either purposefully or not. Sustainability serves as a way of balancing the other two so you don’t inadvertently optimize for a frenetic and chaotic nightmare. Similarly, adaptability makes sure you don’t achieve sustainability through sticking rigidly to a perfect plan.
I’ve been guilty of reading about observability and taking a mental shortcut from that to “monitoring”. There’s a great Venn diagram in the DevOps course relating testing, monitoring, and observability to each other that I recommend looking up. The thing that really solidified the meaning of “observability”, though, was this summary from Charity Majors:
Observability is about being able to ask arbitrary questions about your environment without—and this is the key part—having to know ahead of time what you wanted to ask.https://www.honeycomb.io/wp-content/uploads/2018/07/Honeycomb-Guide-Achieving-Observability-v1.pdf
When I tweeted last week that writing good log messages is an underappreciated art, this is basically what I was complaining about. There’s a real skill in designing your code so that it’s observable in this sense. When I’m writing the code, running things locally, watching logs continuously, I’m in a completely different mental space and looking for different things than when that same code starts doing something unexpected at 3am six months later. While good logging is just one potential ingredient of observability, I know the logging is good when it can stand up to those arbitrary, unanticipated questions.
Next step for me: read the guide on achieving observability that that quote comes from, so I can keep this front of my mind on my journey into software architecture.
Bonus thing: Continuous Delivery Principles
While his book has been on my desk waiting to be read for months, I didn’t know that Jez Humble had described the 5 principles at the heart of Continuous Delivery online. And, what do you know: most of them align almost exactly with some of the language my department uses around our Agile practices. Yet another way of connecting Agile folks to the DevOps world.