Voices in DevOps – Episode 20: A Conversation with Marc Rix of Scaled Agile

Guest

Marc helps large enterprises leverage the game-changing power of Lean, Agile, and DevOps at scale. He has been practicing Agile for over 20 years and is an internationally recognized thought leader, consultant, trainer, adviser, and speaker. Marc lives in California and is a Product Manager at Scaled Agile.

Transcript

Jon Collins: Hello and welcome to this Voices in DevOps podcast where I’m delighted to welcome Marc Rix who’s got a thousand titles. I’m going to stick with one, which is – actually you’ve got two titles, Marc. Sorry, this is turning into a bit of a waffly intro, but I love the fact that you’re a ‘SAFe’ fellow, which I think all fellows should be safe. We can talk about that. You’re also a curriculum project manager for Scaled Agile, so maybe you could just kick off by telling us a bit about yourself, your background, and how you ended up being a ‘SAFe’ fellow.

Marc Rix: Sure. Thanks a lot, Jon, great to be here. One point of clarification, though, on the title. It’s Product Manager, not project manager.

Did I say project? I meant to say product. I’m so sorry.

We’re in the era of moving from projects to products, so my title reflects that. Product manager, SAFe fellows, it’s good to be safe and right. What brought me to this place, [was] probably a career-long series of really bizarre accidents. When I was a kid, I used to ride my bike around and dream about what I was going to be when I grew up. It was never this. I never thought about being a DevOps guy or even a programmer or an engineer, let alone a methodologist or an educator.

I hope you’d have more interesting things to think about when you’re riding a bike around.

Oh, yeah, much bigger dreams. I was the kid who wanted to be a rockstar and musician, so I think in a lot of ways I’m a dysfunctional musician or delusional musician moonlighting as a technologist just waiting for my big break.

There’s some great organizations. I’m over here in the UK. It’s a bit of a t-shirt theme, but it’s like a drinking group with a singing problem. It’s always a drinking group with a ‘something’ problem, with a running problem. You’re essentially the rockstar in the methodologist’s body, fighting to get out.

Yeah. It pays the bills. I think what has really brought me to this point is a desire to constantly learn new things. If you look at my resume – I think that you were perusing my LinkedIn profile – you probably see that it’s very schizophrenic, lots of random responsibilities in there from a degree in business starting out, to programming and being a developer, and then a development manager and then architect and architecture manager, and a VP of engineering here and a VP of enterprise or engineering excellence there, VP of architecture, [for] large companies, small companies, start-ups, unicorns, horses, all over the place.

I think what has guided me through that very choppy sea of responsibilities has been the desire to chase new learning opportunities, first of all. I’m a lifelong learner. I love taking on new challenges and learning new things, but also looking for really interesting business problems to solve. I’ve always thought, ‘how much more interesting could my job be than leveraging technology to solve really interesting business problems?’ I think that’s led me through all of those different positions. Where I am now is working on more of a global-scale, helping some of the world’s largest organizations with their business problems and using technology to leverage it.

You’re right in the consulting, and advising, and mentoring, and all that sort of stuff?

Yeah, I am now, [from] a very hands-on engineering and practical programming-development career. My background is in engineering and programming, but I’ve always taken a look at that – through a business lens. I’ve gotten away from the hands-on, nitty-gritty stuff and now it’s more about educating and training. I really love what I’m doing now because it’s at the intersection of my three primary passions, which are business, technology, and teaching. It’s a really fun space to be in right now.

I’m looking at your LinkedIn profile and it’s not that different to mine about ten years ago before I became an analyst full-on. I was running training courses in agile development and so on. There’s just something wonderful about – well, A, I know how complex projects can get, so the wonder of not actually being part of that complex team, being able to help other organizations make things simpler, was always great because you’re always the solution, never the problem in that circumstance, so the feel-good factor in that; then B, just the epiphanies that people go through.

If you’re working through okay, let’s apply the Pareto principle here. What are the 20% of things that’s really going to make a difference to this particular... whatever we’re talking about: application, law, architecture. Just seeing the veil fall from people’s eyes as they get ‘oh, is that right? Okay, yeah we can do that! We can really cover that sort of news.’ Just so wonderful to get people to that moment where they feel passionate and not bogged down in their own weeds.

Exactly. Isn’t it great when you find that 20% that has 8% of the benefit?

I do confess that I’ve got a principle called the Guru’s Dilemma. Essentially, when you go somewhere and you’ve got everyone on board and it all looks great and you leave and you think, ‘I’ve solved another thousand problems. I’m just the best person in the world.’ What you don’t know is three months later, it’s got ol’ mister radiation decay curve and people have gone, ‘I’m not quite sure what he meant,’ and six months later I’ve seen organizations where I’ve been there six months after someone went in with all great ideas. It’s all kind of reverted to type and you’ve got to start all over again.

I like that. There’s a half-life to your brilliance.

It’s a half-life to your – certainly to that level of influence. You’re speaking to a lot of organizations. Training is kind of classroom consulting as well, so I’m sure you’re asking people what kind of challenges they’re looking to solve. You’ve got all that engineering background. How would you characterize, if we’re looking at enterprises, big companies – and I’m thinking across the gamut of DevOps, of agile, of just innovative – I call it software-based innovation at-scale, because I don’t like those [other] terms. They’re a bit too jargon-y. Driving that innovation and scaling that innovation using software, what are people struggling with? How would you characterize that?

How much time do we have, Jon?

We can always do another one. How would you explain it to your mother, in the words of Philadelphia Story?

Oh, wow. I actually think I’ve done this. I think I attempt to do this at the Thanksgiving dinner table every year, explain to the family what it is I actually do, but it keeps changing.

Can I say for the record, my mum is – I don’t want to derail this, but I was out for a walk with my mum about six months ago and she said, “Yeah, I used to do programming,” and I was like, “what?” Literally 30 years I have not known this. When she was working in clinical trials and there was data coming out of that stuff and there was some code that enabled stuff to happen and she said, “Yeah, I ended up writing reports,” in whatever the language was back then. It was something on a Paracom terminal. Literally my mum was programming before I ever did.

Wow, that’s amazing.

Okay, never again will I doubt her technical prowess. Do carry on.

You know where you get it. It’s baked into your DNA.

Exactly!

The question was something along the lines of how do I characterize the problem, like what challenges are folks facing out there, right?

Mm-hmm.

I always approach the problem first at a macro-scale. Across the broad swath of enterprises across the globe, regardless of industry vertical, regardless of geography, regardless of company size, I think companies everywhere are facing a really big challenge, almost an existential crisis to change, to move forward, to innovate, to transform into very agile, very adaptive organizations so that they can compete with the really dominant players.

At Scaled Agile, we’ve adopted this mindset of business agility in our latest framework release. Version 5.0 is really built around the idea of delivering business agility to enterprises, so really not just building agility and adaptability into the IT organization, but doing that so that we can have an influence on the agility of the business, the ability for the business to compete in the digital age. As companies go digital, as the world goes digital, we’re in the software era. It’s the gig economy, companies that –

Are you going to use the term ‘digital transformation’ in a minute?

I’m sorry, say again?

Are you going to use the term digital transformation? Digital transformation to me, by the way, is something that back in the day I thought, no one knows what it means and therefore it’s wrong. I was thinking, actually, everyone defines for themselves what it means, and that’s the most important thing about it. To your point, everyone’s struggling with this.

Yeah, you can kind of see that buzzword coming from a mile away, couldn't you? It’s the need to transform. Every company needs to be able to compete effectively in the digital era. I’m a student of Mik Kersten. I love his book on Project to Product. It’s had a big influence on my career over the past year, a big influence on the scale of actual frameworks, and it’s making a big splash in the industry.

I know that it’s having a really big influence on the DevOps community as well because I see him as a keynote speaker at the big DevOps conferences, so this idea of moving from the old paradigm to the new paradigm, getting out of the more tailor-istic ‘command and control’ style management of leadership patterns into a new era of agile, adaptivity, and automation where we can move fast, moving away from projects that are built on the premise of high certainty. If we plan it out the right way, if we get our WBSs and our resource-loaded networks and our architecture and our designs and our pixel-perfect designs locked in and defined upfront, we’ll have a great chance of delivering 18 months, 24 months from now.

That game is over. It’s now about how fast can we experiment? This is putting a lot of pressure on organizations of all sizes and ilks to find a way to retool their value stream so that they can compete at that speed with that amount of quality, because if they don’t, they run the very real risk of being overtaken by the unicorns, the dominant players, and the other companies that are able to transform. I think it’s that existential crisis that all companies are facing. It’s being felt in the boardroom, in the C-suite, and that’s creating a lot of pressure on the technology organizations to help step up and lead the way into a new culture.

How does that manifest itself in your experience? Is it that organizations literally are stymied, they don’t know what to – rabbit in the headlights style, knowing that they should do something and just can’t move, or is it that they’re trying lots of things and they’re just not... For some reason I’m reminded of Voyage of the Dawn Treader right now where – we’ll come back to that, but there’s a great bit in that where you can’t just superficially change. You have to change all the way down. How do you see it manifesting?

I don’t see a whole lot of deer in the headlights, we’re frozen, and we don’t know what to do, so work just stops. You can’t run a business that way; you’ve got to keep going and people are accountable for results. What I see everywhere is more of a cargo cult mentality where we’re proceeding with what we know. We’re going on instinct, we know that we need to deliver results and we’re just doing our level-best to figure it out as we go along. A lot of it is running on intuition, maybe making small adjustments here or there, but by and large, the process is: the decision-making structures that are driving the work are really from the old paradigm. People are moving forward, but it’s based on what we’ve always done. It’s what we know. It’s how we got here. What people are starting to realize more and more is that the processes and the practices and the tooling that got us here are not going to get us to where we need to be.

That’s brilliant. I’m going to, in a moment, ask you a bit of a digression question, but I want to come back to this, and I want to make sure that I’ve captured it. Essentially, it’s almost like – Edward de Bono wrote a book about Socratic thinking, this kind of linear – the way that most people make decisions is based on where they already are and they just move forward from there, so it’s a kind of linear progression, and the idea of changing – he wrote a book called Parallel Thinking where you literally move from that set of tram rails to a completely different road system or whatever. It is really hard for organizations. It’s not a death march, so much as just continued trudging along in the hope that ‘better’ will happen.

Right, exactly. The kind of change that we’re talking about requires a mindset shift. It’s very personal; it’s very cultural. It’s a transformation that needs to happen within the minds of everybody involved. It’s not something that can be decreed. I think we’ve all been through organizational change management efforts, the flavor of the day, transformation this, transformation that.

It seems like there’s always a transformation going on, but in order to make transformations stick, it’s really got to stick in the minds of the people whose behavior needs to change. The first step in catalyzing that change is a mindset shift. People have to believe that a better way is needed. They have to believe that their behavior needs to change. If their behavior changes, there will be a great result at the end. If there isn’t that internal intrinsic motivation there, then all bets are off, or you will only be able to transform so far, through your culture, and then you’ll hit a brick wall.

I’m nodding and thinking literally, again, how long have you got with the number of transformation projects? I’ve been watching the party too, been within, right down to, well, ‘we’re going to change the logo because that will do it all.’ This is the minor digression, but I think it’s important. Not everyone out there will know what the SAFe framework is, what Scaled Agile does, and methodologically here’s the thing: here’s a set of ways of helping you get from the place you don’t want to be to the place that you do want to be.

The background question is, how did Scaled Agile come about and how did the framework develop, because it’s not just a case of, ‘here’s the answer, just start applying it and everything will be okay.’ There’s got to be more to it than that.

Right, so Scaled Agile was born out of the need to apply agile practices, which are proven to work. We have decades of evidence that agile is just a great way of working. It’s not the only way. It may not be the only effective way, but it works. Agile practices have been adopted globally for great results. The issue has always been that agile is easier to do in smaller organizations. Startups never have a hard time going agile. It’s just easier; fewer dependencies. The communication networks are smaller. The product lines are smaller. The architecture is less complex. We usually just have one or two products or product lines. Smaller organizations need fewer processes, less bureaucracy, and that kind of stuff.

Agile just works, but how do you apply those principles and practices effectively to very large organizations that have been around for decades, in some cases, more than 100 years? They are very steeped in regulation. They’re high-insurance environments. They’ve got processes and layers and layers of people and bureaucracy. How do we transform those organizations? How can they be agile just as fast as the unicorns? The Scaled Agile framework developed out of the desire to prove that large enterprises could go fast just like small companies and startups could go fast. That’s still the game we’re playing today.

We literally haven’t rehearsed this, but this is pretty much – as I said to you before, I don’t like the term DevOps necessarily, but how to scale software-based innovation in the enterprise. There’s the word ‘scale’. It’s about making it big relative to the fact that you’re working with very – it’s a bit like using terms like ‘legacy’.

A lot of the times when we talk about the enterprise when we’re framing it, it comes across as ‘all of those things are bad things.’ I think some of those things are necessary things. For example, it’s necessary to be compliant out-of-the-box. If you’re an FMCG company, you can’t just make a thousand changes to your supply chain. It’s not going to happen. The supply chain needs to stay exactly as it is, because otherwise it will all fall apart. There are reasons why things have to stay the same, but then it’s how you can make change happen within an environment where there are good reasons why things stay the same.

Right.

Good. You’re literally coming to this from the point of view that this podcast is coming to this, which is very handy and helpful. I’m glad we’ve got you on.

Glad it worked out.

Glad it worked out. Where do you start then, – does such a thing exist? I’ve already said it’s not about a rabbit in the headlights kind of thing. If you’ve got an enterprise that’s ready to start looking at the kinds of things that you guys do, have they already been through – have they hit the rails in terms of how far doing things at an initiative level could work or is it coming top-down? Is it coming bottom-up? It is largely coming within a team? How do you tend to engage? I’m thinking of this not from the point of view of you as an organization, but what does the enterprise look like when it’s feeling ready to start becoming more agile and has it already had some hard moments?

Interesting question. Every application or implementation of SAFe looks a little bit different. The framework is the framework. We have an implementation road map that represents a very common implementation pattern sort of step-wise. First, do this, and then train these people, and then do this, set up an agile release train, and then launch and iterate. We have a defined recommended path to start. Many of our customers proceed that way.

Every implementation is different because every culture, every context is different. We’re dealing with people. We’re dealing with different enterprises with different strategic objectives. The one thing that’s common among all of them is they realize that they need to change; they need to be adaptive and agile all across the organization, not just the technology ranks, but now into the business, too. How do we do agile HR? How do we do agile compliance and change management, agile finance? How can we help our C-suite think in more agile and lean terms? [That is, think in] smaller batches and have more of an appetite for experimentation and risk-taking, the kinds of things that drive the behavior of some of the predominant companies today like Amazon and Netflix and Google, very experimental in nature and innovative. How can we start to move in that direction?

The goals that everyone is looking for are the same, but where it starts in the organization tends to vary. It usually starts with somebody getting an itch, whether it’s an executive or a senior leader or it could be a practitioner or a manager somewhere or somebody who’s got a vision for a different way of doing things and who thinks, ‘man, my team could be so much better, so much faster, so much more effective, if we were to do this’ or ‘my department could be so much better or my IT organization, my division, my business unit, or my entire company could be so much better if we were to do things differently.’

Those champions come from all ranks and all corners of the enterprise. It really just starts with a single spark, usually, and then that spark gets fanned, and it turns into a little flame somewhere in the organization. Usually the path that folks take is, when they get that itch, they’ll go looking for tools that can scratch that itch. Scaled Agile is just one tool of many. They usually go shopping and they’ll try some things out. A lot of times, they’ll try it internally.

Most often, there are folks within an organization who have done agile before or who have done DevOps before or who have experienced lean thinking environments before, and they’ll lead the way. What we see very often is when we get involved, there are pockets of agility, pockets of agile teams, pockets of DevOps, and pockets of lean-ness within the organization that are working effectively. Now those teams just need help scaling those benefits to the larger enterprise.

That’s fair enough. There’s no such thing as a standard organization; let’s say that for the record, but it’s highly likely that if you’ve got a 50,000 personnel organization or a 20,000 person organization, or even a 5,000 person organization, somewhere in that place, there will be people already thinking, doing stuff, in a much better way. I’m feeling it’s a bit like embers in the fire. It’s about how to gather those bits of ember together and recognize that that’s where the future fires are going to come from, and how to get them to make more fire all in one go.

Yep. Usually what we do is –

Does that make sense?

Yes, absolutely. Usually what happens is we identify those people, or they come to us and we help them get their organizations to what we call a tipping point, which is readiness for SAFe, readiness for something new, and ready to commit to the transformation. The people we work with in achieving that tipping point vary from organization to organization and implementation to implementation. Usually it ends up being somewhere within the mid- to senior leadership ranks in the organization.

It doesn’t necessarily have to have the board on top of things from day one?

Right. It usually does not.

That’s really useful. There’s going to be not a sequence of activities but an evolution from getting that readiness to commit, getting that tipping point happening and then building on that. My head’s full of analogies. It’s gone from embers to flywheels; I’m not quite sure how these things map onto each other.

As the flywheel starts spinning up, it’s going to generate information, it’s going to generate success stories, it’s going to generate the interest that then will feed up into the board, I imagine. Do the board [members] ever care? Do they just want to carry on the way they always were or is there a point at which – no, the whole organization goes, “yeah, okay, we’re all up for this.”

The board cares about results. Where we start is usually with the people who need a new way of working because the existing way of working just isn’t cutting it. Because of our processes, because of our project-based mentality, because of how we have our teams organized, and because of how we’re managing the portfolio and the budgets, and how we work managing our software delivery life cycle, it’s just not cutting it. We’re not able to make good on our business commitments. It usually starts with a recognition that the technology delivery engine is not serving the business and our customers well, so we need a new way of working, a new set of practices. The people who are responsible for those practices, the practitioners, the managers, the people who do the work, get trained in a new way of doing things based on agile principles. That’s the easy part.

Then we reach another point where there needs to be more of an executive or senior leadership tipping point where we have this 100 or 200 people in the organization doing things a new way and it’s working; we’re seeing results there and their customers are happy. Now how do we spread this across the entire enterprise? That sort of transformation, that sort of scaling requires more senior management approval and buy-in because budgets are involved and training’s not free and this is organizational change management, which can be disruptive and has an impact on the organization. At that level, in order to scale, you need buy-in and support from higher levels of the organization. Those people always ask the question, “All right, if we’re going to do this, what can I expect as a result?” It’s the senior leaders, the executives, and the board members in the C-suite who will do this if there are tangible business results attached to it. Somewhere along the way, you’ve got to demonstrate that this new way of working is producing tangible business results that are having an impact in the marketplace.

I’m just thinking of my own experience. I’m thinking specifically about government now, because that – was a campus environment; the NHS is similar over here, those kinds of environments where it’s multiple, similar departments but operating in isolation. It was almost like you could look out over the landscape of all these different departments and some would be working in a completely different way to others. They’d be very agile. They’d be very forward-thinking. They’d be making loads of progress. Others would still be stuck in almost medieval principles and practices.

What it seemed to come down to was – this is an obvious thing to say, but if you had a really strong leader in any of those little mini-pyramids of departmental structure, they could manage their part of the business in a really good way. Very strong leadership, as you say, mid-senior level would work brilliantly. Then, depending on the next level of leadership up, if that wasn’t strong enough, that would be the cutoff as to whether it was these fiefdoms doing things right or whether the whole of the organization was doing things right.

Right. Many of our customers are very large enterprises with very large solutions where they’ve got many teams, hundreds, if not thousands, if not tens of thousands of people who need to work together in order to get a product or a solution out the door, – very complex, and some of these solutions are cyber physical systems or highly-integrated systems. They could be big, complex CRPs. They could even be satellite systems or combines, tractors, airplanes, cars.

I love combine harvesters.

Aren’t they great? Have you ever driven one?

I have not. I live in the countryside. That’s something I suddenly really want to do. I think they’re some of the most advanced vehicles in the world now.

They’re amazing.

It’s a whole manufacturing plant on wheels, isn’t it?

Yeah, exactly. Those things are amazing. They’re super complex. More and more, the value proposition of those kinds of things is in the software that’s embedded. Most of the value of the Tesla and one of the reasons why the Tesla Model 3 is the best-selling mid-sized luxury car in the world right now is because of the intelligence built in through the software, the over-the-air updates and those kinds of things. Very cool technology, but also very useful and convenient.

Software’s eating the world now and software’s being integrated into more physical systems and into the manufacturing process, which is creating more complex solutions, and it’s bringing more and more people from the enterprise together into the value stream, needing to cooperate and manage the work effectively from beginning to end. If we have 10,000 people, internal people, different teams, engineering teams, software-based teams, firmware teams, everybody else supporting them, plus some outside suppliers who supply parts that need to get integrated into the finished product in order to get the solution out the door and into market quickly so that we can realize the revenue and compete and be profitable and all of that good stuff. [To] capitalize on the market opportunity to get this thing out the door and into our customers' hands and in the right place at the right time, that requires a whole lot of coordination, and we have to do it faster than ever.

If we have two teams, 50 people, maybe 100 people – that’s a lot more than two teams, by the way, in an agile world, but if we had just pockets of teams among that ecosystem that are doing agile and that are going really fast and doing things like DevOps and continuous integration, continuous delivery and really slamming it out, but everybody else is not, the benefits of being agile and fast are going to be seen only at that team level.

That can cause all kinds of friction, as I’m sure you’re aware.

Reduced lead times from end-to-end, right.

Carry on. I’ll tell you what, because we’re going to be running out of time, as long as the listener wants to carry on listening, so I hope you’re still listening, guys out there. I’m thinking I’ve got it, I’m bought into this, I want to do this stuff, et cetera. I’m already started and I’m pulling the embers together; I’m getting that flywheel spinning up. When you’re with those organizations – I’ve got two questions for you; the second one’s a final question.

The first question is, what does start to make it nearly work and then not work? What kinds of growing pains do you get? I may have just invented a term, so bear with me. I’ve got to get this out of my system while it’s in my head, which is ‘agile in name only.’ Organizations that I’ve seen that think they’re doing it all right, but still it’s like the old adage, real programs can write Fortran in any language. They can still be doing two-year cycles even though they’re doing them in sprints, for example, could be one challenge. What do you see as the growing pain issues? Then let’s go from there and just have a bit of a wrap-up in terms of okay, this is how to get from A to B.

Okay, great. Yes, growing pains out there and the good and bad, good news/bad news of agile adoption. Good news is it’s pretty easy to do and teams, in general, want to do it. If we talk about things like moving faster, decentralized decision-making, we’re going to do work in smaller batches so that we can get more work done, and we’re going to prioritize ruthlessly so that we’re always working on the highest-value things at any given time, and we’re going to impose work-in-process limits so we don’t all get burned out, and we can work on the most valuable stuff, and decentralize decision-making to the point where now the development teams have most of the control over the design and the development of the product.

In my experience, teams want that kind of empowerment. If you give them the space to create and innovate, they will adopt these new practices, they will take it seriously, and they will fly. Adopting the practices, adopting the patterns, and developing the muscle and becoming agile and being agile is fairly easy to do. It happens pretty quickly.

Hooray.

Then growing pains, right? Growing pains start to set in and be very noticeable when you see a lot of people doing agile, they’re holding the ceremonies. They’ve got the backlogs. They’re doing their refinement sessions. They’re holding their demos and their retrospectives, and it starts to seem very routine. It’s almost like you know that you’ve reached a level of plateauing or growing pains when you see a lot of agile happening, but the results have started to wane. This represents a disconnect in the minds of the people who are doing agile. They focus more on the practices than the outcomes.

They sort of lose sight of why we’re doing agile in the first place. It’s to delight customers. It’s to have an impact on the business. It’s to show our customers that we can do more with less and we can innovate faster, and we can have more of an impact in the market. I see that as a pretty major growing pain where we’re doing agile, it sticks pretty well, but then we’re not seeing the compelling business results that were either promised or we’re not really reaching our full potential with being an agile organization.

Very interestingly, on a webinar I was doing last year with Walmart, and that was one of the things – literally showed the graph of results and it went off like a rocket, and then it, again, was a bit of a decay curve. It tailed and tailed, and then it really hit the ruts because the desire went away when the results weren’t there. That’s when the real work started, he found. We’ve got a fad, and then we’ve got the cultural change.

Yeah. This is where I love to bring DevOps into the conversation, which might be a good place for it here. If you would allow me, I’d love to circle back to DevOps, because we started with DevOps, and I think introducing DevOps at this point in the transformation process would be very beneficial to people. It was to me.

I became a believer in DevOps at this point in the transformation. I was in a position as a – VP of something at a large financial institution and I was leading in enterprise-wide actual transformation. We had done this. We’d adopted SAFe, so I started as a SAFe customer. Very skeptical at first, tried it out, went slowly and then eventually fully bought into it. We saw really great results. In about nine months, we trained about 350 people across the organization, many members of the business included. We were doing agile and it was spreading. If you looked around the organization, it was very obvious that we had transformed. There were sticky notes up on the walls and there were big posters and big visual information radiators plastered up in the hallways and it looked like a different environment. You could really tell that something had taken root.

The practices were being adopted and the software was being developed faster, but we weren’t really seeing the benefits on the business side. We would ask our customers if they noticed a difference and they would say, well, we walk through the halls and we see a lot of arts and crafts up on the walls and it looks like you guys are doing some things differently, but we’re not really seeing a faster time to market or a higher degree of quality. We’re really not competing more effectively in the marketplace, so is there anything else you can do?

That’s when we realized that we had reached a plateau and we were experiencing some growing pains and needed something else. That’s when we brought in DevOps. As soon as we brought in more of a DevOps component to help us with that last mile of delivery – the development teams were getting software developed faster, but we still needed to get through our many stages of integration and testing, and retesting, and regression, and system testing, and end testing, and user-acceptance testing, and then deployment and staging, all of that other stuff into production. We needed to streamline that so that we could really demonstrate that we could get to market faster.

When we did that, we brought in more of a DevOps mindset in some of those practices and just a little bit of tooling and within the span of just a couple months, we were able to demonstrate that we could go from 18-hour deployments to 5-minute deployments. That literally changed the game for everybody. From that point on, we were a different organization and we were leveraging DevOps to deliver benefits that were noticed by the business and by customers, and from that point on we were measuring gains not in percentages but in orders of magnitude.

Wow. I’m deliberately saying ‘wow’ there because – I could make the following hypothesis, which is the way to do DevOps properly is as follows: the first is to get your head around doing agile, essentially hit this rail, hit this issue, and then you’re in a perfect place to start bringing in and reaping the rewards of DevOps, because you’ve already made the cultural shifts, but you’re facing the challenges that are caused by those cultural shifts. Now it’s time to bring in better automation, better measurement, better collaboration, et cetera, all those good pieces of DevOps. They don’t exist in isolation; they exist building on a foundation of agile, which has a really powerful potential opportunity.

Which absolutely helps each other, exactly. Agile and DevOps, better together. They reinforce each other.

How very corporate. That took me back. Is that your final word? If I was to say “Let’s wrap up and let’s summarize,” would that be what you would suggest to any organization that’s out there that’s looking to do this transformation, make this, to your point, to address this existential crisis of business agility?

Yeah, but let me add just another little bit. This is inspired by some things that you’ve said along the way about the terminology itself. You said that you don’t necessarily like the term DevOps. You don’t necessarily like other terms. I feel exactly the same way. In fact, I gave a talk at – well, I can’t remember which conference it was, but it might have been our SAFe Summit here in San Diego last fall, but I was talking about the evolution of DevOps. How do you know you’ve reached a good stopping point with DevOps? What’s the sit-crawl-walk-run-fly evolution of a DevOps capability within an organization? I started with: you know you’re at stage one when you don’t even know what DevOps means. Then you proceed through these stages. You get DevOps, and then you’re doing DevOps, and then you’re really flying with DevOps, and you start redefining what DevOps means, and then the last stage is you’ve dropped the term altogether and you no longer call it DevOps. It’s just the way you are. It’s built into your DNA. It’s in the culture. You don’t need a name for it; it’s just what you do.

We apply terms to things: DevOps, continuous delivery, CI/CD, agile, scrum, these things as labels for ways of working and more efficient ways of getting work done, but it’s not so much about the terminology. It’s not so much about following a specific set of practices. It’s finding what works with your culture, doing that very effectively, building it organically within your culture, and then cultivating it, making it part of your DNA in the culture. Definitely start with agile practices, do DevOps, adopt these practices; they work.

I love DevOps because it’s one of the quickest routes I’ve seen going from zero to lighting fast in a very short amount of time. It really is a game-changer. Start to adopt these practices, but don’t do it in isolation. Have more of a system view, make sure that you’re optimizing the value stream from end-to-end and not just one piece of the value stream at a time. Always be centered on why you’re doing this in the first place, what you need to do to really ingrain these practices and this mindset in your culture. When you’re doing it that way, it’s less about doing DevOps and more about just doing continuous delivery and being an agile organization or doing the best you can to enable the competitive advantage and the health of your business.

That really does bring us full circle, doesn’t it? It's a huge difference between getting there and just being there in terms of all of these practices where the labels just drop away and you just wonder why everyone’s talking about it.

Right?

Why do we even need a term? It’s just what we do.

It’s just what we do.

That’s absolutely fantastic. Thank you so much, Marc, for joining me on this podcast. I often say I’ve learned a lot, and it’s usually true, and in this case it absolutely is true. I’ve had a couple minor epiphanies of my own as you’ve been talking. Thank you so much for joining me on this podcast and I look forward to catching up with you again.

Thanks for having me on, Jon. It was a pleasure.