Over the past few months I’ve had the opportunity to spend time at one or two DevOps conferences, a couple of Agile conferences and one where both practices were covered simultaneously. There’s quite a lot of discussion around the differences between the two and you can even find examples of when Agile and DevOps are pitched against each other. Try entering “Agile vs. DevOps” in your next Internet search. At the Agile & DevOps West conference in Las Vegas earlier this year we were treated to a live version of Family Feud where The DevOps family went head to head with The Agileists. You may be interested to learn who came out on top, but I’ll save the answer for a little later on…
Is it Really Agile vs. DevOps?
Joking aside, to pitch Agile and DevOps against one another can be terribly misleading, after all our early adopters and practitioners coined the term “Agile Operations” to describe what DevOps essentially sets out to do. It was recognition of a need to provide the necessary mechanics and infrastructure for frequent software delivery on a sustainable basis. The well versed among us know that to be successful in this arena, both share a common set of core values – a cultural belief and understanding around transparency, good communication, ownership and responsibility. You can’t just switch scrum on and expect instant results, you don’t just start up a CI/CD pipeline without some serious hard work up front. In many ways a mindset change is required by the organization adopting these new principals and practices. Done well, the benefits can be outstanding. (Opening address, TriAgile Conference, Raleigh, NC pictured right.)
Looking at the topics and streams set out in the DevOps and Agile conferences it is clear that a lot of time is given over to ways of changing an organization’s behavior and the activities required to get there– and for good reason. Essentially it boils down to triggers, tasks and techniques to create a fertile and healthy environment in which to adopt your new practice, ultimately shaping the culture of the organization. (Family Feud live! Agile & DevOps West, Las Vegas, NV pictured left.)
A few examples of actual session titles go as follows:
"Starting DevOps on the Right Foot"
"Building Successful Agile Teams"
"They Key to a Great Testing Environment"
"Measuring Delivery Performance"
Let's briefly take a look at each of these below.
Nathen Harvey from Google gave an excellent keynote entitled “Starting DevOps on the Right Foot”. He began by describing Westrum’s organizational cultures: (i) pathological (ii) bureaucratic and (iii) generative. Believe me, I don’t fancy working for the first and the second sounds exhausting so I’ll settle for the third, the generative organization. It turns out that these categories provide insights and predictors around just how well IT is going to perform. Because generative organizations are performance orientated, exhibiting high levels of trust, cooperation and transparency they can expect to do best. So how do you go about becoming a generative organization? Start with individuals, then teams, then departments, and build out strong Agile practices. This will cultivate a space in which DevOps can thrive.
So how about those Agile teams? Most importantly, what is it about those high performing teams that drive them? Highly motivated engineers with comprehensive skill sets –check. An ever-present product owner with a deep understanding of the application and its audience –check. So how do we replicate those characteristics across other teams? Lee Eason of Ipeo gave us some pointers in his presentation “Building Healthy Agile Teams”. He was able to drill down to the core of what motivates us and you’ll find a lot of what he was highlighting in Daniel Pink’s excellent book “Drive”. The key is to invest in your people: Offer training, foster responsibility and ownership and strive for T-Shape individuals. Ipeo has built a web-based application to support and track this growth journey called “Tekata.io.” They’ve harnessed the spirit of healthy competition, added elements of gamification and provided individuals, teams, tech directors and management a means to identify skills (and skill gaps), encourage personal growth and better distribute those skills across the organization. (Nathan Harvey, Google. DevOps West Keynote pictured right.)
A typical DevOps or Agile conference will provide the attendees ample opportunities to gain insights into the practices themselves. One session I particularly enjoyed recently was on the topic of automated testing with Eran Kinsbruner of Perfecto. The title of his talk was “Agile vs. DevOps for Continuous Testing”, oh and there’s that “vs.” again! Eran was able to take us through some key quality parameters that an Agile and DevOps culture is always trying to attain. With Agile’s focus on rapid change in order to deliver business value, DevOps attempts to contain the risks incurred by such a process. How? Automation testing, integration testing together with critical coding and architectural best practices. It's important to note that this is the responsibility of all involved: product owners, developers, architects, QA and IT groups and hence there should be no such thing as a “DevOps team”. I was even introduced to the Testing Manifesto during the talk and I recommend any one of Eran’s excellent books on this topic.
Tekata.io from Ipreo: T-Shaped Team Growth App
So how are we doing? I’m not referring to this review but rather, (although I welcome your feedback and comments) how well are we performing in terms of delivery of working code, features and applications? "If you can’t measure it, you can’t improve it.” - Peter Drucker. One of Agile’s key practices is to measure the velocity (or throughput) of a dev team’s delivered business value (in the form of working software features). It helps to understand what a team can handle in a given amount of time and subsequently improve the predictability of when that business value will be delivered. The same goes for DevOps. How do you know how reliable and resilient your software delivery process is? How do you know if all that money you just spent moving to the Cloud, re-training your IT group and purchasing that shiny new set of CI/CD tools has paid off? On several occasions during my conference experiences I heard references to the book “Accelerate –The Science of Lean Software and DevOps” (Nicole Forsgren, Jez Humble & Gene Kim) currently a key go-to resource for me as I help businesses adopt DevOps. In the book they identify 4 key metrics that we need to have a handle on –Deployment Frequency, Lead Time for Changes, Mean Time To Recover (from a failed deployment) and Change Failure Rate. In future postings I’ll go into more depth on these measures and how to get hold of them.
For the most part I’ve enjoyed participating in these DevOps and Agile conferences, particularly the combined ones. If I were to find fault somewhere I would point to the challenge of how the conference organizers ensure that both experienced and new attendees are well served. As identified in the post a lot of time is given over to getting the preparation steps for DevOps in place- it is vital to your success. Being Agile is part of that and in my next post I’ll discuss the tuning of Agile practices specifically for a successful DevOps transformation. Oh, and who won the Family Feud contest? Why, DevOps of course! There was way too much procrastination from The Agileists. Hmmm.
Damian Dingley, Agile Practice Lead, Veracity Solutions