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 destinationfor tips and interviews with the leaders in the world of Agile. Don’t forget tosubscribe to this podcast on iTunes and please check out our sponsor:TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

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

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

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

Of course, you have to do Scrum well. Now, one of theproblems with any kind of distribution – Microsoft did a study on this a fewyears ago in a process group – and they found that in every case, in 10 yearsof 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 dealwith. And as I’ve said, Scrum can effectively deal with all of them, but onlyif you run a very good Scrum locally. Then you can distribute it. If youdistribute 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 betterthan Waterfall.

Ronnie: Okay –and maybe just a follow-up question to that: In your opinion, when anorganization is looking to adopt Scrum and globally distribute, have you foundthat it’s easier to sort of treat the teams all as equals, if you will? Eachone’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 orcertain pieces of functionality to particular teams; or do you think thatcreates too much of a siloed pigeonhole?

Jeff: You alwayswant to maximize the feature teams. You always want to have cross-functionalteams 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 becausethey elegantly did what I try to do at GE Healthcare. And what they’ve done isthey have almost all features-driven teams. They do have some component teams,but almost all features-driven teams and all features-driven teams have avisible piece of the Spotify user interface. And every team can upgrade theirpiece of the product, every sprint, without disrupting any other piece of theproduct. And so, by making things visible for every team, and really managingthe architecture and the dependencies properly, it gives them a very powerfulway to implement a really cool product. And they really have to be fast andthey really have to be Agile because their competitors are Amazon, Google andApple. 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 andthey 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 reallystudy 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 Ihave is in relation to more of the program or release level type planning andthe question is really regarding: when you have teams kind of more in thetrenches that are in the process of adopting Agile, however you may still haveparts that work large organizations at the program level or they’re trying towork through what’s going to be in a particular release and they’re still inWaterfall mode. Do you have any advice for organizations that – the trenchesmay be adopting Agile, but maybe at the top level, they’re still kind of leftin Waterfall?

Jeff: Well,basically that’s the way Scrum always started. We started in the middle of abig Waterfall implementation. So it’s not only common, it’s the usually problemwhen companies are starting off. And what we find, if we look at the successrate of traditional projects vs. Agile projects, even though there’s a lot ofbad Agile out there, we publish data this Danish group gave up in our book onsoftware 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 thatthe success rate for traditional projects was 14%. 86% were either late, over budget,with unhappy customers or complete failures, nothing ever delivered. Whereas onthe Agile side, and this is global data, worldwide averages, the success ratefor the Agile projects was 42%. About 3 times the success rate of traditionalprojects. And many, of course, of these Agile projects are embedded withinWaterfall. So what that means is that when you’re doing Scrum inside a companythat’s doing Waterfall, you’re going to be 3 times as effective at deliveringyour piece at the right time and 86% of the time, the Waterfall part of thecompany is going to be late.

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

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

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

Jeff: Okay, whenScrum launches just enough documentation and every time I ask anyone: do youhave just enough documentation? They say: No! And I say: Well, take a look atwhat you got and get just enough. When I’ve actually looked with them, we findthat about 68% of their documentation is totally useless and they’re actuallymissing 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, FDAcertified we find that – one of my partners recently went into a German medicaldevice company, they had 12,000 pages of documentation for an implant medicaldevice. So he actually took that documentation to the FDA and said: Is thisjust enough? And the FDA said: Are you kidding? We won’t even read 12,000pages. What are those people thinking?

So he worked with the FDA and after 6 months, he got it downto 800 pages. So this is what we typically see on these high documentationtraceability projects. Companies are generating 95% of what they’re generatingis totally useless. The FDA doesn’t want it. And when you get it down to justenough documentation, only 5% is needed. So what Scrum will do in any companyis ask the question: Do you have just enough documentation? If the answer isno, 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 thecase of the FDA compliant people, then nobody can help them. They’re just goingto waste a lot of money. But what Scrum will make it clear is what is that’sjust 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 theexecutive buy-in and dealing with some of the political aspects. When you oftenhave large organizations, you may have some well-entrenched executives thatmaybe they don’t quite get Agile or they may be stuck in their ways, so can yougive some suggestions if you had some people that are working on their Scrumteams and running into some roadblock with their upper executives? Do you havemaybe some book recommendations on anything you’ve worked on or a colleagueworked on that may be beneficial to recommend to an executive?

Jeff: In manycompanies – my company, Scrum Inc. does a lot of management workshops. Mostlywith the senior management. With the middle management, you want get them allin the certified Scrum Master training so they really understand how it worksand what they need to do from a management point of view. Without that trainingand education, it’s pretty hopeless because management – if management doesn’tknow what Agile is, then they tend to do things that actually disrupt it andcause it to either go slow or fail outright. Just out of being clueless. Soeducation and training is really critical.

At the end of the day, there may be people that are moreinterested in maintaining their empire than they are in furthering theorganization. And senior management has to deal with that. I remember oneglobal telecom company went completely, 100% Scrum all at once and the Scrumtrainer 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’scalled ‘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 impedimentreally fast, and depending on what the management does at that time, that willtell you whether it’s going to be successful. And the Scrum coach and trainersaid they’ve already hit the wall. I said: What was it? He says there were 30managers that were getting in the way and the CEO just fired all of them. So atthe 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 exposeswhat was already there. Well, I think that’s an excellent suggestion. If itcomes to organizations that I’ve personally worked at, have providedcertification, training to some of their middle and directorial-level positionsand I do think that was really helpful. And it is very interesting that youmention that you do have workshops for some senior management and that’s reallygreat to point.

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

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

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

Jeff: Yeah, thereare two books that were written last year. One of them is actually really goodfor managers – it’s written as a novel. It’s the story of a company that was inbig trouble; how they brought in Scrum and how they turned a disaster into asuccess. And it’s not a long work, you can read it in a few hours and youreally get the basic ideas. The other more IT-focused book that I did last yearwith  Ken Schwaber ‘Scrum in 30 Days’ andboth of these books are on Amazon. An even more interesting book is up onAmazon but will not be released for a few months; it’s called ‘Scrum: The Artof Doing Twice the Work in Half the Time’. And it is a book for the generalbusiness 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 areally 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 Halfthe Time’ – you can go to Amazon and preorder it.

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

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

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