Highlights from a recent All Things Agile podcast
Back in January, Ronnie Andrews Jr., host of the popular podcast All Things Agile, interviewed me about key concepts from my Essential Scrum book. Our conversation touched on many interesting topics, including the difference between a group and a team, the hidden issues Scrum can surface, adaptive vs. predictive planning and how it applies to release planning, idle work vs. idle workers, and more!
A few of the highlights are listed below, but I encourage you to read the entire transcript or listen to the podcast.
Team and Groups
QUESTION: What is your insight or your advice on how relationships affect agile teams?
ANSWER: To me, the unit of capacity in agile is the team. ... How they interact with each other, how they perform is of outmost importance. ... [a] group, simply being a bunch of people that I threw together with a common label. ... [Whereas] A team is a group that’s gone through the ... stages: forming, storming, norming and performing. If you can, make a real investment to turn a group into a team.
... 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 the best [they will achieve] is mediocrity.
HIDDEN ISSUES
QUESTION: 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?
ANSWER: ...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 the core agile principles and hopefully they can align their behavior with how we’re going to do agility downstream. ... If they don’t, we will have a serious disconnect. ... 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. ...
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—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.”
ADAPTIVE vs PREDICTIVE PLANNING
QUESTION: Could you please take a moment to explain to our listeners adaptive vs. predictive and perhaps how it might apply to release planning?
ANSWER: ...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 adaptive and you 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.
IDLE WORK VS IDLE WORKERS
QUESTION: Could you please take a few minutes and explain idle work vs. idle workers for the audience?
ANSWER: ...The largest cost in software product development is the people ... 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. ...
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.
...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. ... 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.
CLOSING
The full transcript of the interview contains many more examples and more in-depth information than I've highlighted in this blog post. I hope you will take the time to read it or listen to it. I want to once again thank Ronnie Andrews, Jr. at All Things Agile for making this podcast available.