Webinar Recap: Bridging the Gap Between Dev and Ops
Webinar Recap: Bridging the Gap Between Dev and Ops
Gene Kim and Electric Cloud's Anders Wallgren talk about bringing dev and ops closer together in their latest podcast.
Join the DZone community and get the full member experience.Join For Free
On a recent DevOps.com webinar, Gene Kim, founder of IT Revolution and co-author of "The Phoenix Project," "The DevOps Handbook" and "Accelerate" and Anders Wallgren, Electric Cloud CTO, shared concrete tips for bridging the gap between Dev and Ops. During the discussion, each shared new trends in organizational structures, the importance of value stream mapping, tips for pipeline monitoring and tracking, and much more.
Continue reading for some of the top takeaways!
Wallgren speaks about the dichotomy of developer and operations teams and why the tension between the two exists:
"On the developer side, it's really about creating new technologies, new features, experiment, move fast, change the tooling as new tools become available and are easier and better to use, etc. The motto for Dev is change the status quo, because we need to do more releases and features. Whereas on the Ops side, it's more about maintaining the status quo. The goal is very much to keep the lights on and keep the money flowing in, and kind of be the engine for the company." Wallgren goes on to explain how DevOps is helping operations teams handle the throughput and constant change from developers.
So, how do we bridge Dev and Ops and all the other organizations within a company? Wallgren explains that it comes down to understanding that we're really all working towards the same goal:
" The overarching goal for everybody in the company is to provide value to our customers. And then, in return for that value, you get money or respect or fame or, whatever it is that we're looking for. Knowing and understanding that there is this shared goal of what we're trying to do and that we aren't safely siloed in our own organizations and don't have to care at all about what comes before or what comes after is a very strong belief in the DevOps community as well as shared visibility. For all these different stakeholders and organizations to come together and smoothly and efficiently and repeatedly interoperate and deliver value to our customers, that involves everyone. It is a development problem, it's a quality problem, it's an operations problem, all the lines of business have to participate, even HR, finance, and partners, and so on have to get involved in this."
Referencing the image above, Kim explains the organizational evolution to Model 3:
"What we're often seeing is the shift to Model 3 - product orientation or cross-functional organization. So, beyond technology, we typically do this when we want to optimize for quickly delivering value to customers. That means that any group can independently deliver value to customers because they have all the disciplines within their teams. They don't need to beg, borrow or steal resources to do things that customers demand. By pulling people out of the silos, they have genuinely shared goals. The idea is that you get almost all of the benefits of model three without having to reorg everybody."
Kim goes on to share some recent work about to be published around ticketing systems and makes a resonating statement:
"It is my big learning share that it doesn't really matter where you are in the ticketing system, whether you are the producer of tickets, the consumer of tickets, or the doer of the tickets, when you're trapped in this Byzantine labyrinth, it is sometimes a very joyless activity."
Wallgren emphasizes the importance and value of value stream mapping:
"Value stream mapping helps you figure out, "what are we doing?" How much of this is productive work and how much of this is just wait states where there's three hours of work being applied here but it's three days of duration? Can we make that not be three days and take the wait states out of the system? I think part of the reason value stream mapping is so valuable and so useful is, it gets all the collaborators and all the stakeholders literally in the same room to walk through from when code gets checked into how it makes it into production."
When modeling your pipelines, there are many things to take into consideration, but the more your pipeline looks like your value stream, the better. Wallgren goes on to share:
" If you have your pipeline put together based on your value stream and you've coded it, you now have documentation of how you do things. And if you then show that you ran that pipeline and that's how you built and qualified, tested, released your code, then that is the proof that you do what you document."
"Tisson Matthew as an engineering director within the transportation department had to cut across over 300 functions across the Amazon enterprise. It was one of the most heroic stories just because of the level of leadership and political sophistication needed to do that. There was no central planning function that could make sure that Tisson got what he needed. Basically, he was having to work with 300 parochial selfish people who only cared about their area and cared less about this new idea that's been kicking around. So essentially, he had to use political skill and his Jeff Bezos card to emphasize that this is the most important initiative and they would use that to scramble the priorities. I share the story because I think we're moving towards this product orientation [Model 3 above] where teams are more capable of delivering value to customers themselves. But for something like Amazon Prime Now, no one team could deliver Prime Now. They had to cut across essentially all of Amazon."
Helpful hints on pipeline tracking from Wallgren:
"If we work on integrating data tracking as part of our pipeline efforts, then it becomes a very powerful tool for collecting and then reflecting on a lot of the interesting information. When you're thinking about pipeline tracking, try to automate as much of the collection of data from the point tools as possible and the environments and all the pipeline jobs that run through it, whether it's a build CI type pipeline or release pipeline or what have you."
Architecture is at the root of productivity and joy in the day-to-day work of software delivery, explains Kim:
"These days what the findings show is that architecture has everything to do with how people do their daily work. Is it done on demand or are we hamstrung by ticketing systems? Everything should be done on-demand, self-service, not through ticketing systems and waiting two weeks, four weeks, six weeks to release. It's those characteristics that allow us to get immediacy and fast feedback. Those are the conditions that allow us to get focus and flow not just in the Lean sense but in the sense of these are the conditions that allow us to have a mental state of effortless productivity and joy."
Believe it or not, these tips and insights above don't even begin to scratch the surface. To gain more invaluable information shared from Gene Kim and Anders Wallgren during the webinar, watch the entire replay here.
Published at DZone with permission of Anders Wallgren , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.