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 destinationfor tips and interviews with the leaders in the world of Agile. Don’t forget tosubscribe 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’mvery excited to announce that Ken Rubin is our guest today on the show. Ken is anoted author of Essential Scrum as well as being a public speaker and Agile instructor. Before we begin, a quick reminder that this podcast is forinformational purposes only and we accept no legal liability. So let’s getstarted! 
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 quickintroduction, but can you please take a few minutes and explain a little bitmore about yourself, both personally and professionally? We really want to geta chance to know you.

Ken: Sure! So my background is software engineering. Mydegrees are all in computer science and I’ve had a typical path through mostsoftware companies. I’ve been a developer, project manager, VP of Engineeringat a number of companies both large and small. I’ve done 10 startup companiesin my career, and I’ve taken two of those public on the NASDAQ. I did my 2 yearstint with IBM in the mid-1990s. I’ve helped companies and I worked with 130people; we ran around North America building large distributed object systemsand 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 atXerox PARC, and I worked with a startup company that was a spin-off of XeroxPARC 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 Coloradocalled Genomica. It was a 90 person engineering team, and they let the VP ofengineering go. I ended up inheriting the engineering team which wasn’tfunctioning all that well and we transitioned everybody over to Scrum. And thatended 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 trainingclasses and Kanban training classes or doing coaching. And, I hope that in our discussion today I can go over a number ofexamples that I had the benefit of seeing a lot of different companies andwhat’s working and what isn’t working.

Ronnie: Thank you for the introduction Ken. I’m reallylooking forward to the insights you can provide us based on your considerableexperience. The first question I’d liked to ask you, regarding your bookEssential Scrum, is in regards to the dedication and introduction. It really gotme thinking about the importance of relationships and software. I also startedthinking 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 ofcapacity in Agile is the team. Even the Agile Manifesto calls that out –individuals and interactions over processes and tools. It really is about theteam. So how they interact with each other, how they perform is of outmostimportance. The relationships among the members of the teams is critical. Ifyou’re going to have self-organizing teams, they have to have trust in oneanother. That’s one of the characteristics that, for me, distinguishes a groupfrom a team. Group, simply being a bunch of people that I threw together with acommon label. And honestly, the only thing they have in common are the T-shirtsthey 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 ifyou can make a real investment to turn a group into a team, first, they had tofigure out these soft skills issues: how to work well together? Otherwise, theywould never become a high performing team, and they would constantly be at oddswith one another. So one of management’s responsibility is to help put theright people on the team, but once they’re there, it’s the soft skills thathelp 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 – Butexercise. And the intent behind that – it’s actually an exercise that borrowedfrom improvisational comedy training and the idea is to try and help teamsunderstand how to work well together, how to form those relationships, how totake one person’s idea, build on top of it and not be in a Yes – But stylepassive-aggressive cutting things down: ‘Yeah, I heard what you said; it seemslike a good idea but let me now tell you why it sucks.’ That’s not a foundationfor 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 ofcapacity 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 andhow people fill in the gaps in communication and that with a high trustenvironment, the team is able to move more quickly.

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

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

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

Immediately this lady in the back of the room raised herhand. She said ‘This won’t work here’. I said ‘Why not? What part of that?’ Shesaid ‘I manage the QA team’. She goes ‘You just told me that I should assign mypeople 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 everyScrum we should have zero known defects and the reason that won’t work isbecause we compensate our testers based on the number of defects they find.’ Soshe’s saying basically that’s not very motivating if you’re one of my testersbecause you’re going to make less money if you do that.

Now, what she says next is the tell-tell sign for me as towhether a company has a hope of being successful with Agile. Here’s what shedidn’t say. She did not say ‘Well, in that case, I’m just not going to assignmy people out on to the Scrum teams. I’m not going to do that, I’ll just keepthem together’. Meaning, I see the impediment. Agile has shone a bright lighton 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 thatimpediment doesn’t exist. Now, companies that are bolted to that approach willprobably fail and fail quickly with Agile.

Instead, what she actually said was ‘I think I’m going tohave a conversation with the VP of HR and the VP of Engineering so that we candiscuss 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 currentcompensation system is at odds with them being successful with Agile. Andrather 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 theexecutives trained or understanding these key points, you’re likely to have aproblem. By the way, her next comment – I mentioned other things; I don’t pullpeople off of Scrum teams to work on your pet projects. Another person raisedher 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 toentertain it. So my approach to trying to address the problem is the leadershiprequires the proper kind of training and coaching principally on core Agileprinciples. That’s where I try to focus with them. So if I can get 60-90minutes with them over lunchtime, that’s a good start. Not as good as havingthem in a multi-day class, but they’re not willing to make that commitmentusually. So get 60-90 minutes, help them to understand that core Agileprinciples and hopefully they can align their behavior with how we’re going todo agility downstream, cause if they don’t, we will have a serious disconnectand companies with a better experience at that will likely fail in theirattempt to use Agile, because of that disconnect. It’s a critical question andeither they’re going to understand what we’re trying to do and embrace it, orthey’re not and these companies are going to have a hard time.

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

Ken: I find it beneficial when people like that, people withhigh level titles actually attend the classes. Part of the benefit is not justtheir 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 rangeanswers to questions as a way of communicating uncertainty. Range answers toplanning questions, like ‘When will you be done?’ Give a range answer: betweenX number of sprints and Y number of sprints. And in this one class, an engineerstood up and said ‘Yeah, but my management is never going to accept a rangeanswer’. And there’s only one person in this class – it was a large class – andthe only person in this class wearing a suit was the general manager of thewhole division. He then stood up, turned around and said ‘Well, I’m the guyasking the questions and I’m telling you I’m willing to accept a range answerand I’d like to talk to you about how we can keep range answers within onecalendar 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 askingquestions and he just said he’s willing to do it and I guess we can actuallymove on here under the assumption we can provide range answers’. So getting thesenior execs in a classroom, I think it’s a high priority – but it doesn’thappen nearly as frequently as it should. Occasionally, I’ll get the luxury ofhaving a one day – and rarely, but it does happen – a two day class withleadership. I would say one of every four classes I do, we have that hour to 90minutes 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 isadaptive vs. predictive, which is referenced in your book. One of the examplesthat came to my mind was release planning. Could you please take a moment toexplain to our listeners adaptive vs. predictive and perhaps how it might applyto release planning?

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

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

So let’s buy into the fact that it’s a misperception tobelieve that Agile is anti-upfront planning. Because, of course, that’s simplynot true. Agile is anti-waste. And if you do too much planning upfront, thenyou’re going to inject too much unnecessary planning inventory into the systemthat’ll have to be reworked or thrown out when something goes wrong. So theprinciple here is upfront planning should be helpful, just not excessive. Inthe 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 atthat, if you define what it means, in today’s world release planning isbecoming a harder term to use because in the past, a release typically wasperformed after multiple sprints of work were completed. So in that scenario, arelease was larger than a sprint. But what about the teams that release everysprint?

You can argue ‘Well, isn’t sprint planning the same as releaseplanning?’ Or what about teams that do continuous delivery orcontinuous deployment. They can release every feature as it become availableduring this sprint. You can even argue that in that context, a release smallerthan the sprint. So let’s change the term just for a moment. Let’s call itlonger 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 releasemultiple times during the sprint, there’s still a benefit to looking out at ahorizon that’s larger than a single sprint. We might be using milestonereleases along the path to a bigger goal. And so release planning, is reallytrying to plan to that large goal.

Okay, that presents certain issues. Here you are at on thefirst day of the project – what if that longer goal is 6 months out? Or evenlonger? Can you actually give any kind of accurate answer that early on? And theanswer is that you’re going to get asked the questions. And we all know whatthe questions are. Questions like ‘When will you be done?’ or ‘How many ofthose 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 whatrealistically we can do. And the good news is we can do some things. And theway we’ll address it is, much like I was suggesting earlier, we give rangeanswers. In release planning, the smart approach is always give a range answerto questions. If they ask, ‘When will you be done?’ – stating a specific dateis likely going to be overly precise. On the first day of the project youcannot be that precise, you don’t have good enough information. But I canalways 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 expressesone level of uncertainty. If I said it’s going to take 4-29 sprints; that wouldexpress a completely different level of uncertainty.

At a certain point, I know I can always be accurate, but itcould 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 areaccurate, that are reasonably actionable by the people who hear them. They canmake a business decision – ‘Should I do this, should I not do it?’ So we haveto do some amount of upfront planning to be in a position to answer thosequestions. Typically, at the release planning level, we try to work withmedium-sized stories. Not epics that tend to be too big, but use more portfoliolevel planning, but with some people might call features or even themes so wetry to generate a first pass at those, input high level size estimates on themand then based on a team’s history velocity, or a forecasted velocity, we tryto 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 areasonable timeframe to be planning. Especially because there’s likely veryimportant increments along that path that we can plan first. Rule number one is always try to turn a big problem into asmall one in planning. And always give range answers. So I do think bybalancing upfront, predictive work, sort of adjusted time adaptive work, we cando reasonable release planning. With a very important caveat. We update therelease plan every sprint. Release planning is not a one time at the very beginningactivity. Yes, I did do it early on because I probably got asked some questionsI had to address. But I update my release with every single sprint as I acquirebetter knowledge. That’s how I tend to approach it.

Ronnie: Perfect answer. Our next question is also fromEssential Scrum which is in regards to idle work vs. idle workers. I’ve seenthis come up countless times and it can be very frustrating on me. I often seemanagement focused on idle workers. For example ‘Why is this person only at Xpercentage 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 itin all of my classes because it lays a foundational principle that I need. Theway I try to explain it to folks is this way: the largest cost in softwareproduct development is the people. Once we buy hardware and whatever softwarepeople need to do their job, the real cost of any software organization is thecost of the people that are hired, which is why budget almost always equalsheadcount. Everybody isinterested in eliminating waste, but the issue of course, is that withinorganizations there are multiple forms of waste. And these types of wastetypically trade off, meaning it’s usually impossible to simultaneouslyeliminate all forms of waste. So what people tend to do is they go after thewaste they can see. And since we said the largest cost in software productdevelopment is people, then a visible obvious form of waste would be underutilizationof 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 howbusy I keep that tester, so they assume that the tester reports to me. If Ihire that individual in, pay them 100% salary and assign them to a project, andthat project requires 60% of their time, if I were to stop there, it would givethe appearance of a 40% underutilization of my tester. And I’ll look bad to mymanagement because I’m paying this person 100% salary, but the individual’sonly working 60% of the time. Okay, that won’t do.

So to solve the problem, I’m going to do the obvious. I’mprobably going to assign that person to a second project, which will lead themup 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 underutilizationof my tester to 0. They’re 100% utilized. So I have eliminated that form ofwaste. The question, of course, is what just went the other way? Meaning, wesaid 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 mosteconomic advantage. Here’s the problem: as we keep people that busy, chancesare they’re going to need to start blocking work. As an obvious example, I’veassigned that person to work on 3 separate teams. It’s very likely, at anypoint in time, that person’s blocking two teams. They’re working on one of theprojects and the other two are waiting. That means, the work is now idle.

So what you end up seeing is this inventory that’s buildingup all over product development. Inventory being blocked work sitting inqueues, 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 aninvisible form of waste, hard to see in our inventory and product developmentbecause typically, it’s bits out on the disk, code out on a server in bestcases. Whereas inventory in other cases tends to be more visible. So they goafter the visible ways which is idle workers and they ignore the kind ofinvisible ways. The people are still 100% busy, so itlooks like the system is working at capacity. The problem is that if youexamine what happens in large companies, at scale, if you look at how workflows across their organization, across the system, the collection of teamsthey put together to get the job done, what you often find is up to 90% of thetime, the work is blocked.

Imagine you took a stopwatch out of your pocket when acustomer asks you to work on a feature and you agree to do it. If you click thestopwatch at that point and time starts running, you don’t get to click thestopwatch 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 oforganizations that I visit, up to 90% of the time or more the work isn’tmoving. And that’s causing severe economic damage and the reason I say that isit’s injecting a cost of delay. The work could have been done faster anddelivered to customers faster and delivering work faster generates revenuetoday; revenue today is worth more than revenue tomorrow because revenue todaygenerates 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 yourealize that you’re working on the wrong thing.

In organization, it’s all about the idle work, but that’sexactly the opposite of what most companies do. Most organizations attempt tooptimize the utilization of their people, and by doing so, they inject a lot ofdelay into how long it takes to get the work done and that delay has a realcost. 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’retrying to achieve what I call ‘fast, flexible flow’. To very quickly flow thework across to your teams in a fast and flexible way. You subordinate otherdecisions to that, which means ‘I don’t really care how idle or how occupied orhow utilized your workers are, but I do care about is how quickly you can pullthe work across your organization in a high quality way.’ Though in a sense, most organizations are focused in thewrong place. They’re watching the workers when they should be watching thework. That’s the concept here.

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

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

Ronnie: Very true, I love that example. There are tons ofquestions that I would love to ask you, but I definitely want to respect yourtime. 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 ValidatedLearning and the Lean Startup by Eric Ries, which I highly recommend. We mayhave some audience members that are not yet familiar with the concept and howit might apply to their team. Can you please take a few minutes and explain toour listeners Validated Learning?

Ken: Sure. Lean Startup is a very good book and doesleverage core Agile principles and a lot of the terminology, which is why I’ve used itin the Essential Scrum book, because it very nicely captures a category ofprinciples that are fundamental to Agile. And the way to think about ValidatedLearning is you should validate important assumptions fast. It’s dangerous tomake 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, Istart building things or making other decisions on top of that assumption and ifa long time later I finally validate or attempt to validate the originalassumption, what if I determine the original assumption was wrong?

Now, I’m likely sitting on a problem that is much, muchlarger than it needs to be. So most people are familiar with the techniques ofperforming validated learning, prototype, concept study, experiment – meaningthat validated learning is the act of buying information when you’represented with a high degree of uncertainty, and therefore you made anassumption, if you were certain about something – you wouldn’t have to make anassumption, you’d just make the correct decision. But in the presence of a highdegree of uncertainty, you have to make these assumptions and then what youhave 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 assumptionthat you made is correct or it isn’t.

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

So Validated Learning has two superior economiccharacteristics. One – it prunes a bad path quickly. If you’re going down thewrong path, which you don’t want to do, is keep running down that path veryfast. You’d like to determine you’re on the wrong path quicker so that you canthen pivot over to a new path. That’s economically valuable. The secondeconomic 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 muchbetter way we could’ve done this’. When it’s likely to do anything about it inthis release and maybe in the future. Maybe we’re so far down committed on thepath we’re on that even though we all now agree there’s a much better way ofdoing 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 muchbetter place.

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

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

Ken: I appreciate that. I have a website, it’sinnolution.com and on there I have a blog that I talk about a lot of thesetopics 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 presentationson portfolio management, on what I call Essential Scrum and a variety of othertopics, the most recent being risk management. So by all means, feel free tohave a look at that. Mike Cohen and I also have developed a tool calledComparative Agility. It’s a free survey that you can take which at the end tellsyou how Agile your team is by comparing you with close to 13,000 other peoplewho 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 aninterest, feel free to contact me. All my information is on my website.

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

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

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