Last week Minneapolis was host to Major League Baseball’s All-Star game, but when they were done cleaning up after the game a group of IT professionals got together to exchange ideas and share experiences about DevOps. It was DevOps Days Minneapolis. The crowd was a highly diverse group of individuals including management and engineers, uncharacteristically roughly equal numbers of men and women, and theorists and practitioners. The mix led to some really great exchanges and discussions with a repeating pattern of emphasizing the cultural significance of DevOps.

This is a passionate community. People that are participating really want to improve delivery and operations of solutions for their companies. However, the lack of the definitive in DevOps means there’s a fair amount of “you’re doing it wrong!” being leveled at others in the community. I myself may be a guilty of doing this a time or two. Here’s just some of the rising debates that emerged across the presentations and unconference meetings.

Philosophy vs. Structure

There was a lot of philosophical discussion. For example, Dan Slimmon talked Conway’s Law—described by Slimmon as “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”—as a force that influences the need for DevOps. Meanwhile, Jeff Sussna presented on how promise theory and its role in delivering continuous service quality.

Likewise, we heard from the team at Target. Heather O’Sullivan & Ross Clanton told us about the pragmatic way they are introducing DevOps across both Dev and Ops demonstrating that it’s possible for large enterprises to adopt DevOps strategies and apply them to deliver faster with higher quality. And Ben Hughes of Etsy described how security fits into the DevOps landscape.

Hence, a good balance of what some people are doing while also a fair amount of looking outside the IT universe for examples of ways to improve.

Culture vs. Process

Incorporated into the ignite talks and some of the Open Spaces there was a heavy dose of this thing called a DevOps culture. Katherine Daniels’ presentation discussed the transformation from system administration to “sparkly DevOps Princess”. Of course, over time we have also heard about Unicorns and horses as a way to describe what looks like a DevOps culture.

But culture is such an overused word. Google reports one definition as, “the attitudes and behavior characteristic of a particular social group.” Are we to believe that attitude and behavior are the most critical element to correct the long standing issues of developing complex systems in a fast moving business universe? Certainly it helps, but there’s a lot to be said about a group of people coming together to accomplish a mission even if they don’t share common attitudes and behaviors. So, perhaps, the ways that we leverage tools and process, such as how you can you leverage automation technologies to remove redundancies and control configuration drift is itself a culture?

Lean IT vs. Dev+Ops

Which leads to the most interesting aspect for me. I had the opportunity to actually discuss some of this with Patrick Debois and asking how he reconciles the Lean IT/Agile approaches put forth by Gene Kim et. al. in the Phoenix Project  and the foundational aspects of DevOps, which is agile for system administration.

The Phoenix Project is often considered the seminal book on DevOps, but it presents a much bigger view than the concept for how agile development processes can be applied in operations. Automation, Continuous Integration, Continuous Deployment, etc., these terms are synonymous to saying improvements on the shop floor in a manufacturer is the same as Lean Manufacturing. Improving Dev+Ops is important, just as improving shop floor processes is, but if you don’t change the way orders are introduced into production, how they are prioritized to meet customer needs, and limit bottlenecks before it reaches the shop floor in addition to controlling them in production, all the automation in the world still won’t guarantee higher quality or more throughput.

All-in-all, the Minneapolis team put on a phenomenal event. And, as an organizer of the forthcoming Chicago DevOpsDays, I am looking forward to being able to deliver as valuable an experience to our attendees.