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.<o:p></o:p>

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?<o:p></o:p>

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.<o:p></o:p>

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.<o:p></o:p>

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.<o:p></o:p>

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?<o:p></o:p>

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.<o:p></o:p>

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?<o:p></o:p>

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.<o:p></o:p>

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