Voices in DevOps – Episode 11: A Conversation with Dave West of Scrum.org

Guest

Dave West is the Product Owner and CEO at scrum.org. He is a frequent keynote speaker and is
a widely published author of articles. He also is the co-author of two books, The Nexus
Framework For Scaling Scrum and Head First Object-Oriented Analysis and Design. He led the
development of the Rational Unified Process (RUP) and then worked with Ivar Jacobson running
the North American business for IJI. Then managed the software delivery practice at Forrester
research where he was VP and research director. Prior to joining Scrum.org he was Chief
Product Officer at Tasktop where he was responsible for product management, engineering and
architecture.

Transcript

Jon Collins: Hello, and welcome to this edition of Voice in DevOps. I’m delighted to welcome Dave West, who is running Scrum.org. I have to say for the record, I used to work with Dave in 1997 on agile software development. We didn’t call it that back then. Dave actually knew what he was doing. I didn’t know what I was doing. 

I was able to pretend because of what Dave told me. That’s the background to that. Now 20 years have passed, so hopefully I do know what I’m talking about a little bit more. Dave, you absolutely know what you’re talking about. How did you even get there? I’m not even sure I know the answer to that. What’s happened over the past 20 years to get you to where we are now?

Dave West: Hi, Jon. Thank you for reminding me how old I am. That’s always a great thing to do. I have a six-year-old and three-year-old. I was at soccer, as we call it here in America. For all the listeners, I live in America in Boston.

They call it ‘soccer’ here, even though I have an English accent. I was at soccer, and I was standing next to some parents watching my child follow the ball just a few steps behind it. We were chatting. I said, “I went to university over 30 years ago.” They went, “How old are you?” I said, “I’m 49.”

They went, “Oh, my God. You don’t look 49.” I felt vindicated that I’m not as old as I feel some of the time. Thanks for mentioning that. The question that you asked—by the way, you did 20-odd years ago know lots of things around objects and software development and process.

What I didn’t know, it turned out you can make up...

It wasn’t quite that bad. How did I get here? It’s interesting. I was that kid in high school that spent a lot of time in the BBC model B lab writing code. I was really into it.I got my first robot to move around the table and fall off and break. Then I had to pretend it was somebody else. I was that child. I had a very clear mandate from an early age to become a software engineer or coder or programmer or somebody that could literally spend all their time in front of screens. It was great. I went to university like everybody, then got a job working in industry writing insurance software.

What was interesting is I realized quite quickly that the last thing you do as a software engineer working for a large insurance company is write any software. You spend a lot of time filling in forms, desk checking. I checked my desk many times. It was perfectly fine and didn’t change that much, doing all that stuff. I realized quite quickly that even though I loved writing code, I was doing more [of it] at home than I was in the office. I quickly got into objects.

I did my masters, and I started that journey and realized OO was the way to go. As I got more into objects, bizarrely, process became more important to me. The last thing in the world [you need] as a software engineer is more process. I realized quickly that the relationship between architecture and the way in which you work, the relationship between these objects, these things...It was interesting that you had to work in a different way. That led me to the unified process and to the work of Grady and Jim and ultimately Eva. That then led me to write a book.

It sort of brought me through this journey as I went up the pecking order from ‘I just want to write code,’ to ‘I just want to work with others to write code. I just want to write code that doesn’t break all the time because everybody else is writing the wrong code. I just want to deliver business value so my code is actually used.’

That takes me back to when it was the ‘select perspective’ that was your software process. I can remember clients saying to us, ”Can we just use the process without the tool?”

The answer is “No.”

We’re trying to sell the tool and you get the process for free. It worked. That was the agile stuff that we were doing back then.

It’s interesting because obviously I’m fortunate enough to run Scrum.org for Ken Schwaber, co-creator of Scrum, and one of the guys who signed the Agile Manifesto. It’s interesting when you look at that group: Kent Beck, Mike Beedle, Alistair, Arie, Ward, Martin... they were all OO guys. A lot of them are OO guys. Maybe Jeff isn’t. Maybe Jim Highsmith isn’t. Ron Jeffries definitely was. It’s interesting this agile phenomenon and the DevOps phenomenon, which is sort of ‘him and her,’ ‘yin and yang’ of this change that we’re driving, it has been driven from those people. Ultimately it’s about how people work together to solve complex problems.

Let’s get onto that. DevOps has kind of emerged. Gene Kim wrote books about it and other people have written stuff about it. As you say, agile has moved through extreme programming up until this point, up to where you are now with sprints and so on. Then ops has come in from this other direction.

I was spending more time on infrastructure in that key five-year period. What happened? Did ops kind of go “Look, enough” or did dev kind of mature? How did it actually come together?

It’s interesting because we all know that it all started in Belgium, DevOps, because of beer maybe. I hope because of beer. It was originally called Agile Infrastructure. The reason why it was called Agile Infrastructure was because—strangely the Netherlands or Benelux has a huge agile community and very scrum. I guess if you go to a country below sea level you become quite empirical. (Laughter) I don’t know, maybe. Was that water? Was that meant to be there?

You’re certainly thinking about what happens the next day, aren’t you?

Exactly.

Day two is important.

We’re going to the side here. The Dutch in general have a very kind yet cynical view of the world. They’re very good at asking you very direct questions. I think maybe they’re just more agile enabled.

They started off saying “Hang on a minute. You’ve got these agile teams, predominantly scrum teams, delivering incrementally, trying to learn. The planning cycle is these sprints. What the heck? Why does it still take us six months to release that to the world? Could we not change?”

That’s what drove our initial movement: very simple motivations. Hang on a minute. If ‘potentially shippable’ is the increment at the end of each sprint or iteration or whatever you want to call it—I don’t really mind. Obviously, I come from a certain point of view. Why can’t we release it? What does that mean?

That’s got huge implications on the business. It’s got implications not just in terms of the definition of ‘done’ and what it means for a dev team to deliver working software, where testing lives, etc., it’s got implications into robustness of the underlying infrastructure to support it. It’s got implications to the business itself. How does the customer base deal with the fact that your software is continuously changing? How do you do customer sales education? Where does the support organization live in this?

Just by moving a little bit to the right, dare I say pushing left in terms of the activities, you end up in this really interesting set of problems. The thing that really frustrates me and because as a software engineer I hate this, it all comes down to ultimately levels of trust, psychological safety. It’s sort of like your ability to frame problems, all of this soft stuff, which really is so annoying. It’s funny how the two have driven each other to drive to this next kind of business way of working on the business.

My first job, which you don’t know, was as a programmer for Philips working in Holland. I can remember it was workstation based. It was software for electronics. I can remember going out there to Holland with some stuff I just built a beta version. Someone said to me “That was mostly alpha, wasn’t it?” You’re like ‘yeah. It’s a fair call.’ That pragmatism and honesty, even if it hurt slightly, I fully engage with. Obviously, you’ve worked with Ivar JacobsonFoundation. You ran it.

I ran the US operation for it.

You worked for Rational—that was part of IBM on that side of things. You’ve seen it as an analyst. You’ve seen it as actually ‘hands on.’ While there is no such thing as the kind of generic enterprise, you’ve clearly still had lots of experience of engaging with enterprise-sized companies. You can’t really just go in there and say “Hey mate, we need your soft skills.” How do the things manifest themselves when you’re looking at enterprise?

Ultimately soft skills represent themselves in behaviors, organizational structures, patterns, etc. Even though at the end of the day it is about people working more effectively together and to deliver more value to their customers and it is a socio technical system, yes, you’re right. You have to think about behaviors. You have to think about how do you incentivize people? How do they report? Where does their career go?

What does risk really mean? How do we manifest that in terms of the architecture? Great example, very tangible example: How many times, John, do you talk to a customer at continuous delivery and they say “There’s no way we can do that?” You say to them, “We’ve got all this legacy. It’s very hard and challenging.” What I say to them, which maybe you said the same thing, as I didn’t invent this, “When you’ve got a production outage, how quickly can you fix it?” They’re like, “Well, it depends on the outage.”

I say, “Give me an example the last time you had one, a serious one. How quickly did you fix it?” “Well, two hours, four hours.” “You can release software really quickly.” “Yeah, but that’s different.” “Why is it different?” “It’s different because we have the team. We get the best people.”

That sounds worrying. That means you don’t have the best people. How do we make sure we only have the best people working there? Maybe we put in some community or guilds or chapters or something or whatever trendy term you use. Getting to the nuts and bolts of the issues is really important.

When I talk to enterprises, I tend to look at those sort of things. I tend to talk about how do you measure value? How is that translated to the customers? How do you align your teams? Do you align them to subsystems and these bits or do you align them to customers and outcomes? How do you empower your product owners? Where do your product owners come from?

It’s a relatively simple set of questions. Then how does that translate into the machine that is the organization? Increasingly I’m thinking, which maybe you [are] as well, that alignment is crucial and core and context are crucial, so aligning teams to real outcomes, real customers, real mission kind of stuff. Core and context, most organizations are trying to do too much. They don’t like making decisions, so that’s not great.

I was at a financial insurance company and their COO got up onstage. I’m not going to say who they are. He did a fantastic job. Then somebody asked him, “We see from the execs there’s too many priorities. Are you going to change that as you move through agile?” He said, “No.” He said it in a really nice way, but he said no.He talked about the empowered individual. He talked about measurement. He talked about control, but then ultimately said “No”. The bottom line is you’ve got to make choices. You’ve got to keep focused on the things that are important. The bigger you get and the more complex and the [fewer] choices you make, the less successful you’re going to be.

Core versus context is one way of thinking about this. What is your core? What is your context? That might not be today. You may have to transition away from certain things. Then the other thing is aligning once you know what your core is, those teams and teams of teams to that situation, and then building an environment around them to be successful, whether that’s operations, whether that’s HR, whether that’s legal, whether that’s contract, whatever those things are.

It is actually quite simple, but we make it more complicated than we would like to. I get why. We’re human beings. We want everything. We try to fix everything. We try to build these complex structures, processes, etc. I get why. It doesn’t have to be that complex.

There’s two things you’re saying. One is that you shouldn’t be over here, you should be over there. There’s a better place. It’ s kind of almost, not coping strategies, but living in a world where change is the norm rather than the exception. It requires a change in a whole bunch of dimensions.

The other thing that you said or hinted at earlier is organizations are already good at that, even if they’re very big. It’s just that they’re not thinking that they’re good at that. You say, for example, “How do you deal with a major outage?” “We can do it.” You’re already doing it then. It’s “How do we codify that?”

These companies have become successful. There’s actually a really interesting tension or contradiction. As a Buddhist I can find some cool name for it. The organizations are built around efficiency, around mitigating risk, making sure they never make the wrong decision, making sure they’re very efficient, making sure they take the shareholder value and don’t necessarily give you the best return on it, but make sure you don’t lose it. That’s what they’re building.

It’s a big lie because ultimately you know [with] every system, every process, every thing, there’s a group of people that deliver value in spite of that, not because of that. A lot of these organizations are incredibly capable, but their capability is almost if we admit it, we admit what we weren’t doing. We delivered a release to production in two hours or four hours because of a production outage. It didn’t use a lot of those things that we’ve invested millions of dollars in; change management processes, massive amounts of ERP, signoff checks. Why is that? Audit is in the room with us. Compliance is in the room with us.We’ve got amazing engineers that knew the software. We’ve got the business that knew the implications and the risk. We’ve got somebody that can make the decision, maybe even the CIO or the CEO. Hang on a minute. They don’t want to admit that if they wanted to do that, they just have to scale that.

They just don’t want to admit that because then they’re admitting that they wasted millions of dollars before on those other things. It’s sort of like one of those fantastic contradictions. I don’t think it’s a bad thing, by the way, Jon. We’re going through a huge change across industry after industry. I think it’s just part of the cost.

Hang on. I’m reminded of a large UK government department I was working for was so big, it operated as a campus. The NHS is going to be the same and other large organizations are going to be much the same. Within that organization, there wasn’t one IT department. There were several IT organizations.

The ones that always impressed me were the ones that somehow almost like a swan seemed to do everything faster and better and actually deliver things. Other people said “No, it can’t be done. It’s too hard. We tried for two years and we’re still working on it, and the requirements changed, etc...”

What you’re saying is you don’t have to say everything else is rubbish. Just work with those bits that are working. Just acknowledge them, accept them, grow them. Look for the agile parts of your organization and grow out from there. They already exist.

Of course they will. They have to. There’s no way you can be successful without a level of agility. It’s like when you roll out those sales processes and CRM tools. The really good sales people just carry on doing it the way they’re doing it. Maybe take some of the goodness without necessarily adopting it. They’re successful in spite of the environment around them.

Unfortunately, that doesn’t make it easy. Those people don’t take the status quo naturally. That swan that you described that sort of gracefully moves around the departments and gets stuff out, delivers value, they’re made up of a certain set of people that have accepted—it’s making choices and accepting they’re your choices and not blaming the system or “the man,” as they say in the US. I think that’s really interesting as well.

When we teach scrum at Scrum.org, one of the most important [things is]—scrum is simple. It’s empiricism, self-organization, and a desire for continuous improvement. That’s all it is. It’s simple. What the reality is, self-organization is really hard because the first thing you see on most teams is “we can’t do that because…”

Yes, but—hang on a minute. You have to take ownership. You cut the suit to suit the cloth. You don’t want to bang your head against a brick wall all the time, but you have to take ownership of your own destiny, as it were. It’s a fairly philosophical sort of conversation. Listeners are thinking ‘how do we make this real in our organization?’

A lot of the time we talk about [how] all organizations are on a journey. If you’re here, you want to start moving, etc. You will mature over time, which is this kind of linear approach, which actually never works. You’re still doing the same journey in 20 years’ time. What you’re talking about is actually almost an acceptance of the fact that your organization might be succeeding already and acceptance that some parts of it might already be organizationally mature or capable up there already. Stop doing the stuff that isn’t that, which is a different way around than try harder at doing the stuff you should.

It is interesting. It’s sort of like when you get a great coach, the coach will focus you on the things that you do well and strengthen those things, whether it’s eating, whether it’s habits that you can rely on. The bottom line is I think we have to take responsibility for the situations we’re in. Look to the things that we’re doing well. Rejoice in those things, and not spend our whole time trying to introduce this new way of working.We have to ignore everything we’ve done before. That’s just silly. We do have to get some of the things that get in the way and get rid of them. The incentive programs that I see over and over again, we expect people to work as teams, but we incentivize them as individuals.

The promotion models where we encourage people to hoard knowledge and not share it, those things are just uncool. They just don’t work. All they do is create this sort of very competitive and very individualistic model where transparency is dropped because people aren’t honest about a program or project, their knowledge, their experience, whatever the situation is. When you have a production failure, that tends to fall apart because nobody is thinking about how is this going to help my promotion? If I share this with the boss, they’re going to realize I don’t know this, and I know this. People don’t care about that. They just want to get the thing done. We need to change our organization.

Something I’ve been writing about is ‘DevOps friction.’ Essentially it’s all the things that stop DevOps from happening from a technical perspective. It’s all the “yeah, buts:” yeah, but security; yeah, but governance; yeah, but APIs; yeah, but I don’t have the right information; yeah, but legacy systems, etc. They all slow things down over time.

What you’re talking about are the organizational ‘yeah, buts.’ It’s the same point. What you’ve got to do is stop them. It’s not so much try harder and do it cleverer, it’s stop doing the stupid things. Stop doing the things that are getting in the way of making it simple.

When you get down to the nuts and bolts on most of these things, when you ask the five whys or whatever, they tend to be for a good reason. However, the way they’ve been implemented, as the model changes, as we become more team focused—the reason why we become more team focused is because the problems we deliver on or what you’re solving require teams to work in a way that we’re not totally sure about up front. We need these highly diverse teams of multiple skills, working together, cross functional, etc. We need to incentivize them. How do we bonus them?

Interestingly, as Dan Pink proved over and over again in The Surprising Truth About What Motivates Us, the things that we think motivate don’t. The things that we don’t think [motivate] probably do. Just step back and say what are we trying to achieve? We want to build an environment for these teams to be successful. How do we do that?

Yes and, not yes, but...humble and kind, all those sort of things—it’s funny, all the things that the American education system doesn’t like, we like individuals. We like levels of people. You’re top of your class. You’re top five of your class.

I’m the best at humility.

I’m the best at humility.

I’ve nailed it.

Exactly. The point is: that isn’t it. That’s not how you build a great team. That’s how you build a great group of individuals that don’t work well together that are all in it for themselves. You need to build teams that are in it for each other and in it for delivering value.

That sounds great. Let’s do it. But I’m thinking about chicken and egg. I’m thinking about there must be an order to do things. There’s certain base elements that if you haven’t got them right, then probably the next stuff is going to be harder than it should be. Where it’s easy to say “just be kinder” or whatever, that won’t necessarily come naturally. What would you say are the things to get right first?

The most important thing is alignment. I said it earlier. Align your teams to outcomes and everybody accept that’s why you’re aligned. By the way, that highlights one very important thing: most organizations like teams so much, they put people in hundreds of them. I can’t say that you can’t be in a few, but I can say that you can’t be in millions.

Reduce that to the bare minimum that you can. That means choices, and we don’t like choices, but that’s the reality. Number one is align your teams to clear outcomes. Make them very super aware of that, whether it’s customer personas, whether that’s internal users.

Find your customer. As soon as you find your customer, a lot of the other stuff starts falling away, particularly if you get the team to have a vested interest in the customer. Suddenly everything else kind of falls apart. We’ve worked together in our past. We worked together helping customers.

Everything else that got in the way of that, we kind of just dealt with, whether it’s that customer isn’t in the same [time zone]—that means we’re going to have to travel on a Sunday night. I don’t like traveling or whatever those things are. How do I deliver that training class to them, whatever those things are. Customers help solve lots of problems because you get a vested interest in doing that. Number one is around your customers. If you suddenly get alignment to your customers, everything else sort of falls in check, in my opinion.

Then start thinking about how you help others. I think having that sort of time in your schedule to literally do some coaching, do some mentoring, not only does that help you become better at your craft, it also helps others. Then that whole calmer thing, it’s incredible. Alignment is my number one. I really do think that. I think if you get alignment and you start delivering frequently, everything else is easy.

I also like what you’re saying about the collaborative nature of things. I think we all use Slack these days. It’s all supposed to be collaborative. As you say, people are still operating as individuals. I think it’s a psychological change to be actually working in support of other people as opposed to “Hey, I’m communicating. Get off my back.”

That’s an interesting point. I’ve tried to demonstrate that behavior to my team, and it’s not easy. I try to talk to them when I’m talking to them about the work that I’m doing. There’s lots of stuff that I’m doing. One thing I’m very conscious of is how I helped somebody the other day. I sort of demonstrate that.We see that, and it can be inside the organization. It can be outside. It doesn’t matter. I think that’s such an important thing. I think that is where the 21st century work is going to be going.

I actually do believe there’s an increasingly important part of everybody—particularly if the manager is dead. Everybody says that sounds awful, but I don’t say it like that. The role of management is becoming less important as simple and complicated work gets outsourced to AI and other things. That means that complex work and chaotic work is going to be the norm. We get that.

That means that as the age of the creator, because you’re solving complex problems, that requires teams to work together in some sort of creator-type model. That means ultimately at the end of the day that things that become important are more around equipping the skills to solve the problems, which you haven’t always got. That means you have to help others and vice-versa. It’s the open source thing. I think that’s going to scale out in ways that we don’t really understand in terms of a change in the way in which we work.

To finish off then, I’ll put you on the spot. Thank you very much for this. This has been absolutely brilliant. It does take me back to doing training courses together. I’m going to finish my side of things with a story from the Dave West catalog of things to do in a training course.

On day one you write on the whiteboard at the top that there’s no such thing as a stupid question. On day two you rub it off in an opportune moment that’s guaranteed to get the most laughs. I remember you doing that on more than one occasion. I don’t know if that’s still a trick in the book.

What I’m going to ask you to leave people with is if there was one question to ask yourself or if there’s one thing that people could start doing or questioning, to stand in the mirror and ask that question or ask it of each other in an organization, just to really start getting the hang of how to align better, how to collaborate better, etc., what would you leave people with?

Maybe look at the things that you’ve blamed other people for and think about what you could have done differently or what you can do differently in the future to fix those things. We can’t release software. Testing is a bottleneck. Instead of blaming other people, what can we do to help fix that problem and take responsibility? There’s a [long] list of everybody else’s faults. Let’s try to identify some of those things that we can take ownership of and fix and improve our own lives.

Fantastic. We start and end with responsibility, alignment, collaboration. What’s not to like? Thank you so much, Dave. It’s been a pleasure speaking to you.

Thanks, Jon.