Are You Agile Enough for DevOps?
One of the biggest buzzwords in the industry lately is DevOps. We all know by now what DevOps is intended to offer, and most organizations are looking for at least some subset of the promise of a continuous delivery flow and the power of “pulling ops into the room”. But can we really do that if our own job of becoming “more agile” is still incomplete? Let's explore for a moment what we even mean by agile. I recall back in the early days that agile discussions were about how to turn around features quickly by breaking them down into smaller “bite sized” chunks, delivering those, and then determining where to go next based on that feedback. We invented cool things like user stories, and utilized mechanisms like short iterations and daily standups to move closer to this fast-paced, turn-on-a-dime philosophy toward software development. We discovered, without a doubt, that this was a better way. One major portion of these methods was a set of technical practices that would enable the teams to write software in a way that would support such a nimble environment.
So, where are we now? We have discovered that doing things in these small chunks is hard. It is counter intuitive too. We want to look at things in big picture terms. The question I used to hear the most was “how can I manage a portfolio this way?” Now that question has been turned into “how can we scale this?” My answer to each question is the same: Don’t. The reason we moved to the smaller chunks and stories is because the “big picture” approach doesn’t work. So finding ways to shoehorn agile methods into “scaled” or "Big Up Front Agile" is a waste of time and energy. Rather, let's learn how to do the real agile methods better, and reap the well-known benefits.
What does this have to do with DevOps? Hang on, we’re getting there. One of the things that got set aside along the way was the focus on practices that enable agility. Test Driven Development (TDD) was at best assumed it would magically happen, and more often set aside as something “we’ll get to once we get all of our release trains and architectural runways laid out”. In other words, never. A possible metaphor is saying “I will start exercising once I’m in better shape.” You have to do the technical practices first, or the rest is just a waste of time. And this is where DevOps comes into play.
DevOps is most closely associated with the idea of Continuous Delivery. The idea that we can at any time build and deploy the results of our development efforts allows us a huge amount of flexibility with deciding what software gets delivered and when. The tools that help us, whether it be for visualizing and orchestrating the moving parts of build, test, and delivery, or the tools that automate these parts, have reached a level of maturity that allows us to move forward. The question remains, does your team have that same level of maturity?
If the extent of your team’s agile mechanisms is identifying “portfolio items” that will be broken into stories that will then be scheduled into sprints, do NOT try to go straight to DevOps. Learn how to truly embrace TDD, both at the Unit Test level and the Acceptance Test level. Once you feel comfortable with that, you can move to Continuous Integration and then Continuous Delivery and DevOps.
If you are doing “some TDD” and daily builds, you are getting there, but ramp up the tests first. You might be inclined to at least get some of the cool DevOps tools into place, but I highly recommend getting your TDD house in order first. Time and energy are finite, so let's spend them appropriately.
If you still have a “change control board” of some type that controls when a merge happens, you aren’t ready for DevOps. Ensuring that your tests are in place and automated will help build the trust necessary to avoid constructs that are explicitly designed to slow the development process down. Building habits of checking in code and building several times a day will allow us to catch what errors might make it through quickly, and with a much smaller delta between check-ins to identify where the errors might have come from.
So, am I being somewhat absolutist here? Absolutely. Rather than taking our agile practices halfway there and then saying “hey I know, let’s do DevOps now”, work on making agile everything it possibly could be. Once you feel comfortable with your automated tool stack and delivering every iteration, then move to Continuous Delivery and DevOps.
