We recently hosted another episode of our Continuous Discussions (#c9d9) podcast featuring expert panelists discussing best practices for mapping your DevOps journey.
Our expert panel included: Ilmari Kontulainen, CEO of Deveo; Mirco Hering, a passionate Agile and DevOps Change Agent; Prashant Kelker, Director at Digital Advisory Services, Information Services Group Inc.; Scott Abate, a certified Agile project management professional; and, our very own Anders Wallgren and Sam Fell.
During the episode, panelists discussed the three major tenets of DevOps: people, tools, and process, detailing their own best practices and challenges within each. Read on for what they had to say!
People: Culture and Roles
Wallgren emphasizes the importance of having a core team. “If you are a large enterprise, then you can’t really afford to have one or two platform infrastructure experts on every single development team. That’s why very frequently in large companies there’s a core team whose job is to kind of run build and tests and keep the conveyor belt going.”
Roles and responsibilities are changing as the speed of innovation increases, says Kontulainen. “I believe that the role of IT is to basically think one step ahead. What are the tools developers are going to need tomorrow? Test those out and provide them even before the developers require them. In a lot of companies, big companies especially, there is a huge problem of this kind of shadow IT which comes from the fact that the IT does not support the needs of the development organization fast enough. That happens because they do a lot of manual work and don’t provide this kind of platform. I believe that the roles and responsibilities are shifting to be more practical in that sense.”
Having top-level support is important, but these leaders must be well-informed, says Hering. “I’ve been in a lot of organizations where I have a conversation with the CIOs and they said, ‘but we should use microservices and we need to deploy 10 times a day.’ I mean, look at what you have; it takes three days to compile your 567 different .NET applications. I think the key to this is you need to have those sponsors, but they need to know what they’re asking for and I think they need to enable people to get on the journey and not just say, 'next month we’re going to be DevOps,' because that doesn’t help.”
Kelker further emphasizes the need for top-down support done right. “Especially in an Agile organization, you need one large sponsor. People don’t want to have the feeling that if they start some grassroots movement that it suddenly gets wiped out or they are going northwest and then they have to go southeast. It has to be top-down. But, I’ve also seen these top-down movements cause frustration sometimes because the top-down movement says, ‘go do DevOps, go get Continuous Development done,’ but they forget that IT is stuck with the last 30 years of legacy environments. So, unless you talk to that SAP guy and tell him how to do DevOps, then in his SAP when he has 11 million lines of add-up code, he is scared of doing a release once in 18 months.”
Abate says, “one of the most important things to consider when building up a DevOps organization, specifically in terms of people, is that you really want to separate DevOps from your development team. Have them be two distinctly different organizations and distinctly different entities. One of the pitfalls I have seen is that when you have a DevOps team that is part of a larger development organization, sometimes you may get some developers in there that may tweak the build process or the automation on the fly. As a result, you lose some integrity around the build and the build scripts. It’s important to keep the development operations organization separate from your software developers.”
Fell explains that it is important to let the people choose their own tooling by using an analogy about camping. “The tooling becomes the platform that enables you to make the change. If you try to go camping with someone and they haven’t changed their mindset from being in a hotel into a campsite, what you want to make sure you have is the right equipment. If you take them out and you have a miserable experience, and there’s water leaking on their face and they’re cold all night, they’re not going to want to do that again. You have to make sure the tooling works. If they have a sleeping bag they like, let them use it. Don’t try and tell them it’s not compatible with your tent. Make sure you are giving the people at least the appearance of being able to make a choice about what tools.”
Process: The Value Stream
Once DevOps is deployed, how processes should change can become tricky, says Kelker. “It’s very easy for IT to get busy with itself. One shouldn’t forget that there is life outside IT. If an IT department has already deployed DevOps, one should have a look at the business department using DevOps. How do you use this speed now? Should you think faster? Should you now use this opportunity to try two new things which you couldn’t earlier? Should you do feature testing or A/B testing? That’s also a change. Everybody is on a journey and if someone is not on the journey, take them with you, because you might forget someone important – like the guys who do the budgeting.”
Fell gives an example of how HPE uses ChatOps to help improve their communication processes and adds on that when communication becomes a part of your process, it can be a beautiful thing. “That’s an interesting part of the process is when the communication mechanism frames your process for you, at that point it starts to become kind of magical.”
It’s important to ask the right question in order to get processes right, says Kontulainen. “Basically I would ask these four different questions: what do you want to achieve? Who can help me in that? How can they help? What needs to actually happen from those people? So, I would start from those 4 variations of questions. I think the essence of questions is what do you actually want to achieve? Base your process on that.”
Abate advises using Scrum. “A very pragmatic approach is use Scrum. Build a backlog that represents your pipeline and, as was talked about, value streaming and prioritize that backlog of your pipeline nodes by the amount of value they deliver. Use your information radiators to communicate your progress to the rest of the organization – what you are working on and when it is going to be ready. Use Scrum for DevOps.”
Wallgren says, “the most common answer I give to most common question – where do we start? – is map out your process. Whether it’s value-stream mapping or a whiteboard or both. It’s like the ‘How a Bill Becomes a Law’ episode on School House Rock. You need to walk through that piece of code, how does the become a feature on a customer’s phone? What does it take to get from that point to that point? It’s not the case that every single person in the organization needs to know every single detail and nuance about how that happens, but it’s probably good if a group of people together know that. It’s so common that no group in the organization has that big picture in their head.”
Hering leaves us with words of wisdom. “My last words are: everyone is on the journey. You don’t have to map this out, you don’t have to spend a month analyzing what your world looks like – you’re already in it. You have been doing things to improve your IT over the last few years, so just look at what’s possible and take the next step. Have some meaningful intention of getting somewhere.”
Watch the full episode here.
Want More Continuous Discussions (#c9d9)?
We hold our #c9d9 podcast every other Tuesday at 10 a.m. PST. Each episode features expert panelists talking about DevOps, Continuous Delivery, Agile, and more. Check out all past episodes and panelists here.
Next time on Continuous Discussions:
Join us for a special #c9d9 featuring Gene Kim and DevOps Enterprise Summit San Francisco conference speakers Tyler Underwood, Paula Thrasher, Jayne Groll, Ashish Kuthiala and Rosalind Radcliffe on Tuesday, October 25 at 11:30 am PT.