All Things Agile - Episode 006 - Jeff Sutherland Interview

Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban

I am pleased to share an interview with Agile pioneer, Jeff Sutherland. Jeff is a founding father of Scrum and Agile. He is a noted author and speaker. Jeff provides insight to many of the largest organizations in the world. In this episode, Jeff addresses some of the tough issues facing today's organizations. Please take a moment to listen using the link below or subscribe to the podcast using this link.
Please visit Jeff's website: scruminc.com to learn more and check out available courses. During the episode, Jeff mentioned several great books which are linked below for your convenience. Please take a moment to pick up a few copies for your Agile teams.
Scrum: The Art of Doing Twice the Work in Half the Time
All Things Agile - Episode 006 - Jeff Sutherland Interview
Transcript:

Welcome to the All Things Agile Podcast – your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast on iTunes and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Ronnie: Hello everyone and welcome to the All Things Agile Podcast. I’m very excited to announce that today’s guest is Jeff Sutherland. He’s a true legend in the world of Agile, especially Scrum. He’s a founding father of Scrum and also an original participant in the Agile Manifesto. I’m very excited to have him on today’s show and I’m hoping that he can shed some insight into how implement Agile teams in larger organizations. So let’s go ahead and get started. First off, thank you Jeff for joining us today! Regarding my first question, I’d like to know what is your input or advice on how to implement Agile successfully in today’s global workforce where we often have teams that are spread across the globe: India, China, etc. How can we implement Agile successfully even if our teams are globally distributed?

Jeff: Well, first of all, Scrum simplifies their already complex Waterfall implementations. So Scrum is easier to implement globally than traditional approaches. I’ve worked with many skilled firms over many years – the first one was actually IDX, now GE Healthcare, which was a competitor to McKesson and in fact, the head of marketing – Pam, at IDX who worked with me, implementing Agile there, went on to become the CEO of McKesson; she might still be there, I don’t know, I haven’t checked recently. But she was probably there when you were doing your Agile transformation.

But IDX, at the time, had 8 business units. Each business unit had a minimum of 3 products. Many of them were acquired technologies, acquired companies, mainly in the United States, but some teams that I’ve worked with were in Europe; but scattered all over the place. So we scaled Scrum in a big way. One of the best teams was actually in 3 locations across the continent. So I’ve written about at least a half a dozen papers on good distributed implementations of Scrum, and Scrum is the only way of doing software that allows you to actually scale up without losing productivity per developer. As soon as you start to scale Waterfall, the productivity per developer goes down. It starts to drop radically once you get more than 6 people, which is why we keep Scrum teams small. But by keeping Scrum teams small and then using the scalability mechanism that we do, we actually have several case studies now which are the only ones every published showing that you can scale globally and when you scale, you can get linear scalability by adding teams.

Of course, you have to do Scrum well. Now, one of the problems with any kind of distribution – Microsoft did a study on this a few years ago in a process group – and they found that in every case, in 10 years of doing Microsoft distributed development, in every case, it delayed the project, it increased the project risk and it increased the dysfunction on the teams. And so, any time you distribute, those are the 3 things that you have to deal with. And as I’ve said, Scrum can effectively deal with all of them, but only if you run a very good Scrum locally. Then you can distribute it. If you distribute a bad Scrum, then you magnify the dysfunction when you distribute. But that’s also true with Waterfall. So, in the worst case, Scrum is better than Waterfall.

Ronnie: Okay – and maybe just a follow-up question to that: In your opinion, when an organization is looking to adopt Scrum and globally distribute, have you found that it’s easier to sort of treat the teams all as equals, if you will? Each one’s equally able to grab work from a bigger picture from the product backlog, or do you think that it’s easier to delegate certain either component areas or certain pieces of functionality to particular teams; or do you think that creates too much of a siloed pigeonhole?

Jeff: You always want to maximize the feature teams. You always want to have cross-functional teams and have every capability on the team that’s needed to get to a ‘done’ state. One of the most interesting models today in scaling is Spotify because they elegantly did what I try to do at GE Healthcare. And what they’ve done is they have almost all features-driven teams. They do have some component teams, but almost all features-driven teams and all features-driven teams have a visible piece of the Spotify user interface. And every team can upgrade their piece of the product, every sprint, without disrupting any other piece of the product. And so, by making things visible for every team, and really managing the architecture and the dependencies properly, it gives them a very powerful way to implement a really cool product. And they really have to be fast and they really have to be Agile because their competitors are Amazon, Google and Apple. And any one of them will crush them if they don’t run fast enough. Google, Apple and Amazon are like a big tsunami, all coming at them at once and they have to run fast enough so that the wave doesn’t crash on them. Basically, they use Agile globally to do it. So I’d recommend that your people really study the way Spotify has done this.

Ronnie: Excellent. If we look at that, it does make a lot of sense. I guess the next question I have is in relation to more of the program or release level type planning and the question is really regarding: when you have teams kind of more in the trenches that are in the process of adopting Agile, however you may still have parts that work large organizations at the program level or they’re trying to work through what’s going to be in a particular release and they’re still in Waterfall mode. Do you have any advice for organizations that – the trenches may be adopting Agile, but maybe at the top level, they’re still kind of left in Waterfall?

Jeff: Well, basically that’s the way Scrum always started. We started in the middle of a big Waterfall implementation. So it’s not only common, it’s the usually problem when companies are starting off. And what we find, if we look at the success rate of traditional projects vs. Agile projects, even though there’s a lot of bad Agile out there, we publish data this Danish group gave up in our book on software in 30 days last year and the data showed clearly that about 10 years’ worth of Agile vs. traditional projects and over 50,000 projects showed that the success rate for traditional projects was 14%. 86% were either late, over budget, with unhappy customers or complete failures, nothing ever delivered. Whereas on the Agile side, and this is global data, worldwide averages, the success rate for the Agile projects was 42%. About 3 times the success rate of traditional projects. And many, of course, of these Agile projects are embedded within Waterfall. So what that means is that when you’re doing Scrum inside a company that’s doing Waterfall, you’re going to be 3 times as effective at delivering your piece at the right time and 86% of the time, the Waterfall part of the company is going to be late.

So that means that every Scrum team working inside that environment needs to get a very clear commitment from Waterfall on dates and they have project managers that are supposed to do that. In fact, that’s the big role of the project manager that’s left since Scrum doesn’t need them. So the Waterfall project managers have to commit to a date; the Scrum teams with their product owner will commit to the date and most of the times, the Scrum teams will hit it and then traditional implementations will fail. So the Scrum teams always have to have a Plan B so they need to clearly articulate to the management that when the Waterfall teams have missed their date and that they’re going on to Plan B and they should be called when the Waterfall team fixes their problems.

One of the things that we sometimes see is that when the Waterfall teams are late, which they mostly are, then they say ‘Well, the Scrum teams – you guys are faster so we’ll just put you on the Waterfall teams’ which is a really bad idea, because it just slows the Scrum guys down to Waterfall speed. A better idea is for the Scrum guys to say ‘Look, we’re faster than you are – give us functionality, we will Scrum it – we may need some of your people to do that, but we can produce it much faster’. If you do that, Scrum will gradually grow in the organization and start to drain the swamp of failed Waterfall projects.

Ronnie: Okay, excellent. I guess, my next question would be again in relation to large organizations, is on the subject of documentation. Obviously one of the challenges that a large organization gets is bureaucracy. That there are typically already in place a lot of gatekeeping documentation and they often times have so many different departments and one department hands off another’s keys to another – and in your experience, when implementing Agile or in particular Scrum at a large organization, what advice do you have on the subject of documentation? Ensuring that you have enough, but at the same time, that you’re still able to move quickly?

Jeff: Okay, when Scrum launches just enough documentation and every time I ask anyone: do you have just enough documentation? They say: No! And I say: Well, take a look at what you got and get just enough. When I’ve actually looked with them, we find that about 68% of their documentation is totally useless and they’re actually missing a little bit – about 10%. That’s what we seen at some big companies. And companies that are doing medical devices that have to be FDA compliant, FDA certified we find that – one of my partners recently went into a German medical device company, they had 12,000 pages of documentation for an implant medical device. So he actually took that documentation to the FDA and said: Is this just enough? And the FDA said: Are you kidding? We won’t even read 12,000 pages. What are those people thinking?

So he worked with the FDA and after 6 months, he got it down to 800 pages. So this is what we typically see on these high documentation traceability projects. Companies are generating 95% of what they’re generating is totally useless. The FDA doesn’t want it. And when you get it down to just enough documentation, only 5% is needed. So what Scrum will do in any company is ask the question: Do you have just enough documentation? If the answer is no, then they’ll look at what is just enough and when they determine that, they’ll make that really clear to the management and the rest of the company.

If the management insists on producing 95% junk as in the case of the FDA compliant people, then nobody can help them. They’re just going to waste a lot of money. But what Scrum will make it clear is what is that’s just enough, what do we really need and we’ll get that on the table.

Ronnie: Okay, perfect. I guess the final question I’d like to ask you about is in sort of the executive buy-in and dealing with some of the political aspects. When you often have large organizations, you may have some well-entrenched executives that maybe they don’t quite get Agile or they may be stuck in their ways, so can you give some suggestions if you had some people that are working on their Scrum teams and running into some roadblock with their upper executives? Do you have maybe some book recommendations on anything you’ve worked on or a colleague worked on that may be beneficial to recommend to an executive?

Jeff: In many companies – my company, Scrum Inc. does a lot of management workshops. Mostly with the senior management. With the middle management, you want get them all in the certified Scrum Master training so they really understand how it works and what they need to do from a management point of view. Without that training and education, it’s pretty hopeless because management – if management doesn’t know what Agile is, then they tend to do things that actually disrupt it and cause it to either go slow or fail outright. Just out of being clueless. So education and training is really critical.

At the end of the day, there may be people that are more interested in maintaining their empire than they are in furthering the organization. And senior management has to deal with that. I remember one global telecom company went completely, 100% Scrum all at once and the Scrum trainer that was leading the effort was communicating with me, he said: Yeah, is this going to work? And I said I’ve already written a paper on this, it’s called ‘Hitting the Wall’. What happens when you take a global organizations, take them to Scrum all at once.

What happens is they run into their biggest impediment really fast, and depending on what the management does at that time, that will tell you whether it’s going to be successful. And the Scrum coach and trainer said they’ve already hit the wall. I said: What was it? He says there were 30 managers that were getting in the way and the CEO just fired all of them. So at the end of the day, there may be some housecleaning needed.

Ronnie: Yeah – but that’s one of the greatest advantages to Scrum, it’s that it really exposes what was already there. Well, I think that’s an excellent suggestion. If it comes to organizations that I’ve personally worked at, have provided certification, training to some of their middle and directorial-level positions and I do think that was really helpful. And it is very interesting that you mention that you do have workshops for some senior management and that’s really great to point.

If someone wanted to find out more about yourself and about your company and the services that you provide, where do you recommend that people take a look?

Jeff: Well, they can certainly go to our website: ScrumINC.com. They can send me an email: [e-mail] and I’ll get back to them.

Ronnie: Excellent. And do you have any particular books or works that you’ve written or your colleagues written that you’d definitely recommend?

Jeff: Yeah, there are two books that were written last year. One of them is actually really good for managers – it’s written as a novel. It’s the story of a company that was in big trouble; how they brought in Scrum and how they turned a disaster into a success. And it’s not a long work, you can read it in a few hours and you really get the basic ideas. The other more IT-focused book that I did last year with Ken Schwaber ‘Scrum in 30 Days’ and both of these books are on Amazon. An even more interesting book is up on Amazon but will not be released for a few months; it’s called ‘Scrum: The Art of Doing Twice the Work in Half the Time’. And it is a book for the general business reader and Randomhouse founded this in their business book ‘Division’ and they wanted it at least 80% of the examples outside of IT. And so this is a really good book for the general business guy to get a handle on what is Agile, what is Scrum all about? What are its benefits, what are the key principles? How can it help my company? So, ‘Scrum: The Art of Doing Twice the Work in Half the Time’ – you can go to Amazon and preorder it.

Ronnie: Okay, excellent. I’ll definitely provide links to those. That concludes all my questions. Jeff, I’d like to thank you for your time, I really appreciate it!

Jeff: Okay, thank you! I enjoyed talking with you!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!