In part one of this two-part Q&A we dug into Wes Higbee’s position on instilling a DevOps culture. Higbee, a developer and business consultant, continues his separation of wheat from chaff in the field of DevOps dreams.
DevOps.com: How is automation, which is a focal point for DevOps, also a trap?
Higbee: Focusing on the automation can become problematic if you forget about other things. Something like automation will distract you and you’ll end up having great turnaround times on new features that don’t mean anything to your customers.
DevOps.com: Doesn’t failing fast fix that?
Higbee: Failing fast could help, assuming you have metrics in place that tell you that you’re failing in a way that matters.
DevOps.com: Could you please illustrate an example of isolated devs and ops that serve the given purpose better than combining them would?
Higbee: I have a history of doing projects in the software development space where we had tight collaboration with everybody that’s involved in the process. Users, stakeholders, developers, testers, managers … you name whatever role, people worked closely together. I also have a history of examples where there was no collaboration at all.
A lot of smaller projects end up in this latter bucket where you really just need one person to create a software system for a very specific purpose. They create the system, they deploy it, and then it just has to be supported at that point because it’s not going to be changed thereafter. It serves its purpose. People are happy with it. It’s probably never going to be changed ever again, so the separation there between dev and ops is perfectly acceptable and if you tried to bring together a whole team of people and synchronize them, it would just be a waste of time because the effort isn’t big enough to justify it.
Another example would be pretty much any company that has ops staff but doesn’t do their own development. They outsource their development. Sure, there are situations where a project would necessitate everybody working closely together, but I’m sure there are a lot development efforts that happen in this regard where the dev team is outside the organization so there’s going to be functional separation. They developed software, it’s deployed, and maybe it’s never changed again, so there’s really no need for some tight-knit collaboration.
DevOps.com: How do recommend helping organizations produce rapid results such that they can rapidly move to a DevOps approach successfully?
Higbee: First and foremost, I don’t extol any methodology, so I’m not a DevOps consultant. I’m not an agile coach. I think it’s ludicrous when people put these fads in front of their titles. The thing that I do that makes the difference, that produces rapid results is to make sure that we have a common goal, make sure it’s crystal clear and make sure everybody understands it. It’s like hiking to the top of a mountain. Everybody knows how far along we are. They can measure their own progress. They can flag things if we’re headed in the wrong direction like down the mountain. They can always see the goal. It’s always in sight.
In another example, if you’ve ever gone to an Escape the Room Adventure, everybody is dumped into a room. It’s a group of people who oftentimes are strangers. About 10 people get dumped into a room and the goal in the duration of an hour is to get out of the room. The challenge is set up so it would be pretty difficult to get out in that hour, so if people don’t focus on that goal, then people aren’t getting out of the room.
I’m not interested in how fast we solve each of the individual puzzles, so we don’t measure those things. We just get to work on getting out of the room. That’s my approach to doing business with people and that’s how people get rapid results. Because if you have a crystal clear goal, then you can go to the last hundred years of management philosophy to find the ways you need to get to your final destination. You aren’t worried about the right way of doing things; you’re just worried about the way that works for your specific situation.