All Things Agile - Episode 011 - Ken Rubin Interview

Please checkout out this exciting interview with author of Essential Scrum, Ken Rubin. Ken is a distinguished author, speaker, and Agile instructor. He has worked with many of the nation's top companies, and he joins us in this episode to tackle some of the tough questions facing teams as they adopt Agile.

If you haven't already read Ken's great book, please pick up a copy of Essential Scrum on Amazon today!  You can also read Ken's blog and learn more about his services through his website innolution.com.

I hope you enjoy this episode and please remember to subscribe in iTunes. Do you have a question that you would like answered in an upcoming podcast? Please send your question to: [email protected].

All Things Agile - Episode 011 - Ken Rubin 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 in iTunes, and please check out our sponsor:
TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Ronnie: Hello everyone and welcome to All Things Agile. I’m
very excited to announce that Ken Rubin is our guest today on the show. Ken is a
noted author of Essential Scrum as well as being a public speaker and Agile instructor. Before we begin, a quick reminder that this podcast is for
informational purposes only and we accept no legal liability. So let’s get
started! 

First off, Ken, thank you so much for joining us on this episode.  I am really glad to have you on this show. I’ve given the audience just a quick
introduction, but can you please take a few minutes and explain a little bit
more about yourself, both personally and professionally? We really want to get
a chance to know you.

Ken: Sure! So my background is software engineering. My
degrees are all in computer science and I’ve had a typical path through most
software companies. I’ve been a developer, project manager, VP of Engineering
at a number of companies both large and small. I’ve done 10 startup companies
in my career, and I’ve taken two of those public on the NASDAQ. I did my 2 year
stint with IBM in the mid-1990s. I’ve helped companies and I worked with 130
people; we ran around North America building large distributed object systems
and if anybody’s old enough to remember, I came out of the Small Talk world.
Back in the late-1980s, I helped bring Small Talk out of the research labs at
Xerox PARC, and I worked with a startup company that was a spin-off of Xerox
PARC called Barclay System. We were the early market object technology folks.  So we brought Small Talk and object technology to the market.

I’ve been doing Agile since the early-1990s. Scrum,
formally, since 2000. In those days, I worked for a startup company in Colorado
called Genomica. It was a 90 person engineering team, and they let the VP of
engineering go. I ended up inheriting the engineering team which wasn’t
functioning all that well and we transitioned everybody over to Scrum. And that
ended up working out much better for us. And I’ve been using Scrum ever since,
about 14 years. These days, I spend my time out either doing Scrum training
classes and Kanban training classes or doing coaching. And, I hope that in our discussion today I can go over a number of
examples that I had the benefit of seeing a lot of different companies and
what’s working and what isn’t working.

Ronnie: Thank you for the introduction Ken. I’m really
looking forward to the insights you can provide us based on your considerable
experience. The first question I’d liked to ask you, regarding your book
Essential Scrum, is in regards to the dedication and introduction. It really got
me thinking about the importance of relationships and software. I also started
thinking about how relationships or soft-skills play into the success of Scrum.
What is your insight or your advice on how relationships affect Agile teams?

Ken: It’s a good question to start with. To me, the unit of
capacity in Agile is the team. Even the Agile Manifesto calls that out –
individuals and interactions over processes and tools. It really is about the
team. So how they interact with each other, how they perform is of outmost
importance. The relationships among the members of the teams is critical. If
you’re going to have self-organizing teams, they have to have trust in one
another. That’s one of the characteristics that, for me, distinguishes a group
from a team. Group, simply being a bunch of people that I threw together with a
common label. And honestly, the only thing they have in common are the T-shirts
they printed out that have the name of the group on it.

A team is a group that’s gone through the stages. Sort of the top most stages: forming, storming, norming and performing. And if
you can make a real investment to turn a group into a team, first, they had to
figure out these soft skills issues: how to work well together? Otherwise, they
would never become a high performing team, and they would constantly be at odds
with one another. So one of management’s responsibility is to help put the
right people on the team, but once they’re there, it’s the soft skills that
help bring these members together, that help them work well and function well.
In most Scrum classes, there’s an exercise: the Yes – And, vs the Yes – But
exercise. And the intent behind that – it’s actually an exercise that borrowed
from improvisational comedy training and the idea is to try and help teams
understand how to work well together, how to form those relationships, how to
take one person’s idea, build on top of it and not be in a Yes – But style
passive-aggressive cutting things down: ‘Yeah, I heard what you said; it seems
like a good idea but let me now tell you why it sucks.’ That’s not a foundation
for building a high performance team. If the soft skills are not addressed,
then likely you won’t have a style of organizing teams which are the unit of
capacity in doing Agile and for that reason, you’ll likely fail.

Ronnie: I definitely agree. What came to my mind is the book
‘Speed of Trust’ by Stephen Covey. It describes how trust is a major factor and
how people fill in the gaps in communication and that with a high trust
environment, the team is able to move more quickly.

Ken: I think it’s really important. How we disagree is as important
as how we do agree. At no point would I ever suggest that team members
shouldn’t disagree, or shouldn’t have a vigorous debate. They should do it though
in a very proactive way; in a way that’s reinforcing their ability to come up
with an innovative solution, not inhibiting that ability. So if they don’t have
the skills to work with each other and challenge each other, then very likely
that the best achieved is mediocrity.

Ronnie: Excellent point! And I think that leads into our
next question: There is a quote in your book that I love, which is that one of
the benefits of Scrum is that it really exposes existing issues. I couldn’t
agree more. It’s been my experience that Scrum really sheds light on underlying
problems or processes that are actually bottlenecks. One of the challenges that
I’ve seen is that sometimes the personalities and procedures that were in place
before adopting Agile may be discovered to be part of the concerns. Some of the
potential personalities involved may even be in leadership roles. So one
question I would like to ask you is, how does an organization work on improving
their adoption of Agile when much of the legacy culture, leadership style and
procedures are still in place?

Ken: This is actually a critical question and how people
respond in this situation, to me is one of the tell-tell signs as to whether
they’ll be successful – let me give you a specific example. Some years ago, I
was giving a management presentation during lunchtime in front of my boss. So
we budgeted 90 minutes, brought in food, the management team. So senior
management and director level people and some VPs are in the room and I made
the following comment; I said – by the end of your Sprint, you should get the
work done and you should have zero known defects on what you just built. And I
also mentioned that people that have historically been members of the testing
team should be fully integrated in with developers in a single team. They
should work together collaboratively with zero defects to get things done.

Immediately this lady in the back of the room raised her
hand. She said ‘This won’t work here’. I said ‘Why not? What part of that?’ She
said ‘I manage the QA team’. She goes ‘You just told me that I should assign my
people on to the Scrum team.’ Yes, right – we work collaboratively that way.
She said ‘Yeah, well here’s the problem. You also said that at the end of every
Scrum we should have zero known defects and the reason that won’t work is
because we compensate our testers based on the number of defects they find.’ So
she’s saying basically that’s not very motivating if you’re one of my testers
because you’re going to make less money if you do that.

Now, what she says next is the tell-tell sign for me as to
whether a company has a hope of being successful with Agile. Here’s what she
didn’t say. She did not say ‘Well, in that case, I’m just not going to assign
my people out on to the Scrum teams. I’m not going to do that, I’ll just keep
them together’. Meaning, I see the impediment. Agile has shone a bright light
on where we have an impediment. And rather than address the impediment head on,
instead what I’ll do is I’ll alter the definition of Agile so that that
impediment doesn’t exist. Now, companies that are bolted to that approach will
probably fail and fail quickly with Agile.

Instead, what she actually said was ‘I think I’m going to
have a conversation with the VP of HR and the VP of Engineering so that we can
discuss how we’re going to change the compensation plan for our testers’. Now,
we have in place people that understand that the current process, the current
compensation system is at odds with them being successful with Agile. And
rather than run away from the problem, hide when the impediment gets exposed,
we’re willing to address it head on. So my advice – if you don’t have the
executives trained or understanding these key points, you’re likely to have a
problem. By the way, her next comment – I mentioned other things; I don’t pull
people off of Scrum teams to work on your pet projects. Another person raised
her hand and said ‘I do that all the time – what else shouldn’t I do?’

At least in an environment like that, they’re willing to
entertain it. So my approach to trying to address the problem is the leadership
requires the proper kind of training and coaching principally on core Agile
principles. That’s where I try to focus with them. So if I can get 60-90
minutes with them over lunchtime, that’s a good start. Not as good as having
them in a multi-day class, but they’re not willing to make that commitment
usually. So get 60-90 minutes, help them to understand that core Agile
principles and hopefully they can align their behavior with how we’re going to
do agility downstream, cause if they don’t, we will have a serious disconnect
and companies with a better experience at that will likely fail in their
attempt to use Agile, because of that disconnect. It’s a critical question and
either they’re going to understand what we’re trying to do and embrace it, or
they’re not and these companies are going to have a hard time.

Ronnie: I love that example! One of the approaches that I’ve
seen previously is that the director VPs and executive teams actually complete
certified Scrum Master training. I believe that really helped them understand
the vision and what Agile teams actually need.

Ken: I find it beneficial when people like that, people with
high level titles actually attend the classes. Part of the benefit is not just
their understanding, which is profound, but a second benefit as well. You know,
for example – in one class, I was talking about how teams should give range
answers to questions as a way of communicating uncertainty. Range answers to
planning questions, like ‘When will you be done?’ Give a range answer: between
X number of sprints and Y number of sprints. And in this one class, an engineer
stood up and said ‘Yeah, but my management is never going to accept a range
answer’. And there’s only one person in this class – it was a large class – and
the only person in this class wearing a suit was the general manager of the
whole division. He then stood up, turned around and said ‘Well, I’m the guy
asking the questions and I’m telling you I’m willing to accept a range answer
and I’d like to talk to you about how we can keep range answers within one
calendar quarter – but yes, a range answer will be acceptable’.

That pretty much addresses the whole point right there.
People are looking at each other, are like ‘Okay – he is the guy who’s asking
questions and he just said he’s willing to do it and I guess we can actually
move on here under the assumption we can provide range answers’. So getting the
senior execs in a classroom, I think it’s a high priority – but it doesn’t
happen nearly as frequently as it should. Occasionally, I’ll get the luxury of
having a one day – and rarely, but it does happen – a two day class with
leadership. I would say one of every four classes I do, we have that hour to 90
minutes lunchtime conversation. Which is precisely an hour to 90 minutes good,
not as good as a half a day or a day or two would.

Ronnie: Great answer! Leading to my third question which is
adaptive vs. predictive, which is referenced in your book. One of the examples
that came to my mind was release planning. Could you please take a moment to
explain to our listeners adaptive vs. predictive and perhaps how it might apply
to release planning?

Ken: Be happy to. A lot of folks, when they think of
Waterfall, they think predictive. Predictive up front water. In Waterfall, we
have to put together the full requirements document on the first day, when we
have the worst possible knowledge we’ll ever have about that project. So to a
certain stage, you have to predict. If you’re being rude, you’d say you’d have
to guess what all the requirements are. A lot of people didn’t think of Agile
as adaptive – more just in time. So if you imagine like these two being on
either sides of a teeter totter or a see-saw, what I’d like to suggest is that
if you’re overly aggressive in either dimension, overly predictive or overly
adaptive, you’re probably going to be unhappy.

If you’re overly predictive, you’re probably just going to
dip down into the guessing pool. There’s a part of you who might say ‘You
couldn’t possible know that – not on the first day, not when you have the worst
possible knowledge you’ll ever have!’ At this point, you’re just guessing, and
that seems dangerous. On the other hand, if you’re fully adapted and you’ll do
everything just in time, which in the context of release planning would mean no
upfront planning whatsoever, my guess is that’s going to feel chaotic. Agile
isn’t about everything done and adapted just in time. It’s about finding
balance; balance between up-front work, predictive work and downstream adaptive
work. And where you set that balance point will be different for different
types of projects or products, different companies.

So let’s buy into the fact that it’s a misperception to
believe that Agile is anti-upfront planning. Because, of course, that’s simply
not true. Agile is anti-waste. And if you do too much planning upfront, then
you’re going to inject too much unnecessary planning inventory into the system
that’ll have to be reworked or thrown out when something goes wrong. So the
principle here is upfront planning should be helpful, just not excessive. In
the spirit of just enough, just in time. But there’s nothing in there that says
‘avoid upfront planning’ so release planning – if you very specifically look at
that, if you define what it means, in today’s world release planning is
becoming a harder term to use because in the past, a release typically was
performed after multiple sprints of work were completed. So in that scenario, a
release was larger than a sprint. But what about the teams that release every
sprint?



You can argue ‘Well, isn’t sprint planning the same as release
planning?’ Or what about teams that do continuous delivery or
continuous deployment. They can release every feature as it become available
during this sprint. You can even argue that in that context, a release smaller
than the sprint. So let’s change the term just for a moment. Let’s call it
longer term planning. And people might say ‘Well, longer than what?’ Well,
longer than a sprint. Even if you release every sprint, or even if you release
multiple times during the sprint, there’s still a benefit to looking out at a
horizon that’s larger than a single sprint. We might be using milestone
releases along the path to a bigger goal. And so release planning, is really
trying to plan to that large goal.

Okay, that presents certain issues. Here you are at on the
first day of the project – what if that longer goal is 6 months out? Or even
longer? Can you actually give any kind of accurate answer that early on? And the
answer is that you’re going to get asked the questions. And we all know what
the questions are. Questions like ‘When will you be done?’ or ‘How many of
those features do you think will be available 6 months or 9 months from now?’
And ‘What’s all this going to cost?’

Now, these seem like fair questions to ask. And for us,
trying to be in a position to answer them, we need to figure out what
realistically we can do. And the good news is we can do some things. And the
way we’ll address it is, much like I was suggesting earlier, we give range
answers. In release planning, the smart approach is always give a range answer
to questions. If they ask, ‘When will you be done?’ – stating a specific date
is likely going to be overly precise. On the first day of the project you
cannot be that precise, you don’t have good enough information. But I can
always be accurate by giving a range. You just have to give a sensible range.
If I tell you it’s going to take 4-7 sprints to get this done; that expresses
one level of uncertainty. If I said it’s going to take 4-29 sprints; that would
express a completely different level of uncertainty.

At a certain point, I know I can always be accurate, but it
could be ridiculous. Yeah, it’s going to take between now and 3 years from now
– yeah, but that’s not very helpful. So we try to give range answers that are
accurate, that are reasonably actionable by the people who hear them. They can
make a business decision – ‘Should I do this, should I not do it?’ So we have
to do some amount of upfront planning to be in a position to answer those
questions. Typically, at the release planning level, we try to work with
medium-sized stories. Not epics that tend to be too big, but use more portfolio
level planning, but with some people might call features or even themes so we
try to generate a first pass at those, input high level size estimates on them
and then based on a team’s history velocity, or a forecasted velocity, we try
to give a rough estimate. And we try to simplify the problem. If someone says
‘Well, my release is going to be 2 years out’, I don’t think that’s a
reasonable timeframe to be planning. Especially because there’s likely very
important increments along that path that we can plan first. Rule number one is always try to turn a big problem into a
small one in planning. And always give range answers. So I do think by
balancing upfront, predictive work, sort of adjusted time adaptive work, we can
do reasonable release planning. With a very important caveat. We update the
release plan every sprint. Release planning is not a one time at the very beginning
activity. Yes, I did do it early on because I probably got asked some questions
I had to address. But I update my release with every single sprint as I acquire
better knowledge. That’s how I tend to approach it.

Ronnie: Perfect answer. Our next question is also from
Essential Scrum which is in regards to idle work vs. idle workers. I’ve seen
this come up countless times and it can be very frustrating on me. I often see
management focused on idle workers. For example ‘Why is this person only at X
percentage of utilization and rather than a team mindset of why is there work being idle?’ Could you please take a few minutes and explain idle work vs.
idle workers for the audience?

Ken: I will. To me, this is a critical topic, and I cover it
in all of my classes because it lays a foundational principle that I need. The
way I try to explain it to folks is this way: the largest cost in software
product development is the people. Once we buy hardware and whatever software
people need to do their job, the real cost of any software organization is the
cost of the people that are hired, which is why budget almost always equals
headcount. Everybody is
interested in eliminating waste, but the issue of course, is that within
organizations there are multiple forms of waste. And these types of waste
typically trade off, meaning it’s usually impossible to simultaneously
eliminate all forms of waste. So what people tend to do is they go after the
waste they can see. And since we said the largest cost in software product
development is people, then a visible obvious form of waste would be underutilization
of people. Meaning, if I hire someone to do testing and I pay them 100% salary,
there’s an expectation that that person is going to test 100% of the time. And by the way, my management probably measures me on how
busy I keep that tester, so they assume that the tester reports to me. If I
hire that individual in, pay them 100% salary and assign them to a project, and
that project requires 60% of their time, if I were to stop there, it would give
the appearance of a 40% underutilization of my tester. And I’ll look bad to my
management because I’m paying this person 100% salary, but the individual’s
only working 60% of the time. Okay, that won’t do.

So to solve the problem, I’m going to do the obvious. I’m
probably going to assign that person to a second project, which will lead them
up 30%. Okay, I now have them at 90% utilization – but there’s still a 10%
underutilization – well, it worked so well for 2 projects, let’s try 3. Okay,
clever me. I’ve now eliminated idle tester waste. I’ve driven underutilization
of my tester to 0. They’re 100% utilized. So I have eliminated that form of
waste. The question, of course, is what just went the other way? Meaning, we
said sometimes waste trades off – as one goes down, the other goes up. Well,
here’s the problem. The idle workers weren’t waste that was causing the most
economic advantage. Here’s the problem: as we keep people that busy, chances
are they’re going to need to start blocking work. As an obvious example, I’ve
assigned that person to work on 3 separate teams. It’s very likely, at any
point in time, that person’s blocking two teams. They’re working on one of the
projects and the other two are waiting. That means, the work is now idle.

So what you end up seeing is this inventory that’s building
up all over product development. Inventory being blocked work sitting in
queues, waiting to get done. And the problem is that blocked work, that inventory, is causing huge economic damage. And people don’t focus on it because that’s an
invisible form of waste, hard to see in our inventory and product development
because typically, it’s bits out on the disk, code out on a server in best
cases. Whereas inventory in other cases tends to be more visible. So they go
after the visible ways which is idle workers and they ignore the kind of
invisible ways. The people are still 100% busy, so it
looks like the system is working at capacity. The problem is that if you
examine what happens in large companies, at scale, if you look at how work
flows across their organization, across the system, the collection of teams
they put together to get the job done, what you often find is up to 90% of the
time, the work is blocked.

Imagine you took a stopwatch out of your pocket when a
customer asks you to work on a feature and you agree to do it. If you click the
stopwatch at that point and time starts running, you don’t get to click the
stopwatch again until you’ve actually delivered the features to the customer.
And so, what I’m saying, from click to click on that stopwatch, in a lot of
organizations that I visit, up to 90% of the time or more the work isn’t
moving. And that’s causing severe economic damage and the reason I say that is
it’s injecting a cost of delay. The work could have been done faster and
delivered to customers faster and delivering work faster generates revenue
today; revenue today is worth more than revenue tomorrow because revenue today
generates money and money is a time battle. When you compare the cost of delay,
of idle work, against maybe a little bit of underutilization of the workers you
realize that you’re working on the wrong thing.

In organization, it’s all about the idle work, but that’s
exactly the opposite of what most companies do. Most organizations attempt to
optimize the utilization of their people, and by doing so, they inject a lot of
delay into how long it takes to get the work done and that delay has a real
cost. And they don’t quantify it, so they don’t really see the impact of that.
So you focus on the idle work, you don’t worry about the idle workers. You’re
trying to achieve what I call ‘fast, flexible flow’. To very quickly flow the
work across to your teams in a fast and flexible way. You subordinate other
decisions to that, which means ‘I don’t really care how idle or how occupied or
how utilized your workers are, but I do care about is how quickly you can pull
the work across your organization in a high quality way.’ Though in a sense, most organizations are focused in the
wrong place. They’re watching the workers when they should be watching the
work. That’s the concept here.

Ronnie: Well, unfortunately I’ve seen that happen many
times, and especially with the example regarding QA. It is such a common
practice to do just what you described – when one person is placed on multiple
teams to boost utilization numbers. That practice actually injects more project
risk because if the person is working on team A, B and C – if team A hits a
major bump in the road, there’s no margin to absorb it. Work simply becomes
blocked in the other teams, it can really cause havoc. I love your answer which
forces the organization to ask better questions.

Ken: It’s a good example. I’ll leave you with one analogy
for the listeners. And I know it’s the extreme analogy, so don’t get upset
because it’s just extreme, but it’ll illustrate the point. Isn’t it true we pay
firefighters to be idle most of the time? If you think about it, you really
don’t want to keep your firefighters 100% utilized, because if you do, then the
next fire that breaks out, very likely structures will burn and people might
die. And as citizens, we deem that to be unacceptable. So we actually pay
firefighters to be idle most of the time. Why? Because when you need them, you
need them. And you need them now and any cost of delay associated with that
work is unacceptable because the ramifications are too great. But I’m not
saying you should pay people to sit around and be idle on your software
project. But I’m suggesting the fallout – if there’s a certain skillset that
when you need it, you need it; and any delay in it becoming available blocks
your work and there is significant cost of delay in the blockage, you might
want to seriously rethink the strategy of trying to keep everybody at 100%.

Ronnie: Very true, I love that example. There are tons of
questions that I would love to ask you, but I definitely want to respect your
time. With that said, my final question is in reference to Validated Learning,
which is mentioned in your book, Essential Scrum. I’m a huge fan of Validated
Learning and the Lean Startup by Eric Ries, which I highly recommend. We may
have some audience members that are not yet familiar with the concept and how
it might apply to their team. Can you please take a few minutes and explain to
our listeners Validated Learning?

Ken: Sure. Lean Startup is a very good book and does
leverage core Agile principles and a lot of the terminology, which is why I’ve used it
in the Essential Scrum book, because it very nicely captures a category of
principles that are fundamental to Agile. And the way to think about Validated
Learning is you should validate important assumptions fast. It’s dangerous to
make an important assumption and have it live long in an invalidated state.
Because if I make an assumption and I don’t go out and get it validated, I
start building things or making other decisions on top of that assumption and if
a long time later I finally validate or attempt to validate the original
assumption, what if I determine the original assumption was wrong?

Now, I’m likely sitting on a problem that is much, much
larger than it needs to be. So most people are familiar with the techniques of
performing validated learning, prototype, concept study, experiment – meaning
that validated learning is the act of buying information when you’re
presented with a high degree of uncertainty, and therefore you made an
assumption, if you were certain about something – you wouldn’t have to make an
assumption, you’d just make the correct decision. But in the presence of a high
degree of uncertainty, you have to make these assumptions and then what you
have to do is go buy knowledge, buy information to validate your learning,
meaning to be able to confirm or refute the hypothesis that you stated, the assumption
that you made is correct or it isn’t.

You just have to do that fast. So, in Agile, if you think
about a learning block – you make an assumption, then we build something, then
we get feedback on what we built, then we inspect and adapt, the goal is to go
through that loop very very quickly. So in Agile the third part of this
Validate Learning is that you have to organize the flow of your work to get
fast feedback. In a sense, you say ‘What is the next most important thing I can
learn?’ and then go learn it. And then validate your learning. And if you learn
that you’re going the wrong way, take what you learn, plant your foot and alter
your direction. Take the learning that you have and maybe go to a better place
based on that.

So Validated Learning has two superior economic
characteristics. One – it prunes a bad path quickly. If you’re going down the
wrong path, which you don’t want to do, is keep running down that path very
fast. You’d like to determine you’re on the wrong path quicker so that you can
then pivot over to a new path. That’s economically valuable. The second
economic characteristic – it helps your exploit an emergent opportunity faster.
What you don’t want to do is learn late in a project: ‘Wow – there’s a much
better way we could’ve done this’. When it’s likely to do anything about it in
this release and maybe in the future. Maybe we’re so far down committed on the
path we’re on that even though we all now agree there’s a much better way of
doing it, we actually can’t exploit it. By validating your learning sooner,
you’re able to them exploit those opportunities sooner and end up in a much
better place.

So this is a critical concept. It applies in startup
companies, it applies in well-established companies; they’re building the next
generation product that’s been there for 10 years. You have to validate your
learning, validate the important assumptions fast and you organize the flow of
your work to get that fast effect.

Ronnie: Thank you so much, Ken, for being such a great guest
on our show. I’d love to give the listeners an opportunity to learn more about
your services and how they may be able to contact you. Can you please take a
few minutes to expound upon that?

Ken: I appreciate that. I have a website, it’s
innolution.com and on there I have a blog that I talk about a lot of these
topics and I also have a lot of my presentations that I give at conferences so,
if anybody’s interested feel free – you can go down and look at presentations
on portfolio management, on what I call Essential Scrum and a variety of other
topics, the most recent being risk management. So by all means, feel free to
have a look at that. Mike Cohen and I also have developed a tool called
Comparative Agility. It’s a free survey that you can take which at the end tells
you how Agile your team is by comparing you with close to 13,000 other people
who have already taken the survey – so there’s a number of resources out there.
Also, I do offer training and coaching, so if your company might have an
interest, feel free to contact me. All my information is on my website.

Ronnie: Thank you so much for joining us today Ken and for
your great insight and advice.

Ken: I appreciate you hosting me and I wish everybody the
best of luck with their application of Agile!

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!