Labcast: Moving to Scrum? Easier Said Than Done
Labcast: Moving to Scrum? Easier Said Than Done
Though usually associated with product management and development, few realize that there’s a lot more to Scrum than just software. In fact, companies of all shapes and sizes have successfully applied the Scrum process to improve productivity in all areas of their business. Heck, even some churches use Scrum these days.
But no matter what type of organization you might have, making the transition to Scrum is no easy task, and not everyone is prepared for the challenge. In our latest podcast, Scott Downey, owner of RapidScrum.com, calls in to discuss some of the hard truths organizations need to come to terms with before transitioning to a Scrum way of life.
For more from Scott, check out this short video series from OpenView Labs on the nuances of a Scrum transformation:
- Overview of a Scrum Implementation
- Comparing Slow and Expedited Scrum Adoptions
- Moving to Scrum: Beyond the Basics
Brendan Cournoyer: Hello again everyone and welcome to this episode of Labcast. I’m Brendan Cournoyer, and today we’re joined by Scott Downey, owner of RapidScrum.com. Scott, how are you doing today?
Scott Downey: Doing well. How are you?
Brendan: Very well. I appreciate you taking the time to chat with us. I basically wanted to talk to you. I came up with this idea based on a post that we actually excerpted from your blog, which we called “The Six Hard Truths about Moving to Scrum.”
What I liked about that post and what I told you earlier was it wasn’t really evangelizing, necessarily, why Scrum is so important at what it is. It was really focusing more on this is hard; there are some hard truth to comes to grips with.
Before we get into them, I thought it might be interesting for you to tell me, based on your experience, what inspired that post? Is this something that you see a lot where people say “Yeah, Scrum’s great” and then they get a rude awakening once they actually try to implement it?
Scott: Absolutely. In my experience, it’s been the case that almost everyone who wants to bring Scrum into an organization, wants to bring it in to fix some other group. Very few of them actually want to bring it in because they want to be better or because they want to optimize their team or because they want to optimize their personal job performance.
Whether it comes from a grass roots perspective and they’re trying to fix the executives or vice-versa, the executives are trying to fix the teams. It’s usually the case that neither side expects to have a great deal of change going on in their world because they think they are already doing the right job.
I was wanting to with this article — that you guys cited — make it very clear to everyone that in an organization that’s making the transition to Agile; every person in the organization is going to have skin in the game. If you’re going to take it seriously and if your goal is seriously hyper-productivity and increased customer satisfaction, you’re going to have to change how you’re doing things if you’re not already there.
Brendan: One of the points that you focused on initially is basically that Scrum is not for everyone and I think you touched on that just now. Who is Scrum for? Who are the kinds of people that are really going to have success based on their goals with Scrum?
Scott: I have never seen an environment where Scrum could not be meaningfully applied so I want to make it clear that it has nothing to do with the product, with the technology or even with the market that you’re in. If you’ve got a group of dedicated people focused on the goal, Scrum can work for you.
Now, that being said, Scrum is not for everyone because not everyone is going to do the hard work. Just like riding the Tour de France is not for everyone because not everybody is going to be on a bike six hours a day.
What I’m trying to point out that if you’re an organization with a sacred cows in the corner offices and certain things that can’t be changed or won’t be changed because the organization holds certain things historically sacred, Scrum is probably not going to do that much for you except annoy everyone and make everyone unsure how to do their jobs for a period of time because it is a huge learning curve. It’s a huge switch of mindset. If you’re not going to actually do it then you’re probably just going to annoy a lot of people.
Brendan: What you also mentioned was another point that I wanted to bring up. Scrum is not about software, even though it’s most often aligned with an Agile practice or product development. Even here at OpenView, we use Scrum for our recruiting team, for out marketing team, for our research and analytics. We’re not creating software at all but we’re just using that to improve the productivity of those processes. Do you think that’s still something that a lot of people just don’t know?
Scott: Absolutely. One of the things that makes me absolutely crazy about the Agile community right now is that we’ve done a pretty good job at getting the basic message out there and now we have a lot of coaches who cannot go into a company without talking to them about the architecture of their software.
That’s not what companies need from us as Agile coaches. They need us to teach them how to do the Agile process so that they can invent the best architecture or so that they can choose the best tools to achieve their goals. It’s not about us coming in and telling them what language they should be writing in or how to even write and Agile spec. That’s not something that is part of the basic definition of Scrum.
What is so hard for people is to understand that this basic framework is equally applicable in hospitals, in churches, in charity organizations, recruiting organizations like your own, design and marketing organizations. It has nothing to do with software. It’s a group of people with a clear goal.
Brendan: In your post, you even mention that there are churches that use Scrum. Isn’t that right?
Scott: Yeah, absolutely. In fact, I’ve worked very closely with Jeff Sutherland over the last five, seven years. Something like that. Jeff is, of course, the founder of Scrum and his wife is a Unitarian Universalist minister and she has applied it to four of her churches. To me, the thing that’s so interesting about that is we tend to think of defining business value, which is a critical part of organizing your product backlog, as being something that’s measured in terms of dollars.
Ideally, churches are not measured in terms of dollars. They’re measuring it in terms of other things, depending on what that particular organizations goals are. Same thing for charitable organizations. They should not be measuring dollars probably. They should probably be measuring how many people they can help. What is valuable to different organizations varies by organization.
Brendan: You’ve touched on this other point previously as well. Basically, Scrum won’t fix your company but it will shine a light on some of the things you’re doing wrong and I would imagine that’s probably one of the biggest challenges. People might not be really willing or really at that point where they’re ready to accept “Hey, all of this stuff that I thought was the right way of doing things maybe isn’t as productive and isn’t as fruitful as I thought and Scrum is telling me this.” There’s probably a lot of resistance there as well, right?
Scott: Absolutely. I had a class not too long ago with a client where, I forget the guy’s title, EVP of something impressive. When I got to the section of the introduction course where I was talking about you have to measure the value of documentation, don’t just do it reflexively. Be sure it’s actually filling the goal that you think it’s filling and creating the business value you think it’s creating.
He just could not get past the fact that well, of course you’re supposed to document everything in great detail as you go along. My only response to him was “document it if you see that it is worth what you think it’s going to be worth but don’t just document it and hope that there’s value in that because that’s creating a huge amount of burden on the team that’s slowing them down. You could have more working product that’s less well documented if the documents weren’t any good in the first place.”
I think that’s the kind of thing we often see, especially when the executives are the ones who initiate the adoption. The executives will typically think of bringing Scrum into the organization much like they would think of bringing in a new integrated development environment. Here’s a tool for the team to go us. Just let them go use it and it’s not going to bother me on my day to day life. Here’s a tool. Go do that.
What they never seem to expect because, again, I think, I blame the Agile community for not having done a good enough job of preparing people for that. They never expect them to have a non-stop stream of issues to be surfaced for their attention and for their resolution. That’s what Scrum basically is.
At its core, it is an impediment surfacer. It’s going to help you find out what’s wrong with your organization and it’s going to help you, through your own hard work and focus, fix the organization so that it becomes more productive. There’s nothing magic. You have to work it or it doesn’t work.
Brendan: Sure. Like you said, and like you said in your article as well, this can effect the organizational structure of things when Scrum shows you some of the ways to really improve. When you have a lot of people with these management roles and higher level roles, there’s going to be some resistance there as well if suddenly some of those responsibilities shift, right?
Scott: Quite often. One of the things that I think works well, and we are talking about predominantly software. While Scrums isn’t just about software, we are predominantly talking about that. In that regard, I think there is a built in dysfunction of software organizations that actually lends itself well to Scrum adoption.
Let me explain what I mean. Historically, the way that we’ve promoted people is we take the very best developer that you can find and we give them more responsibility and Tech Lead but generally in the software organization or software world, we don’t typically tell them what it means to be a tech lead.
We just start calling them a Tech Lead and ask them to keep doing everything else. Then they get promoted to manager and director and vice president and so on so that at some point, what you’ve done is promoted someone well beyond what their skills were that got them attention in the first place.
What I typically see among managers in many organizations is that they are not really in a job where they are happy. They are not really in a job where they feel maximized or most efficient. Ultimately what they would like to do is step into a different role but now they’ve got the golden handcuffs and, organizationally, they don’t know how to start doing better work.
As Scrum comes in and the transparency that Scrum creates begins to move throughout the office place, the first thing everyone feels is threatened. If you’re in a job that you don’t feel qualified to do, you begin to feel threatened because suddenly you feel like you’re going to be exposed and you are. You are going to be exposed but the good news is, if you also have been making valuable contributions in another vein or under a different title, then the Scrum organization is going to ask you to do more of that and less of this.
Ultimately, long term, people wind up being able to move back into their core competencies and work more effectively for the entire organization. They become happier themselves because they no longer feel like they’ve been promoted beyond their own skills.
Brendan: I’ve got one last question for you and this is one that I can speak from personal experience having come into a situation when I first came to OpenView, where I was introduced to Scrum. Having worked at a completely different sort of business environment for several years, it’s shocking. It’s a little intimidating. It’s a little what, we’re doing this? It’s a real culture shock at first because Scrum is very unique and the way you go about getting work done and working with your team is very different.
It can be very challenging for new people in the organization to really adapt to that if they’re not used to that. Should that play in to hiring decisions for new hires and new people that you’re adding to the team. Are they going to be able to fit in and adapt to this Scrum way of life?
Scott: Beyond the shadow of any doubt, yes. That’s the most critical thing that you can do. If you’ve decided to take your organization in the direction of Scrum, you’ve got to be sure that you begin to build and extend your organization with that in mind and bringing people who are going to support it. I worked recently with an organization that had brought me in as a Scrum coach hoping that I could make this great transformation without, of course, annoying any of the executives.
At the same time, they brought in a rabid project manager. Absolutely must be in a gap chart, complete waterfall, got to have a two hour project planning meeting per day kind of project manager. Their goal was let’s just see which one wins. After doing this for a short period of time, I couldn’t tell you which one of us won, but I can tell you the organization lost. Their lack of focus, their lack of commitment to one process or another led them absolutely over a cliff.
I’m not going to name organizations but this particular organization does not exist anymore today and it’s because they weren’t willing to make a choice. They weren’t willing to commit. They weren’t willing to change how they did their recruitment, how they on-boarded new employees.
Ultimately, this can be a very destructive thing to do to your organization. That’s what I was trying to point out with this article. Be serious or don’t do it. One of the other things that we typically will find, there’s several studies and papers out there that confirm this, is that when you bring Agile or Scrum into an organization, it can cost you up to 20% of your head count. Up to about 20% of the people are just not going to dig it, they’re not going to get it.
They enjoy being the information aggregators instead of a participant in a team. They are more concerned about themselves and promotion than making their team and their organization successful. They’re just not going to get it. They’re going to fight. They’re going to resist and ultimately, you’re never going to achieve the goals that you had when you adopted Scrum. You’ve got to make that decision.
Here’s the risky part. If you begin the Scrum adoption, about 20% of the people are also going to find that Scrum is the most appealing thing they’ve ever heard and, if you back out, they’re going to leave. We’re talking about some serious issues here. There is potential for a dramatic of head count turnover when you begin to either bring Scrum in or take Scrum out.
If I could just take a moment and tell a story. It was Con Ed, the power company up in your area of the country. I think it was back in the late 70’s or early 80’s, they began to get hit constantly with these environmental concerns that wherever their people had gone to work, they left their work sites in worse shape. They left it polluted. They left it really torn up.
The Con Ed leadership said we’ve got to fix this. This is going to be a PR disaster for us if we don’t get in front of it so they came up with an idea. They told their engineers, when you go to a work site, you don’t just leave trash all over the place and you don’t just pick up your trash, you leave that work site better than you found it. You pick up all the trash. You restore it to better than it had been before you left.
Something that’s relatively analogous to refactoring code is you go through and introduce new features. These engineers said you’ve got to be kidding us, there’s no way we’re going to do this, we’re very highly skilled professionals and we’re going to do it. At this point, Con Ed leadership had a decision to make. Was the potential of the PR nightmare big enough that they had to annoy their engineers and they decided it was and the engineers predictably went on strike and eventually quit and they had to all be replaced. This was a very dramatic and scary time for Con Ed.
Brendan: I bet.
Scott: Yeah. But then just a couple of years later, after they had rebuilt their engineering teams, what they found was, you can go to any engineer out there and say how do you feel about site clean up? They would oh, it’s critical. We absolutely have to do that for the health of our organization and for the good of the community. Because they had made that critical step, they had, number one, decided that the switch in this policy was worth more than the individual head count. This was critical to the success of the organization and to the health of their business.
Number two, they had changed how they were recruiting people so they were only bringing people into these roles who would support their direction. Same can be said of transitioning any organization to Scrum. You’ve got to be willing to stand firm. You’re going to have people complaining about, I’m a director, what do I do anymore? You need to have answers for that. This is a big scary time for everyone involved. Don’t jump into it lightly. Don’t jump into it because someone mentioned it to you at a cocktail party or told you you’d have whiter teeth and fresher breath because of it. You need to know what you’re getting into to.
Brendan: Sure. So, Scott, thanks very much for taking the time to chat with us today and people can check out more from you and find more information at RapidScrum.com, is that correct?
Brendan: Excellent. Well, thanks very much again and hopefully we’ll get to do this again sometime soon.
Scott: I look forward to it. Thank you.