There are generous resources for DevOps — online periodicals, trade shows, and opinions galore. In November of this year in Florida, one more was added to the list — the DevOps East conference. However, the show proved to me that putting the label DevOps on something says very little. What matters is what people are actually doing in the development environment.
DevOps East is part of a mix of events put on by TechWell. It combines the Agile Development Conference, DevOps East, and the Better Software Conference into one larger event. It had a registration of around 600 folks, most of which come from Agile and quality assurance backgrounds.
The DevOps aspect of the show resulted mostly in an independent track of courses, and an overarching theme. But quality assurance undertones dominated all conversations. I was surprised by a few elements of the show that did not fit the typical DevOps event.
First and foremost, I heard the word Docker once (and it was when I said it). At an average DevOps event, 60% or more of conversations are about Containers and Docker. And none of the vendors in the Expo Hall were vendors you would find at the larger DevOps specific events. This was an enjoyable change, because several tools (like a change management tool) could have a positive impact in a DevOps ecosystem of tools where the only thing that matters is release.
For the typical attendee, the DevOps concepts around culture and principles are annoying and/or non-existent. That person’s definition of DevOps is tactical. It is the thing that IT team members do and usually involves some form of automated orchestration with tools like Puppet and Chef. This neglects the broader (and in my opinion) more important definition of DevOps, which describes the movement. The movement includes people, processes, and tools — not only tools. It is not something that you do, or complete. It is a journey and a driving principle.
This is so difficult to accept, in part, because principles are not easy to measure or execute. As soon as you start dealing with people, things get messy. At the event, I regularly heard from those who were enthusiastic about DevOps and just wanted to know how to get started — and how to convince their team of its merits.
The event held a session titled "Creating Culture of Quality", which included a discussion evangelizing the importance of quality — not just on the application, but also efficiency. And "Benefiting from Conflict: Building Antifragile Relationships and Teams" made the case that teams can’t be afraid of conflict. If change is needed or expected, then conflict should be expected.
In my own session, I covered the nuances of Continuous Integration (CI), and explained that it is a must on the path to DevOps. I hinted at the fact that environments that have not yet adopted CI can leverage it as a quick win, and create a “Code Cafe” to encourage better collaboration and communication.
Another session that really caught my ear was a keynote on the topic of culture and changes in team dynamics by Elisabeth Hendrickson from Pivotal software. She focused on the story of transitioning her team to faster, smaller iterations. A few great one-liners she had:
“If you are talking about what is going well in standups, you are wasting time.”
“QA is about diplomacy.”
“Test suites are not static — they have to be curated.”
All of her points were strong. The last point is something I have seen often, where test suites are allowed to become stale. In some respects I see this as a quantification of technical debt. However, her first two points included the cultural elements of DevOps in a powerful way.
She had one trick up her sleeve that I really liked, and that was a game where she showed, via sticky notes with a completed set of instructions, what happens to releases when teams are isolated and not allowed to talk, and then what happens when they are.
I have a problem with the over-simplification of culture and hierarchy changes needed to modernize teams. It isn’t as easy as playing a game for some organization. And often it’s “above pay grade” for those who want the change. No matter how much you see the benefits, there is an implication you may have to take on some uncomfortable challenges, like approaching your boss's boss with a new initiative and its benefits. I’ve found that some organizations, given their current culture, are simply not ready for DevOps, and may never be. For individuals ready for change in an organization that won’t, I suggest finding a new job.
The show was a good one — but I believe in terms of DevOps, it lacked some of the more in-depth and mature implementations that you would find in the more entrenched DevOps events.
The current QA focus is strong. It’s one of the most important elements to hold a modern delivery chain together. But this mindset, along with the implied animosity among developers and IT, feeds the problem in many ways.
If you can, I would suggest attending the show next year, but not for DevOps. Attend to hear about how modern Agile shops are taking the next step in improving communication, and on-boarding even better automation techniques.
Chris Riley is a technologist who has spent 12 years helping organizations transition from traditional development practices to a modern set of culture, processes and tooling. In addition to being a research analyst, he is an O’Reilly author, regular speaker, and subject matter expert in the areas of DevOps strategy and culture. Chris believes the biggest challenges faced in the tech market are not tools, but rather people and planning.
