Our first webinar in this series will focus on DORA’s 2018 State of DevOps report and Outsourcing.
Date: 18th September 2018 | Duration: 54:40
Welcome to the first DevOpsGroup webinar. I’m joined today by James Harvey and Raj Fowler; the topic of conversation today is outsourcing. So, we’re here, off the back of the State of DevOps report this year, we’re going to take a look at how outsourcing is impacting high performance I.T. Like I said I’m joined by James and Raj, both of you have fairly strong views on this topic, and my job is really to give us a quick overview of what was said in the State of DevOps Report, and how it leads into this conversation on outsourcing.
We’d like to keep this reasonably informal so please feel free to hit us up with any questions in the in the Q and A box as part of the Zoom call. I don’t expect to get through my four or five slides without either Raj or James interrupting me, so we’ll see how we go on that front.
For anybody who’s not familiar with the State of DevOps Report, or the Accelerate: State of DevOps Report, to give it its full title, this is a research project which has been running for about five years now it’s headed up by Dr Nicole Forsgren along with Jez Humble and Gene Kim and the team over at DORA. And it attempts to analyse the industry and look at how DevOps patterns and practices are impacting the abilities of teams to perform and to reach what, up until now, they’ve referred to as high performers and now we’re actually introducing this concept of elite performers.
So, it’s an incredibly in-depth report there’s lots of science behind it. If you haven’t read it, I strongly recommend it. But for those of you who haven’t to give us a little bit of context here’s my takeaways from this years’ State of DevOps Report.
The first thing that comes out as you read the report is that DevOps really does make a difference. So, the organisations that are working in a DevOps way are seeing benefits to organisational performance, and this organisational performance is being applied regardless of industry.
So typically, we’ve gone into organisations and we’ve heard those famous words “that can’t work here”. What we’re seeing from the State of DevOps Report is that these patterns and practices can drive high performance, irrespective of industry sector, irrespective of whether or not you’re highly regulated or not, and also irrespective of whether or not you’re for-profit or not for profit.
One of the things that changed this year in the State of DevOps report is they used to talk about I.T. performance, and there was some, some people would comment that that was very software development focused. What they’re now doing is they’re now looking at a new construct which they’re calling software delivery and operational performance, or SDO, which includes both software development delivery and operations. And it gives us a much broader view of how well organisations are performing through the whole lifecycle of delivering application software into production and operating that. It also helps us to draw a distinction between the software delivery and operate functions and other services, things like service desk.
One of the things we’re seeing, I mean if you look at the number of high performers that we’re now seeing, 48% of teams are now regarded as high performers. That is up from last year. So, it shows us that as an industry we are getting better. I think if you drill down into that 48%, what you’re seeing is that throughput instability are no longer seen as a trade-off. So those teams are they’re delivering more change and they’re doing it more stably. So, gone is this idea that we can be fast, or we can be stable, but we can’t be both. The high performers group is growing across the board.
So the other thing that that’s telling us is back to that first point that we made, that DevOps is applicable across all industries. That excuse, that like I said earlier, it can’t work here really, it just doesn’t hold up anymore. And if you want to see what excellence looks like in our industry, that’s where the seven percent are, that subset of high performers fit in. They’re the people who really are pushing the boundaries of what is possible and what good really does look like for an organisation.
One of the things that we are seeing though, is that the gap between the high performers and the low performers is now starting to get wider. As more organisations move into that high-performance bucket there are unfortunately some organisations who are getting left behind.
So, they were key takeaways when I read the report. In terms of the key findings from a statistical perspective, SDO performance drives organisational performance. So, productivity, profitability, market share, and customer satisfaction all measures which are going up for teams who will have strong SDO performance capabilities. Interesting, the first year that the State of DevOps report has really looked in any detail at Cloud. And what they’re saying is that doing Cloud is simply not just good enough. You have to do cloud right. So, you have to be leveraging the true capabilities of Cloud platforms, in order to see the real benefits. As a bit of a teaser, we’ll probably get to this at the end, but one of our next webinars we’re hoping to dig into that a little bit more, in a little bit more detail.
Another interesting stat that came out was how high performers use more open source and expand on open source software, much more.
Today’s topic of conversation, outsourcing, has been shown to be a challenge that needs to be understood. So, we’re going to dig into that on today’s call.
And then finally we talk as an organisation, certainly the three people on this call talk an awful lot about culture. One of the things that this year’s report hammers home is those key technical practices definitely drive performance. So, DevOps is not all about technical practices, but they remain incredibly important. Things like monitoring and observability, continuous testing, database change management, shift left on security, are fundamentally important to any organisation that’s looking to go on this journey.
So that’s what the report told us, so what does SDO performance look like? The report shows us how the low performers pit against those elite performers. So that subset of high, all the numbers that you want to be driving up so deployment frequency, lead time for change, time to restore, and availability are all significantly higher in the elite performers. Probably the most interesting one here, for me, is that if you look at the change fail rate, elite performers to low performers, low performers are seven times more likely to introduce problems when they put an application into production. They are over two and a half thousand times slower to be able to recover from that incident.
And if we look at actually what that means for teams, and this helps you to see where your team might sit. We’re talking here about low performers whose time to restore the service is averaging between one week and one month. And in reality, for a number of organisations, that can be an awful lot longer. So, this was useful, and it comes out every year, and I think it’s really good for teams in an organisation to get to look at where they sit on that spectrum, from elite, high, medium, and low. And there are some real clear benchmarked areas as to what teams should be aiming for.
The other thing that I find particularly interesting about this, as a means of measuring, a lot of organisations that we talk to will say things like “we don’t have that data”. “We can’t measure that.” “We don’t know that.” You see that when DORA do their analysis they’re looking for people to give them data which is in their particular range. So, the time to restore in elites is less than an hour, in low performers, it’s between one week and one month. For most people, and most organisations can answer these questions to that degree of accuracy. So, the key takeaway for me, when starting out on that DevOps journey, is for teams not to worry necessarily about what that degree of accuracy is but just start measuring.
My final point I think before I hand over to Raj. The State of DevOps report this year, they called out this J curve which, for anybody who’s involved in change, will have seen this before. But what they’ve done here is they’ve overlaid some of the patterns that we see in DevOps transformations. The thing that jumped out for me is that change is really easy to start, but really hard to complete. And if we go back to those high, elite, medium, and low performers, 50 percent of the teams that we’re looking at, at the moment, are either about to drop into that trough of disillusionment or are already there.
So, we need to get into these things with our eyes open and know that it’s really hard. There are some quick wins to be had. There’s some automation that these low performing teams can put in place. But once you get to that point of medium performers, where we’re seeing much more manual work than we are in the low performers, there has to be this absolute relentless focus on removing technical debt and carrying on without automation. And if you trust in what you’re doing, trust that you’re working on the right things, you will eventually come out on the other side of that transformation. Into that high and elite performance bucket.
So that was really all I had to say off the top of this webinar before I hand over to Raj. If you haven’t read the report I strongly recommend downloading it. It’s Available from the Cloud platform online site.
If you are interested and you want to dig a little bit deeper into the research and the science, the report was preceded by a book again authored by Nicole, Jez and Gene. Which talked about what they’ve learned through the previous four years of the State of DevOps reports, and also talked about some of the science behind it and helps to provide some practical applications for how you can use these things with your teams.
So, they were my thoughts Raj, James anything that jumped out of the report when you looked at it?
I mean the only thing for me is there’s obviously a ton of super important information here, but it was reassuring to again see that culture is still a key driver of DevOps performance. Certainly, on the Academy, we often talk about culture as not just being a vital ingredient to any DevOps success that you may have. It’s impossible to achieve any sort of technical excellence without the right culture, having the right culture, and we’ll explore a bit of this later on.
But I mean having the right culture ultimately drives a lot of the good practice, and things that come out in this report, as to what actually separates the excellent from the medium. Things like having teams being fully autonomous, breaking down the silos that exist in the organisation.
So, it just reinforces the message, I think, that we firmly believe in. To get this stuff right you have to build the foundations on a very very solid culture and help nurture that culture over time. And I think that was probably again the biggest takeaway for me. It’s often easy to get lost in the exciting technical advances, or the different team structures you can try. But actually, it comes down to have you harnessed the right culture in the organisation to help this stuff bed in, in the long haul?
Thanks, James. Raj, anything that you wanted to hint at before we dig into outsourcing?
So yeah, I recently read the accelerate book. I found that to be really interesting. It brought a lot of life to the Accelerate: State of DevOps report this year. So, for those who haven’t read the book it is really worth doing and then the outcomes that come from the report make a lot more sense.
The thing that really stood out for me was the section is called ‘why DevOps matters’. It’s really clear to see that with five years’ worth of research into this subject, 30,000 plus surveys have been done, survey responses. There’s a real correlation now between high performance organisations, not just high performance I.T., high performance organisations and DevOps. DevOps enables, through culture and technical practices, high performance I.T. And high performance I.T., which has now been badged as service delivery in operation, makes a significant impact on business performance. And I think this is a statement in there that says intuitively we knew that that was the case. Now there’s enough statistics behind this to the point where the high performers and the elite performers, who really embraced this philosophy, are accelerating, and the gap between those low performers and high performers is extending.
So, this is a wakeup call, I think, this report for low performers, medium performers. And again Ed, you’ve just mentioned there how you can assess yourself against those criteria. It is time for people to wake up, smell the coffee, and recognise that there’s a movement here that people are going on, and it’s really really impacting business performance.
OK, so I’m going to talk now about the impact of sourcing. So as Ed said, outsourcing is one of the areas that negatively impacts the performance of the team. The State of DevOps report has a number of these diagrams, and these diagrams show that the positive arrows they show something positively impacting software delivery performance, and ultimately organisational performance. And occasionally you see an arrow with a negative symbol in the middle. And basically, what this means is the outsourcing, and in particular functional outsourcing, negatively impacts software delivery performance.
That’s an important thing to think about. A lot of organisations have maybe development, maybe testing, maybe operations outsourced to different organisations, and then that results in things like handoffs. It results in batching of work. So, what that means is you might have a number of critical and high priority items that you need to deliver to production, but they’ll get botched with low priority or low-value features and due to the nature of the handoff.
And so, what does that mean for organisations? How can they break away from that cycle? Well rather than having that functional outsourcing, organisations may adopt to outsource the whole product. Particularly if they can find somebody who’s got that lean product management, employs DevOps practices, where they can deliver early, often cadence of features whilst maintaining the stability of the product. I think we see more or more SAAS service providers are providing that service to the clients. But the other thing is if the product is strategic to your organisation, if it’s really important to you, and has a direct impact on the performance of the business, more organisations are insourcing their software delivery and operational capability.
But that’s tough, particularly if you’ve been in the business of having your software being delivered by somebody else because you now need to think about recruiting engineers, product owners, technical architects. You need to have the right skills in place and the development frameworks for building on those skills. There’s a culture that predicates high performance. It’s all about servant leadership, cross-functional teams, having a blameless culture, leadership that is humble and facilitates high performance. And then there are all of the engineering practices that sit behind this in terms of continuous integration, continuous delivery, release automation. All of these technical and engineering practices that new teams need to understand, adopt, and employ which will normally be very different, if you’re in the retail industry or in the manufacturing industry, to the practices that you’re used to.
Then once you’ve built these teams, and you’ve developed these teams, and you’ve built the engineering practices, and fostered that right culture, retaining good staff is really critical. Because good engineering capability now who can deliver software regularly, and maintain its stability, are going to be in high demand. And you’ve seen the elite performers and high performers will be attracting more of those people. So, you’re going to have to think about ways of how you retain the staff that you’ve got. And moving from where you are today to that is going to be a really really big challenge, and you’re not going to be able to have the right skills in place, the right roles in place.
One of the things I did was I augmented my teams based on output-based contracts. So, what that means is rather than a supplier being wholly responsible for a component of delivery, they would augment and sit within my teams, and they would be accountable for the delivery alongside my teams. Which meant that we had to really face things like blame culture, contracts, and all of that stuff. We all have to focus on the product and put the product first. We all had to behave as part of the team.
So, building on that, there’s a category of performance called the misguided performer, that came out of the report. Basically, this is where organisations take a more cautious approach to software development. So, the characteristics from all the research that’s been done they’ve looked like they have higher stability and lower change failure rates than the low performers. But they came the longest time to restore services, and deployments can cause cascading failures. So, what a customer might see is that the service has gone down, it’s not available anymore, but after maybe a day or two or even a few hours the service is back, but the full service won’t be back. It takes these organisations maybe months to fully restore the service and the health care crash in 2013 is a good example of that.
The State of DevOps report is showing that there are more organisations in this, who are taking that more cautious approach, delivering software in big batches, not really tackling their technical debt, fragile infrastructure, fragile code. And so, when something happens, when change happens, it takes a long time to recover. What was noticed as part of the study, was that this category of organisation contributes to the highest level of functional outsourcing, which contributes to their slow performance, and significantly slower recovery time.
So, in my own experience, I worked for BAE Systems for 20 years. I had multiple roles, both in aircraft maintenance and I.T. roles, mainly in service integration and management. So, everything from analyst work, strategy work, project management, service management, and in the last few years of my career over there, in 2014 to 2017, I led the transformation, the DevOps transformation, for seven strategic products. They include service now, success factors, SAP, Salesforce. And in 2018 I joined DevOpsGroup as a principle DevOps consultant.
I’ve seen a lot of these challenges first hand, particularly in the big enterprise. Trying to move from an environment where most of the I.T. is outsourced to an environment where we start taking ownership of our strategic products. If we just pick on the right-hand box here, when we look to the 2016 State of DevOps report they identified high performers and based on things like changes delivered, unplanned work, and morale. And they said that high performers were deploying 200 times more frequently than low performers, a 22 percent reduction in unplanned work. And had teams who were twice as motivated than those in low performers.
During those three years of our transformation, we saw 300 times increase in the frequency of deployment. We saw a 35 percent reduction in unplanned work. And the morale of our teams doubled during that time.
That’s great in terms of setting numbers. What did we do? What did we achieve? For one of our business groups, we helped to redefine the operating model. So that was SAP Salesforce, a number of capabilities working together, product teams working together to deliver a transformation. In a relatively short space of time with a very very fixed deadline. Basically, the opening of year-end or year start basically. We did that, we delivered that, and we did it with a day to spare which was pretty awesome.
We also transformed the way enterprise I.T. services were delivered, through the implementation of ServiceNow, and the continuous rolling of new capabilities to the organisation. Which resulted in us switching old systems off, legacy systems off, but also regularly deploying new features into the business. And we moved up to deployments twice a week, which was quite a big change from the monthly, or six-monthly releases, that we were doing before that.
Then we picked up the H.R. system SuccessFactors as it deployed. It was a cross-business enterprise deployment of that. We picked that product up, we stabilised it, there was a lot of technical debt that went in there to start off with. So, we stabilised the platform, upgraded the platform, and got into on-demand releases into the business new functionality capability. So, it wasn’t just a case of a set of numbers, we made some really big changes to the way we were.
Now we have to really make some changes because we have certain types of roles that are very much about service integration and management. So, we need to think about the different roles in our organisation. So, we introduce product owners, who are accountable for value, both in terms of build and operations. We have technical leads, who are accountable for quality. Delivery leads, we very careful not to call these guys scrum masters. So, they have to know Scrum, they need to know Kanban, they need to know waterfall, and apply those based on the type of work that would come in. They would be working with analysts, engineers, and administrators who would both deliver the product and support the product.
Clearly trying to recruit all of those roles for products like ServiceNow, or Success Factors, or SharePoint, is a real challenge, particularly when that’s not your forte. So, we needed to think really hard about how we built these things. And so, we had a mix between our own people, like product owners and maybe the delivery leader tended to be our own people. We’d augment with third parties whilst we built our team. We developed output-based contracts with our third parties, where they’d basically sit with us. They’d deliver the outcomes of the product whether that’s SLAs, or throughput, or particular value features to a particular time. But they’d also go play badminton with us, they’d come out for team nights out. They’d be part of the team, they put their badges at the door, and they’d work with us in a collaborative way.
During this, while we were building all of this, I worked with the DevOpsGroup, DevOpsGuys at the time, and a training provider called Emergn, and they helped us transform the ways of working. They were our if you’ve read the Phoenix Project, Eric character, who came in and said maybe you should try this, or maybe you should do this. And said don’t worry things aren’t looking so great right now, but you’re building good foundations, they’ll help you achieve great performance. Which we did. It was really really exciting to go through that transformation, but also it was a very vulnerable time, at the same time.
Just to pick up on some of those challenges. We went from a very traditional model where we had various roles accountable for the work, to a product owner being accountable for the product. We had vendor and third-party sourcing and we had to move to internal teams and augmented contracts, with outcome-based contracts, with our third-party providers.
We moved from technical governance to actually delivering deep engineering practices, in code management and release management etc. We’d gone from these big large releases with huge gates for moving work from one place to another, to small, frequent releases, and adapting the gates. So that we could make sure we were still doing things in a safe way but doing them much more frequently. We had to make change normal, rather than the thing that happened once in a while.
The team’s focuses, we had project teams focused on the delivery of the project. I need to get this over the line conversation. And then you’ve got the service stability, the service teams, who are going over my dead body. We’re here to keep this service stable. You’re going to destroy the service if you deploy that. We’d have all of the tensions, and the handoff challenges, that most organisations have in that space.
But then when we changed the whole team became accountable for the whole product and they became proud of the product. They didn’t want to deliver but features, because the developers would know that if those features were still there in six months/twelve months’ time, they’d be woken up in the middle of the night to fix them. The whole team became passionate about delivering value. There was this in-built sense that said we need to get rid of the incidents. We need to automate the request management. We need to drive down the un-planned work, so we can focus more on the delivery of value, of new features.
Our people focus was very much about SIAM roles, of service managers, and project managers, solution architects. We had a really big challenge to start thinking about recruiting product owners, product architects, engineers who are niche in their capability. And the integration with the SIAM was a big challenge as well because the SIAM was built to manage third party contracts, for the enterprise, and to give that seamless experience to the end-user. We have to do a lot of tailoring of that SIAM model to make it work with internal product teams who were more agile. Who already cared about the organisation and cared about a different respect for the end-user and the customer, because it was their business. So, we had to tailor those SIAM processes so that the governance was appropriate, but not overwhelming, for the internal teams.
All of this meant that we had to really think about the modernisation of our workforce, and our working practices. So, Ed, James anything you want to add to that?
So, I did promise that we wouldn’t do this Raj, but there was a question that has come in, that you won’t have seen yet. But I think it’s safe. I think one of the participants is just asking for clarification, when you were at BAE, that dev function, was that in-house or was it outsourced?
So, our dev functions tended to be outsourced. So, what that meant was we would typically get a vendor, or an implementation partner, to do the development and then deploy that into an environment, typically managed by another third party, and a different organisation would then support that. In some cases, we could have had two or three outsource partners looking after a particular product.
James, anything you want to add?
Not really. I think what Raj has just talked about flows nicely into our final section here, which is basically talking around the ‘what do we need to change?’ How do we need to change to ultimately become one of those high, and excellent, performing I.T. organisations?
I think we talk about that a lot, both internally, and with our clients when we look at, what we refer to as, our workforce modernisation. Which really is a is a change with, not only the skills and the specialisms that our engineers and every other role has. But also, in the way in which they work, and the way in which they work together.
We spoke earlier on, or I mentioned, around how I think culture is still the be-all and end-all. If your culture isn’t right, it’s very difficult to get any of the DevOps ways of working implemented. Again, the workforce modernisation is a huge testament to that, because you need to get people to buy into this way of working. Which is obviously very difficult to do if you are working with outsourced teams perhaps, who aren’t part of the integral team, and they do work a lot more on this ‘we tell them what to do and they go ahead and execute that’ basis.
So this next section really is just around what does workforce modernisation look like? How can we strive to become one of those high performing, excellent, I.T. teams?
We’ve covered this slide before and it’s just to reiterate that, to be in that bracket of high and excellent performers it’s pretty simple. We developed some software, we deploy it as frequently and as safely as we can. Ultimately our operations mean that we can recover from any issues without too much difficulty. Because of the technical excellence that we’ve been able to sort of build into our process. if we’re doing things like continuous delivery, and continuous integration, it’s all geared around making that possible.
Obviously, we’ve mentioned Cloud, and just to touch on what Ed said earlier on, this will be a big part of our next webinar. But another thing that came out of this year’s report was that teams that are adopting these Cloud characteristics, and ways of working, and technical excellence, are 23 times more likely to become part of those elite performers. This we’re seeing is a huge problem within many organisations because, Cloud specifically, they don’t have the capabilities to deliver on those practices, because they just don’t have the skills available.
So, a big part of modernisation, for us, is trying to encourage people to broaden their knowledge. More traditionally you have very specific knowledge in one very specific area. Which is why outsourcing has become very desirable or was a very desirable way, of filling those gaps. Because you were looking for a very specific individual that did a very specific role. We’re trying to encourage this broader learning. Yes, you’ll still have specialists, but we want that to be as fluid as we possibly can.
So, for all this to work we need leadership to be a big thing. Obviously, when we talk about leadership we absolutely aren’t talking about management, which is what you traditionally align with I.T. teams. And again, we mentioned it very early on, when it comes to culture the organisations that are really excelling in this are the ones that trust the development teams to do the job. They allow the development teams to have a voice. More importantly, they are giving them the empowerment to act with complete autonomy over the work that they’re not only producing, but then maintaining, as the products obviously shifts into live.
And it’s just one of the fundamental differences really, in mindset changes, that teams have to make between working on a project vs. working and supporting on a product over an amount of time. And again, it’s a model, that when you’re talking about project-based delivery, it can work very well with outsourced teams. I say very well, but it’s the thought processes, it works very well with outsource teams because it’s a very prescribed contract of work to do some stuff and we’re going to tell you exactly how to do it. And ultimately, we’re trying to move away from that essentially.
For this leadership, for these teams to develop in the way that we want them to, culture is so important to introduce a climate for learning. Trying to give people the tools and the ability to continually develop and learn is not enough. If people don’t want to learn they don’t want to share new skills with each other. If we don’t have this concept of these fully autonomous cross-functional teams, there’s a real hard cap on the amount of learning that happens. Knowledge sharing becomes very siloed and you get, potentially, developers just talking to other developers, testers talking to just other testers. Learning is very much halted because we are encouraging people, and teams, to get more knowledge on their specialist area which ultimately could potentially make them a blocker further on.
With the culture that we’re trying to develop here, we want people to buy into what it is we are trying to do. We want them to figure out the best ways of working, and the best practices to do that. We want them to share their learning with each other, organically. And of course, we will have more formal check points to do that with things like retrospectives.
Ultimately this all comes back to that appetite. And really to get people in that place, as I said, I’m a strong believer that you need to have the right culture which is driven by that collaborative approach. Obviously having outsourced teams just makes that collaboration that huge amount, it’s not impossible, but it makes it a million times more difficult to actually get the same intimate collaboration, that climate for learning that you would get from using those outsource teams. Where you have little input into how they develop and as a unit.
What we’re getting at here is, unfortunately, what a lot of organisations find it difficult to digest early on, is that when we go in and we talk about transforming to a more Agile and DevOps way of working, it really is about figuring out what that looks like for that particular organisation. It is a huge shift. It’s not just a change in the way we do development. It’s a change in organisational wide around how we actually deliver software.
What we’re basically looking at as a new target operating model, essentially, so that we can help find out what good looks like for you. We can help find out what different roles are needed within the organisation and that will differ. As Raj said earlier on what he had, and what he successfully implemented at BAE, will probably, yes there’ll be some of those roles that will be applicable to the next transformation that he might work on, but some of them might not be needed some of them might be different etc. It’s about finding out where people’s roles sit, and specialities that they need to know, as part of the transformation.
And again, without that collaborative, constant learning, it’s very difficult to figure that out. It’s not about looking at a spreadsheet and saying we need these developers in these particular areas here. We need these testers, these engineers, we need these analysts, or whatever. Which again makes it very difficult to go out and outsource. As we said finding the skill sets is a huge, huge deal for us and part of the modernisation, I think, is taking more traditional VM guys, who are very specialist in one particular area, and bringing that knowledge up to speed.
And again, we’re seeing very often that those low performers, as far as the reports are concerned, are the ones that aren’t working this way. They are in the habit of having very defined clear roles which may or may not be outsourced, and in most cases, it actually is. We’re really trying to encourage these lean practices, shifted from a more project focus to a product focus, and really, as Ed showed earlier on that J-curve, it’s figuring out what works for you. Then having the ability to stick with that, for the time that it takes, to get these practices to bed in and you really start to see the gains that way.
So, from an organisational view simply what we’re trying to do here is modernise the way we work. We’re trying to remove those silos. So, we’re trying to get away from this concept of role-based work. We go from the initial requirements out to the customer in a very hand-over laboured process. There are obviously a million and one potential challenges that come into play here, but the waste involved in this particular way of working is astronomical. When you talk about handoffs, relearning, issues with collaboration, issues with communication.
We’re really trying to move to that model at the bottom, which is flow optimised. So, we’re trying to get things through to production as quickly as possible. We have an all in the same boat approach here, where we’ve got the team who are accountable for the work that they are producing. They do what they need to do to get it through the system, ultimately into some sort of live environment.
The change that we make is pretty simple. This is what comes back to the outsourcing dilemma that we have really, is that we are trying to move from a more traditional I.T. team. Where you have a project manager, or some sort of manager, who effectively tells the team what it is they going to be working on and how they should do that. Which again allows us to outsource that work. We’re trying to move to a more Agile model where we have leadership rather than management. We have self-organising teams who, as we said, will collaborate and learn from each other. To build their knowledge, and their portfolio, and what they can help deliver in that time.
Really the big fear that we see with organisations, is that when we talk about Agile and DevOps, the more hierarchical organisations will feel like we are asking them to give up the control that they have over the teams. On one hand that’s absolutely correct because we don’t want them to micromanage I.T. professionals. But the nice way to look at it is that we actually want you to focus more on Managing the workload, rather than the actual people involved.
Obviously again that is very difficult to do if you’ve got an outsource team, that’s not an integral part of the day to day working. It’s almost impossible not to have to manage those people. But when you are working with an autonomous, empowered, self-organising team, it means the managers and the product owners, in the organisation, can focus more on making sure that the work is the right work that they should be doing. I.e. Are we working at the right level? Are we always delivering the simplest solution, and getting it through that flow as quickly as we can? Because ultimately once we’ve got something there we can utilise all the feedback loops to improve on that moving forward.
Finally, this is the utopia, if you like, as to what we’re trying to strive to achieve here. And it is all about that modernised delivery approach. Where you’ve got continuous delivery, which is fueled by technical excellence, as far as continuous improvement, continuous integration is concerned. And you have this concept of a delivery team that is completely self-contained, is completely autonomous. Because of that, they are, ultimately, a hell of a lot more efficient in what they do. They can drive ideas forward. You’re going to get far more creative solutions in working this way rather than, as we said, describing a way of working to a team that is outsourced and not part of the delivery team.
I just want to close by saying a lot of teams look at this sort of model, and they say this is a million miles away from what we can possibly achieve within our organisation. And the answer that I always have to that, and I’ve heard every excuse under the sun; we’re too big, we’re too small, we’re too complex, we’re not complex enough, our industry is unique it’s not going to work here, and I think the big takeaway is that this stuff takes a long time.
Again, referring back to Ed’s J-curve, it takes a while for it to bed in. But ultimately bringing this stuff in-house, and really transforming the culture in your organisation, as all of these organisations you can see in front of you have either started to do or well on their way in their journey. It is possible, and it just takes the right implementation and the right attitude. The last thing I’ll say is that it takes everyone in the organisation, and not just the development team themselves.
Thank you, James. Thank you very much. Just before we go to questions, you said one thing earlier that, and I’ll paraphrase you now, but you said basically it’s doing this with an outsource model is not impossible, but you are making it more difficult. If you could pick one thing that anybody who is either being forced to outsource or is in a long-standing contractual relationship whereby they have the outsourced model, is there is that one piece of advice you could give to people trying to work in that situation?
Yeah definitely, I think most organisations who are outsourcing for whatever reason. I think if you go and speak to the commercial people in the organisation most of them will tell you, if, for no other reason, it’s definitely not the most cost-effective way of doing this stuff. And there’s always a desire to probably not outsource as much as they do.
What I’ve seen a lot of organisations do badly is they just try and rip the cord out straight away, and they’re left with effectively trying to build up the capabilities in-house or hire in the capabilities in-house. To fill that void that you were, at least somewhat, producing some work from, from an outsourcing perspective. I think the advice that I would always give is you have to start this stuff small and incrementally. If you just try and abandon your outsourcing, if you’ve been doing that for a while, it’s almost going to be, without setting expectation right, internally there’s going to be a ‘well at least we will be delivering something that way so let’s just go back to it’.
So, I think what a lot of organisations and certainly a lot of the brands that you’ll see in front of you here, a lot of the discussion that we had with them was around ‘we need to prove that this stuff works within your four walls’ and that starts the case study there. Not just a case study from Spotify or whoever else on Silicon Valley has done it well, it’s about how does it work for me as an individual client. So, it’s about slowly scaling it down, whilst you slowly scale up your internal teams, and you start to bring some of that knowledge in-house.
Of course, there’s going to be an investment you need to make there. But as we said if you start focusing on encouraging people to broaden their skill set, rather than narrow it in a specific area, it will only strengthen the team when the next change in direction or pace comes in from a different technology. The advice that we do with everyone is there’s no silver bullet, there’s no easy way of doing this, but I promise you in the medium to long term you’re going to see huge benefits in bringing in-house.
Thank you, James. So, we’ve got a couple of questions coming in. So, the first question talks about how do you deal with situations where upper management just wants to cut the cost of I.T. and sees outsourcing as the answer?
I think we are incredibly short on time. I think my response to that would be if you look at this year’s State of DevOps report there was a really good case study that talks about the cost of delay. And I think if you can start to talk to the business in terms of cost to delay, the conversation becomes very different very quickly. You can actually see that the cost of not getting products, or service, to market can, in some scenarios, vastly outweigh any savings that you’re making by outsourcing. So, to answer that question, I don’t know if either of you gents has anything to add on that before we come to the next question?
Just one thing really quickly. Sorry, Raj. I forget where the quote comes from now, but it’s every organisation is an I.T. organisation in 2018. And I think you have to be. The ones that don’t do their I.T. in-house, and they do outsource all this stuff, those are the ones that are going to get left behind. And I think you have to realise the importance of I.T. regardless of whether you’re a traditional I.T. organisation or not.
I was just going to that. With that question, when you look at senior leadership, senior management, they’re trying to get cost down, performance up, and growth. Those are the three things any organisation wants to see. They’re constantly trying to battle those three aspects which is a really big challenge. So, a big part of that is the education that the senior leaders need. To understand where they sit, as a benchmark, against other organisations, where their competitors are going when adopting these sorts of things.
Back to the State of DevOps report, there’s a lot of evidence now that says actually you need to change the way you work. Start thinking about, rather than seeing I.T. as a cost centre, seeing it as a value enabler, or a predicator of high performance.
And yes, there is an aspect, there are two aspects to I.T. there are the commodity services that should be there, should be cheap as chips, pay per unit, and should be just there when you want to flip the switch, and it should be on. Then there’s those systems and products that differentiate you. So, systems of record, systems of differentiation, systems of engagement. Those are the things organisations should be investing in. Investing in the people. Investing in those products. And by deploying features regularly, delivering that value often, and maintaining really good performance for end-users is really really critical.
And I think this was one of the things when we read the Phoenix project, and that’s a really great book to read. But in the time when I was in BAE Systems, three years ago, I engaged with the DevOpsGuys, I engaged with Emergn. I engaged with people who could help me describe that journey. Describe the value proposition to the seniors. Not plugging this too hard, but that’s probably why I’ve joined this organisation, is that I can speak with those scars, I can speak with that experience. To say you really need to think about how you deliver your strategic products because there is another way, it involves investing in that way. Investing in the people. Investing in the culture. Not having an outsourced throat to choke model. But it can generate significant benefit for the organisation.
So, if the person, or if anybody wanted to talk to me a bit more about that, get in touch and I’ll be happy to have a conversation.
Thanks, Raj. So, I think we are incredibly short of time. We’ve got one question which would be nice to just touch on before we wrap it up. So, coming in the Q&A channel somebody is asking us: what would you suggest is the best way to enable a collaborative team culture, when you have large outsource teams split across multiple time zones? So, anybody got a 30-second response for that?
I mean the answer I’ll give is, as I said earlier on, it’s not impossible. I think the first thing is you need to accept the fact that obviously there’s no way you can be as collaborative as a team working in the same environment. That said, we talk a lot in the academy when we train around the importance of that face to face time with each other.
Obviously, video communication has come on leaps and bounds in the last 10 years, and I think there is no excuse to have a phone call these days. I think to be able to find that hour where you can all overlap to have a quick catch up every day, or whatever it might be. Don’t underestimate the importance of face time is the best advice I could probably give teams who are struggling because of time zones, and different locations. Because just knowing the person behind the words on the screen, or the voice on the phone, can make a ridiculous amount of difference. Even though there’s no reason why it should.
You’re trying to build that culture up and I think if you can’t do it organically with people in the same space, doing it through at least seeing each other is going to help you.
Yeah, I was just going to add a two-second thing. If the person asking the question wants to reach out and have a broader conversation. I’ve had experience with people having teams and multiple time zones. And the trick was to develop multifunctional teams in each of the time zones.
So basically, squads within a product team. Make sure that they have some overlap, and ours was unfortunately 7:00 in the morning UK time, out into the far east. Just having those daily stand-ups, those situational awareness moments, where everybody can just make sure they’re all doing the work in the right way.
And there’s a phenomenal benefit as well from having teams in different locations that are multifunctional. The work can continuously be delivered across the world in different time zones.
So really really tough, really really challenging, team design becomes really really important. The integration points, which are limited, and the face to face time, which are even more limited, are really important and I’d be happy to talk to that person in more detail.
Thanks so much. I think we are, not only, out of time but over time. So just before we end the session I’d just like to let everybody know that this isn’t a one and done. This is part of a series of webinars. DevOps Discussed Cloud, Thursday the 18th of October 1 p.m. You can register for that now.
Because we anticipated that this group was liable to go off on tangents, we’ve put together a white paper which draws together lots of the themes that we’ve been discussing on this call. That’s going to be available by the end of the week.
To Raj’s point, if anybody wants to continue these conversations the DevOps Discussed is a hashtag on Twitter. We’re all available on Twitter, we’re all available on LinkedIn. @DevOpsGroup on Twitter is the company Twitter handle, so worst case you can get to all of us through that. We would be more than happy to continue these conversations after the call.
I think the only thing that’s left me to say is thank you so much for what he’s given up that time to jump on the webinar today. Thank you to Raj and to James for their time on the call and to everybody behind the scenes. To Jo, to Clara to Lydia and everybody else who’s helped this run very smoothly. We will see you all again.