No Devops? No Agile!

nodevopsnoagile Your agile teams operate like F1 cars, does your DevOps support them?

Would you be willing to take a $10 million dollar F1 car off-roading in the mountains?

I’m talking about some muddy, deep valleys and rock ridges that would make a Jeep Wrangler cry; would you take an F1 out there? Of course not. That vehicle was not designed with that surface in mind. F1 cars need smooth, high-traction roads with broad, sweeping curves and gentle, rolling hills, adorned with grandstands and buckets of ice for the champagne.

Your devops practices put a harsh upper limit on the effectiveness of your agile practices.

Well, your development teams are F1 cars; and how your organization is implementing devops is the surface that those teams run on. Make no mistake, your teams are doing devops. Any time you have a development team who puts things into production, then there is some level of devops happening somewhere. But here’s the real question that you need to answer: Is your devops implementation the Nurburgring or the Rubicon? I can promise that your development team is only designed to run on one of those tracks. More importantly only one of those tracks supports a truly agile team.

I believe that if your teams aren’t doing high-quality devops then you cannot say that they are doing agile. No devops? No agile. Certainly not effective agile. In other words, your devops practices put a harsh upper limit on the effectiveness of your agile practices. Let me tell you a Tale of Two Teams.

Team Purple:

People: All three roles (PO, SM, DT) are staffed by people who have been on the team over a year and are knowledgeable in their roles

Scrum - The team had recently reset their Scrum and returned to core practices, backlog was already well-groomed

Product - New team, they started with zero output and incrementally ramped up

Leadership - The team has the manager’s full support, they understood agile at a basic level

Devops - New team, they insisted on fast deployments early and often

Team Orange:

People - All three roles (PO, SM, DT) are staffed by people who have been on the team over a year and are knowledgeable in their roles

Scrum - They are hitting all of the core events, backlogs are decently-groomed

Product - The team is putting work out at an OK pace, however in the past they have delivered at a higher velocity

Leadership - Team is fully supported by a management team that wholly believes in agile as a better way to do work

Devops - Poor, low quality, big-bang deployments that take the DT away from development work and usually trail actual development by a month or so

As you can see, the major differences between the two teams is not at the personnel or business levels. Both were doing Scrum at a core competency level, both had supportive management, and good backlogs to work from. The single biggest difference was the team’s delivery pipeline, how they performed their devops. Let’s examine that…



Team Purple

Team Orange

Cycle Time (Dev start to Production)

3-4 days, often less, never more than a sprint

10 days, best case scenario, often up to a month


Committed daily

Merged once per sprint

Integration Testing

Tied to commits, fully automated

Post merge, manual, up to three days of testing (!)

Overall testing automation and quality

TDD with deep automation,

Some automation, not aggressively pursued

Feature Toggles




Weekly, any code that was written since last deploy and was ready

Bi-weekly, lagged development by up to 1 month


Determined by the business as a separate function from deployments

Tied directly to deployments, no distinction


Built into the product from day 1, deep Piwik integration

Google Analytics built in, but rarely used

Analytics Review by Business

PO worked closely with sales and marketing to review their analytics and steer the product backlog based on the learnings.

Even if Team Orange had this, their analytics weren’t of quality to support meaningful learning

The DevOps Ways Of Work

Even a cursory glance at the above table makes it pretty clear which team would be the better performing team. Team Purple and Team Orange had very different approaches to the Three Ways of Work:

The First Way - Flow: Team Purple had solid, rapid flow of work from left to right. This allowed the developers to tackle code problems while that code was still fresh in their minds. Team Orange had significant gaps between when the code was written and when it was delivered; with a resultant productivity loss from having to constantly recontextualize themselves.

The Second Way - Feedback: Purple had taken the time to write a full analytics portal which showed meaningful interactions between the code and the customers. Orange could show hit counts and some of the customer’s path through the site.

The Third Way - Learning: Team Purple had set up their business partners with the information needed to develop a learning culture that could pivot decisions based on deep analytics generated by the product. Meanwhile, Team Orange’s business partners had no such insight and relied on a few vanity metrics to make decisions.

Let me restate my argument. Your team’s agility level will be critically limited by how well they implement devops. Team Purple was able to soar because their underlying systems were working in harmony with them. Meanwhile, Team Orange was actively fighting against it’s systems. And losing. Team Purple had multiple members who were selected for performance awards while Team Orange’s management was looking at making roster changes. These two teams are only two examples of many other teams that I have worked with during my years. Everyone of them are examples of instances where devops directly dictated how effective the team’s agile was; both good and bad.

As an agilist, your primary job quality can be strongly tied to the level of devops that your team is running. Remember: This single subject is the primary force that impacts how agile your teams can possibly be. The question for you is: Does your team run on an F1 track, or an off-road track? The answer is usually self-obvious, and not hard to correct.

If you need guidance or training, Allison Agile can help. See the course of upcoming SDP classes in the right hand column or reach out to us for coaching or help launching.

Percent CA: The Hidden Gem of Processes
The Lorax Would be a Great PO!

Related Posts



No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Monday, 25 October 2021
If you'd like to register, please fill in the username, password and name fields.