Is “DevOps” considered an Agile practice? Should someone from operations be included on a Scrum team?
I see DevOps as a “flavor” of Agile, because they have pretty much everything in common. Like Agile development, DevOps focuses on continually improving how we develop and deliver software. Also like Agile, it promotes communication and collaboration between departments and positions, especially between development and operations (known in some companies as system administration or IT) teams (hence the name). DevOps grew partly from the need of many companies to release new software multiple times per day. Automation for deployment as well as regression testing is a must in that type of environment.
Scrum has always called for a cross-functional team that includes not only developers, testers, and business analysts, but system administrators and database experts. My current team has included one or more system administrators and DBAs for the past eight years – long before we heard the term “DevOps.” Our sys admins support our version control, test servers, continuous integration, and delivery to production. Our DBAs support our test database schemas, and database changes needed for each sprint. Everyone in Ops works hard to make our production system reliable, secure and fast.
Since we’re an Agile team, we developers and testers have all gained some competence in Ops areas. Anyone on our team can go set up a new build process in Jenkins, or add a column to a test database table. Still, we depend on Ops to keep improving our ability to deliver high-quality business value to production as often as needed. And, they don’t limit their efforts to their traditional areas of expertise.
Recently, one of our sys admins, Tony, who is also a Java programmer, led our team’s effort to evaluate and select a new GUI testing driver and framework. When the first framework we tried didn’t meet our needs, he paired with me and with another tester to try out others. I doubt that this is in his job description, but like everyone else on the team, he can switch positions when needed.
When our team was smaller and Tony was our only sys admin, he trained us how to respond to various hardware and network emergencies in case something happened while he was out of the office. To test our knowledge, periodically he’d come up to one of us and say, “There’s a fire in the server room,” and we’d have to go take machines down or boot them up as appropriate. We sometimes had to use this knowledge to, say, get printers back on the network. Luckily, the day there actually was a fire in the server room, Tony was in the office.
Learning goes both ways. For example, when one of the DBAs needs help understanding business rules or a complex data model used by our application, I can explain, and pair with him to look at issues. When we had trouble integrating one of our open source test frameworks with the continuous integration, I got help from its developer community, and we were able to get it working in-house. We’ve all worked together to fine-tune our process to release to production and make it seamless and fast.
The Whole Team approach requires that everyone needed to produce and deliver the software work together continually. This collaboration must be even tighter with more frequent or even continuous delivery to production. The next time your Scrum team conducts a retrospective, identify your biggest problem. Maybe testing lags behind coding. Then ask yourselves, is there one additional role or position that could help with that problem? If the issue is inadequate test environments or slow feedback from a dodgy continuous integration process, you may need more Ops on your Dev team. “Quality” includes many diverse criteria and our software teams need diversity to deliver a high-quality software product.
Dig Deeper on Topics Archive
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting. Continue Reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates. Continue Reading
Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good. Continue Reading