What are the barriers to adopting Scrum in the business and how do you overcome these?

This is the third post in a series of three, which started as a Blab discussion with Joe Justice talking about Scrum everywhere - Adopting Scrum outside of technology teams. Joe subsequently had to leave the Blab and so in the next post Simon Bennett of LASTing Benefits and I explored the question Can Scrum everywhere be taken too far?. In this final Blab post in the series Simon and I answer the question 'What are the barriers to adopting Scrum in the business and how do you overcome these?'

The recorded Blab is 15 minutes long and there is a transcript of the discussion below.

Blab presenters

Our presenters during the Blab presentation were:

• Left-hand side: Simon Bennett, Managing Principal at LASTing Benefits. Simon is a Certified Scrum Trainer and popular Agile speaker with a focus on the wider organisational issues in the areas of Agile contracting, employee motivation and systemic resistance to Agile & Scrum Adoption.
• Right-hand side: Ray Cooke, Lean and Agile business transformation coach, Equinox IT Wellington office. As a Software Development Manager Ray focuses on Agile software development approaches and the change required to successfully adopt Agile within teams and organisations.

Transcript of conversation

Ray: So, final question we're going to cover today... So, and those were where they are appropriate. What are the barriers to adopting Scrum in the business, and how do you overcome these?

So I guess that's a more general question and we could spend quite a long time discussing that anyway. But, I guess, at a high level... So let's go with personal experiences. What kinds of problems have you come across, Simon, that are from a business standpoint that have meant Scrum adoption is a problem? I guess we're talking specifically about adopting Scrum in a business context, here, rather than purely in a technology team.

Simon: Yeah. I was going to ask the question.

In some ways... So if we skip over the traditional problems you get with Scrum... So let's just, for the moment, let's not talk about all the problems people always have when they deal with Scrum and talk about the specific ones.

Really, number one, is Scrum is now seen as a software thing. So if you have a real culture of the us and them as the software thing, there's an immediate thing as, like, why would I do that software process? In fact, I recently did a course where people were doing analytics, and they were, like, "Oh, no. We can't do any of these things, because we're doing data analytics, and this is all very specific to software," which is ironic, because I'm working with a couple of data scientists at Sydney who actually roll out specific Agile for analytics courses because they fundamentally see Scrum as solving a lot of the problems they have with analytics products today, because of all the same sort of things happen. So I think sometimes people discount a lot of it because they kind of put it in the same bucket as .NET programming, and they go, ".NET programming has nothing to do with me. That's too techy."

So that would be number one.

Ray: But Scrum is very much, quite obviously it was written for software teams, and as much, it's very much worded for software development teams. So I guess there's a scope here for a non..., a Scrum guide without the tech speak that, as long as you can somehow frame the appropriateness of that for the problem that's being solved.

Simon: Oh, absolutely. So that was going to be my number two answer to the response

I don't know if Joe was there, but it was about 2009, I think, the Scrum Alliance had a conference called Scrum Outside of Software. The one thing we're not allowed to talk about at this conference was Scrum with software.

This is probably, because there's a whole bunch of government people here, so all that stuff that Joe was talking about at the beginning of the Blab (see Scrum everywhere with Joe Justice - Adopting Scrum outside of technology teams) may have had it's seed there, because it was just basically an open space, and people went, "Oh, I want to try and adopt Scrum to these different things." So a bunch of people are very interested in American government issues and passing bills, and all that stuff.

When we got together again at the end of this conference, the one universal discovery of every single group was that, if you took... And as you kind of said, the scum guide Scrum, the sort of have a product owner and write your user stories this way, and do things like that, that was basically the principles of Scrum codified for software development.

And as soon as you want to apply and get all of the benefits out of Scrum in other contexts, you had to ladder up, move away from the specific practices, and move more back to the idea of the principles.

So that would be the same ones. So if you were going to adopt Scrum for marketing, you don't want to give people Mike Cohn's classic texts. They won't be able to connect with it. It comes back to, again, the empathy, or just disconnect.

Ray: Yeah. "This is an IT thing. I'm not interesting."

Simon: Yeah.

Ray: Yeah. It doesn't fit my bill.

Yeah. It's a work management methodology more than a, well, anything to do with IT, frankly. It just, as it happens, it's history is in IT.

Simon: Well, even that I would actually deny because..  so you called about Cynefin before, and Dave Snowden and I ran a series of workshops in Sydney, I think it was last year, about scaling organisational agility using Cynefin.

We had a bunch of people there. So to give you a little bit of background, Dave and I have run a series of invitation only seminars that are all about creating these self sustaining scaling Agile and Lean adoptions by blending together complexity science, Agile and Lean thinking. We've been calling those CALM. We've run one of those in the UK. We've run one in Boulder, Colorado, and I keep on threatening to run one either in Australia, New Zealand and call it CALM Down.

But one of the things that came out of that is that we were doing these joint workshops, and it was a backwards and forwards between me and Dave, with Dave going right "I am the god of complexity" and I was filling in the Lean and Agile bits. And I had a few people in the audience going, "Oh, exactly this. I don't want to hear about Scrum. That's some IT rubbish. I do real work. I handle real problems and people, and I'm not a nerd."

That's when I always like to go back to two things, which is the original Scrum paper, The New New Product Development Game, and everything it's based on. If you really want to go back to the next step, you're going to go back to Deming's PDCA cycle, which is fundamentally what Scrum is.

But if you read that first paper, the first paper that used the word Scrum, there's no software in it. They are talking about building photo copiers, printers. They are talking about traditional product development. Those cross functional teams have no developers, no testers.

Ray: That is a manufacturing context though, still. It is still fundamentally technology.

Simon: Not even the manufacturing part. It was the product development bit. It was far closer to Lean Startup than anything else. It was, like, how do you solve the problems? It doesn't actually get to that manufacturing step, and it depends on where you see the Scrum epoch. If you see the Scrum epoch as Easel corporation in about '93, and that's kind of the beginning of Scrum with Jeff Sutherland. What Jeff and Ken did was take these Scrum principles and codify it for software, and that's just where most people connected with it, not realising that it actually started off as a general business process.

So the codification of it, what you now see in the Scrum guide, is very, very IT. But all of the principles were fundamentally about saying, "Hey, silos aren't awesome. Interruptions aren't awesome, and they are wicked problems." They often happen in product development, because you're not trying to build the perfect printer. You're trying to build a printer that was good enough in an economically viable time fame.

Ray: And appeals to the market.

Simon: Yes, and appeals to the market. 

That would bring you, I think, to the third challenge, I think, in Scrum for the business is reinforcing the silos. So I think one of the biggest failures of Scrum for the business is when you get the IT Scrum team, and then the marketing Scrum team, and then the sales Scrum team.

People just reinforce their silos, and you have Scrum teams talking to each other.

Ray: Yeah. Absolutely. So much of the cross functional team.

Simon: Yes. It's cross functional as long as everyone is like me.

Ray: Yeah.

Well, I suppose that does bring about another problem. If you're gonna have a cross functional Scrum team that involves business representatives, actually you've got suddenly a very large number of central skill sets in that cross functional team.

There comes a point when actually that's gonna be quite challenging to adopt what's conventionally the Scrum methodology over the top off.

Simon: Oh, absolutely.

Ray: I personally haven't worked with an organisation yet that has managed to put that many people in a cross functional team, other than, I guess, startups, which are naturally like that. Have you worked with any of those types of teams?

Simon: It depends on what you mean. So this is kind of when you would also go back to letting go of some of these practices.

So at the risk of being branded a heretic, if you have a look at some of these Scrum rules, like your Scrum team should be five to nine people, and if you get ten people you must split the team, otherwise it will all fall to bits.

All of that comes from a context when daily Scrums were a bunch of developers sitting around a table. If you actually have a look at Ken's original black book, in the appendix it refers to the source reference material where that number came from. It's a paper from about 1956 about memorizing phone numbers. It all has to do with people's ability to process a certain number of events in their short-term memory.

That whole five to nine workgroup thing became irrelevant the day that somebody wrote something in a Post-it note and put it up on a wall, because now you have what's called an exocortex, and you don't have to verbally communicate absolutely everything, because you don't have to keep it in your head. You can now visualise things.

Ray: So you still have the same problems with maintaining one's relationships. I mean, the other paper that backs up those numbers is Richard Dunbar's research into team sizes. But the output of that was actually those kind of team sizes make sense from the number of close relationships you can maintain.

Simon: But that's 147.5, not nine.

Ray: Yeah, although... Yeah. So he was talking about different qualities of relationship.

Actually, to guess, kind of extrapolating from that, there were numbers around... I can't remember exactly, but it was around about nine, for the closest relationships you could maintain, or the number of closets type of relationship you can maintain. Now, obviously, you don't necessarily need that level of relationship in a working environment. But the implication is that, actually, teams that can stay at that level can intrinsicly maintain a close relationship as a team than larger teams.

The implication being productivity and all those sorts of things from a communications standpoint. So I guess you do still start running into those communication, collaboration, relationship problems more as you extend beyond that.

Simon: I'd throw two things into that, and I'm acutely aware that I think we're running out of time.

Ray: Yeah. We're pretty much there.

Simon: The issue you have with that, and you have it in Scrum anyway, is that all of this stuff, in some ways, in a modern business context, is almost theoretical or irreverent. Because somebody, again, asked me recently at a course, "Have you ever seen a perfect Scrum team?"

I said, "Yeah. I've seen a couple of perfect Scrum teams. But they haven't lasted," because the instant that you lose somewhere between two and three people, and you get new people, you've lost that interpersonal dynamic, and that's now a new team.

So the idea of being religiously attached to a team size of nine people when it's not the same nine people at the beginning of the year at the end of the year...

Ray: Yeah, doesn't make sense.

Simon: ...Is basically denying reality. That's ridiculous.

The second thing I would say is that you don't have to maintain these tight relationships with people that you are not interchanging tiny, defined pieces of information with at a rapid sort of basis. So it would be easier if I could draw this, but this is where you get into sort of the organisational complexity.

I don't now how far you've gone into [inaudible] work, but in side a team, a person might be an object. From the point of view of a larger sort of value stream, the teams themselves are the objects. You actually have functional teams and teams, and it's only the interface points that have to have the close relationships.

So I think it's a fairly simplistic view to go, "Oh, okay. If I have 150 people or 200 people, or 500 people in my organisation, I have to have a daily Scrum that's now taking more than one day to complete," because you don't need to know what this person at the end of the value stream is doing if you're at that end of the value stream... Is doing, but you do need to know what... The information still needs to move backwards and forwards.

Ray: Yeah. The implication of that, then, is that, actually, you are better off increasing team size than you are number of teams, because then you are more rapidly exploiting your number of interface points if you are increasing your number of teams.

Simon: Yeah.

Ray: So, as you said about a second ago, we are pretty much out of time. So thanks everybody for listening in.