DevOps: “Collaboration comes with a cost”
Instead of a very simplistic approach, we need to look for collaboration and interaction patterns that work in different contexts. Collaboration comes with a cost but it produces very good results. However, sometimes it’s better to deliberately introduce a kind of boundary between teams. JAXenter editor Hartmut Schlosser talked to Matthew Skelton at DevOpsCon 2016 about the need for collaboration and what goes into good team structures.
JAXenter: Hi, I’m Hartmut, I’m here with Matthew Skelton at DevOps-Con in Munich. I think you had a wonderful session right now – you talked about team organisation / team collaboration / team structures, and you presented some team topologies. Why is it useful to have a set of different team topologies?
Matthew Skelton: Well, what we found is that there are many different ways in which teams can work effectively together. There are many ways in which teams can be very ineffective when they’re set up in certain ways. There isn’t really one single kind of team structure or pattern for collaboration that works. It depends on what the business purpose is; it depends on what the organisation is trying to achieve. It depends on where they are with technology adoption; it depends on how quickly they’re moving – all sorts of things like this.
Instead of a very simplistic approach, which says “Oh, development needs to talk to and collaborate with operations”. That’s a good starting point. But what we found is that we need to be more specific than that and look for collaboration and interaction patterns that work in different contexts.
JAXenter: So let’s be a little more specific. What would be a good example of team structure, which measures the needs of a company?
Matthew Skelton: That’s a very good point. Let’s say an organisation is trying to discover something very quickly, like trying to discover new technologies. Let’s say they’re moving from virtual machines on AWS to Kubernetes or something like that, then the people building the software or the application and the people who are providing some infrastructure perhaps need to collaborate very closely at that point. That way they can really understand the operational implications of taking on something like Kubernetes for their application.
So, having those teams work really closely together can be really valuable. It can also be useful to not need to collaborate so closely, because collaboration comes with a cost. It’s expensive, but it produces very good results. Sometimes it’s better to deliberately introduce a kind of boundary between the teams. Specifically, that way the product teams can simply rely on a platform and deliver their stuff on top of the platform. There’s less need to collaborate with IT operations at that point, because the hard problems have been solved.
The classic example is pivotal cloud foundry, where there’s a hard distinction between application and platform. The reason that’s there is because the hard problems have already been solved. So, the application people can just deliver on top of the platform. That’s the specific example, to feel the main situation, so we think about different ways of teams and interacting depending on what they’re doing.
JAXenter: So you would say that collaboration is not of value in any situation?
Matthew Skelton: I think collaboration is always valuable. But we need to understand why we’re collaborating and what to collaborate on. Exactly what should we focus on collaborating on? Sometimes it might be better to codify certain things as a service instead.
JAXenter: So let’s look at the broader context. We are here at the DevOps conference, you are talking about team structures, but team structures are not all. What brings life into such structures?
Matthew Skelton: It’s a very good point. Just having a nice team structure carefully designed is not going to give you a kind of effective software delivery by itself. We need to look at the cultural aspects, we need to make sure we’ve got good, sound engineering practices, and that takes some time to evolve. It’s like we need an ecosystem. We need to nurture and care for that kind of culture to make the good engineering happen.
Ultimately, the business or the organisation needs to have a very clear and well-informed picture of what it’s trying to do. Because there are so many organisations that haven’t really validated their product or service idea! And so, when they ask IT or engineering to build something, it’s not clear what we should build because the business idea or the organisation idea is not clear. It’s actually quite a common thing, increasingly for people and organisations who have adopted DevOps, to become so good at the technology part that it actually exposes the business’ or organisations aspect has a lack of clarity. That’s kind of an interesting place to get to.
JAXenter: What would be a good starting point? We have traditional company structures that now want to achieve something. They hear about DevOps ideas, they hear about team topologies – What would you suggest how to start?
Matthew Skelton: The important thing at a start is to pick something that’s small enough that we can gain some traction, but not trivial. We need to get some buy-in from senior management, so that we’re allowed to experiment on this, kind of on-stream if you like. It might be one product, it might be one product area, but we’re expecting to learn a lot from doing that. We’re expecting to not get it right the first time, we’re expected to do some things wrong, but to learn very quickly from that.
Some people of the staff might feel left out, but we need to bring them along by saying “Look, don’t worry, you’re not in this team right now, but our plan is to roll out this approach to you later on. So just wait a little bit, come to the lunch time pizza sessions, learn about what we’re doing, and over time we’ll roll out this approach further and further to other teams.” Trying to change the whole thing at the same time could work, but it’s probably not the best thing for most organisations.
JAXenter: Do you see this as a top-down-process or more as a bottom-up?
Matthew Skelton: There’s a combination of both. We need to enable a very good engineering culture, a culture of learning and safety for experimentation at the bottom and from the bottom up. Sometimes we get individuals who are very aggressive, or people are scared of them, then we need to work out what to do with them. Perhaps off to the side somewhere, but also top-down it needs buy-in and awareness from the management of the organisation that this is something that’s worth investing in. So the combination from top-down and bottom-up is the right way. Often, we want to start small and expand later, rather than trying to do a big bang change. Sometimes that’s needed, but more often than not it’s better to do it in a kind of stream and then expand from that.
JAXenter: Thank you!
This transcript has been edited for clarity.