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!