All Things Agile - Episode 006 - Jeff Sutherland Interview

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:
[email protected] 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!