Helen Beal: “DevOps is not just one person’s job”
JAXenter editor Gabriela Motroc talked to Helen Beal, Head of DevOps at Ranger4 and speaker at JAX DevOps 2017, about how DevOps propagates through an organization. She explained what companies should do after they’ve decided to embrace DevOps and how the change should occur.
JAXenter: Hi Helen. How were your sessions?
Helen Beal: They were both great, thank you. So the first one I did the correlation between DevOps and Holacracy, and I just did the second one about how DevOps propagates through an organization.
JAXenter: So let’s say a company decides to do DevOps, whatever that means for them. What is the first step, what should they implement first?
Helen Beal: We would not recommend implementing anything first. What we would recommend doing first is baselining their current state. There are lots of maturity matrices, lots of people like us out there that can help people do that. So we would recommend some kind of assessment that should have three goals.
The first to baseline the current state, the second to articulate the desired future state, and the third to define the roadmap between those two states. So that’s what we always recommend starting. I’m trying to make a sprint project, so the transformation itself doesn’t fall into the waterfall trap again of doing it in steps but actually think about it, if you like injecting iterability into your capabilities and organization.
JAXenter: I see. And how should the change happen, bottom-up, top-down, both, neither?
Helen Beal: Bit of both. DevOps is a kind of a grassroots movement, so it’s quite bottom-up. Most organizations have some kind of hierarchical organizational structure where layers of authority and power exist. Change only happens when there’s executive support.
JAXenter: And are there perhaps any tools that we can use, that the company can use to make sure they don’t make mistakes when they are doing DevOps?
Helen Beal: Yeah, so there are a lot of maturity motors out there. So we have slots that we can use, slots available out there, so that’s a tool from a kind of organizational pattern perspective. There are some quite specific automation tools that we think can help early so we would normally do things like recommend people process tools, but there are some tools like particularly ditched performance management, such tools like Dinotrace or AppDynamics. If you use them you can uncover lots of kinds of endemic problems in your applications, without sending yourself down the path that you can’t return from. Another tool if you like is “The Phoenix Project” game that we have, so serious play, and it’s based on the book by Gene Kim, George Spafford, and Kevin Behr, and developed in partnership with our gaming works who are very specialist gaming development partner based in Amsterdam and you basically get twelve people in the room and they all take a role from the book and they play a few rounds and they have to influence the share price and the revenue coming into Parts Unlimited which is to come out. So it’s a fun way
Another tool if you like is “The Phoenix Project” game that we have. It’s based on the book by Gene Kim, George Spafford, and Kevin Behr, and developed in partnership with our gaming works. You basically get twelve people in the room and they all take a role from the book and they play a few rounds and they have to influence the share price and the revenue. So it’s a fun way to learn basically.
JAXenter: Sounds exciting! But how can we make sure that we don’t create yet another silo, because this is what we want to prevent, right?
Helen Beal: Yeah, so the most common pattern for creating another silo is to create a DevOps team, which is okay, as long as people consider that’s one step towards evolution. DevOps is not just one person’s job, it is everybody’s job in the organization and DevOps needs to be seen as an evolutionary transformation journey where every human in that organization understands and acts on the underlying principles.
JAXenter: And how can we make the cultural changes stick? Is there a way?
Helen Beal: It’s tough. I think it needs to be understood from the start that changing behaviors takes time. So if you think about things like muscle memory, you have to repeat the same thing over and over and over before it becomes kind of ingrained or a habit in everything that we do. A typical kind of a problem use case that we see is people trying to adopt Agile, and Scrum is often said to be easy to learn, but difficult to master. So what people tend to do is get some prototypings, some Scrum Masters, write product backlog, get the sprints battles and run some sprints, and they might get their coaching towards the start, it’s very easy to fall back into waterfall ways or forget to do daily stand-ups.
People came to talk to me yesterday about what kind of hickups their Agile transformation is going through and I asked them about daily stand-ups and they just weren’t doing them and they were really essential part of the discipline of doing Agile and doing Scrum.
JAXenter: I see. But I would love to hear more about smart failures. What are they and how can we deal with them, what can we learn from them?
Helen Beal: Let’s just go back a couple of steps. I mentioned things like where do we start with DevOps? I’m doing things like baselining a current state and when we do that one of the things we do is baseline people’s current cultural states who actually quantify their maturity from the cultural perspective.
One of the questions that we ask people is how they feel about failure, and most people are quite of scared of failure, but in DevOps we take a different principle, we must embrace failure because embracing failure proves that we are learning and we are experimenting and willing to try new things.
Some organizations that we work with have an annual price that they give to the worst project, so they are actually celebrating the fact that people try to do something that just went really badly but at least they tried and that is the really important thing. So when we talk about all that it’s like, obviously there is a lot of fear in organizations, they have critical systems but I don’t want to introduce failure for failure’s sake because that could cost businesses a lot of money, a lot of reputation. Some businesses that have had failures nearly cost them their entire livelyhoods in the past. So what we want to encourage is a culture where people have experimentation and aren’t afraid to fail. We also need to create a system arround them that means they are protected from failures as much as they can.
So these could be different things: it could be an early warning system (so I mentioned digital performance management earlier) so things like Dinotrace could people give a preemptive warning that something is coming and an application is failing so it gets the chance to either move to a low balance or isn’t ultimated or another example of an way to do some failure is to have an automated deployment system we you could immediatly redeploy the last known good state and therefore get yourself out of trouble. Another way of doing it is to actually test yourself using things like Chaos Monkey, to break things on purpose to practice what will happen if there is a disaster of some sort.
JAXenter: It’s good to have a safety net, right? One final question, it’s a bit general, but how can we become DevOps enablers?
Helen Beal: It’s very promotional, but we have been partners with the DevOps Institute and we deliver their courses. They do have a DevOps foundation course which is a really good way of getting certified early and which helps you learn how to do DevOps and then evangelize that.
JAXenter: Thank you!