Key Takeaways from Continuous Discussions (#c9d9) Episode 53: Mapping Your DevOps Journey

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 – 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

Delineation of DevOps and development teams is about the discipline for the pipeline and software delivery process @samueldfell #c9d9 #IT pic.twitter.com/16AQf1WYxq

— CloudBees (@electriccloud) October 4, 2016

Hand offs are not only happening between dev and ops but the partners involved with them as well, per @prkelker #c9d9 pic.twitter.com/goKZfDj6G2
— CloudBees (@electriccloud) October 4, 2016

Per @anders_wallgren - trying to do a #DevOps transformation when there is active negativity in the enterprise is very difficult #c9d9 pic.twitter.com/CKjKwFxGoc

— CloudBees (@electriccloud) October 4, 2016

You need to have a sponsor, but they need to know what they are asking for & enable people to get on the #DevOps journey @MircoHering #c9d9
— CloudBees (@electriccloud) October 4, 2016

Wallgren

emphasizes the importance of having a core team: “If you are a large enterprise 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 conveyer belt going.”

Roles and responsibilities are changing as 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, and testing those out and providing 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 ten times a day.’ I mean look at what you have, it takes 3 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 North-West and then they have to go South-East. 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

“One of the most important things to consider when building up a DevOps organization, specifically in terms of people, is 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 and 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.”

Technology: Infrastructure and Tooling

Because #mobileapp delivery is so fast, leaders are more apt to believe in and drive #ContinuousDelivery |@ScottAbate #c9d9 #DevOps pic.twitter.com/A8b02IyH5l

— CloudBees (@electriccloud) October 4, 2016

Today, when the vendor leaves you have no control over how to deliver your own #applications , per @MircoHering #c9d9 #DevOps pic.twitter.com/16k7lV5f0Q
— CloudBees (@electriccloud) October 4, 2016

Start with the very basics with software delivery tools and infrastructure - version control, integration, etc. | @kontulai #c9d9 #DevOps pic.twitter.com/oqPM19maGo

— CloudBees (@electriccloud) October 4, 2016

Coming from a mobile perspective, Abate recommends using cloud-based and elastic tools: “Focus on the tech stack. I would definitely recommend cloud-based over virtual tools and also elastic tools. We often have the need in mobile to spin up new environments very quickly to test out a specific scenario. It’s really tough to do in a physical environment, but virtualized with all cloud-based tools is much easier to accommodate that. It’s definitely advisable to stay in the cloud and make sure you have elastic resources.”

Kontulainen provides self-service platforms for his development team: “In general, from the tools that are expected, I will start with the very basics - like version control, access management tools for different tooling, issue tracking, documentation, and then the very basics of Continuous Integration and provide them in such a way that the development teams can use them when they want and how they want. Providing this kind of self-service platforms that the development teams can then utilize has been very beneficial.”

Tooling can become incredibly convoluted, especially in the enterprise, remarks Kelker : “We're in the enterprise on the buyer’s side and the dialog that we have is a little different, it's - Do I need a system integrator who brings his own tooling? Or, do I need to get the tooling and then bring the system integrator in? What happens when the system integrator leaves? Does he take his tooling with him? And then I'm lost. What we're saying is a very interesting topic being pulled aside from two topics. A tooling pro is saying - I'll give you this Platform as a Service. Now you just went from a tool to a service, and then you have a system integrator who is essentially a service, but he has brought all these heuristics and he has actually gone from a service to a product.”

Wallgren “DevOps is the ability to choose the speed at which you release your software. Much more so than having your people, processes, tooling and culture dictate the speed at which you deliver software. It’s the same with QA. The goal of QA is not to ship with zero bugs, the goal is to ship with a known number of bugs.”

Hering stresses the importance and difficulties of having an independent infrastructure: “Now we're in a world where we have more tools that are easier to use and as an organization we might choose to go with Amazon and have a whole bunch of CloudBees tools, but then if I at some stage decide that someone else is better, I have the same problem. I've used so many of these cool tools that Amazon provides and now I'm going to move to the cloud and they don't have these tools, what are we going to do next? Building enough of an infrastructure and platform that is independent is actually really important, but it's difficult.”

Process: The Value Stream

"Value stream mapping is how DevOps looks on the ground." @prkelker #c9d9 #DevOps #business pic.twitter.com/XhUGEwYFBk
— CloudBees (@electriccloud) October 4, 2016

"So much of process is communication" @samueldfell on #c9d9 #DevOps

— CloudBees (@electriccloud) October 4, 2016

A pragmatic approach is to use #Scrum - build a backlog that prioritizes your value stream | @ScottAbate #c9d9 #DevOps pic.twitter.com/xPw1qoxq0X
— CloudBees (@electriccloud) October 4, 2016

"Don't automate a bad process" @anders_wallgren #c9d9 #DevOps #ITOps #SoftwareDevelopment

— CloudBees (@electriccloud) October 4, 2016

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 4 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 to use Scrum: “A very pragmatic approach is use Scrum. Build a back log that represents your pipeline and, as was talked about, value streaming and prioritize that back log 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, when it is going to be ready. Use Scrum for DevOps.”

Wallgren “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 white board 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.