This is a transcript of episode 254 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.

Dominica Degrandis is an expert on flow and helping companies get the benefits of using flow metrics to make systemic improvements. What does she find as the biggest obstacle to success? A proper investment in change. In this conversation Jeffrey and Dominica talk about the importance of a daily change budget, time you’d expect people to be working in the new way, with some advice for both leaders and practitioners. Recorded live at DevOps Enterprise Summit 2022 in Las Vegas.

Show links:

Listen to the episode on SoundCloud or Apple Podcasts.


Listen to this section at 00:11

Jeffrey: Welcome back to Troubleshooting Agile. This is Jeff Frederick and I am once again recording live at DevOps Enterprise Summit 2022. I’m here today with Dominica Degrandis. Welcome back, Dominica.

Dominica: Thank you, Jeff. Glad to be here.

Jeffrey: So Dominica is an expert on flow. We covered that last time we got to sit down with her, which was the same conference but in 2019. Recently you’ve had the second edition of your book, Making Work Visible come out. How did you end up becoming such an expert of flow? What got you into that as an area?

Dominica: My background was as a build engineer doing software configuration management for many years, which led in to merging and source code control and doing a lot of releases and configuration of environments. I think it was in 2005 or 2006, we started doing Kanban for operations: measuring wait times versus work time and getting visibility on it, and that really changed things because we started doing operational reviews where we had a team lead present their cumulative flow diagrams to their peers, their bosses, and business partners were invited to those sessions too. So that was really a pivotal time around how to describe your team’s productivity in terms of flow.

Jeffrey: That’s great. So you took a different path from mainstream Agile, which I think it was about 2001 that the Poppendieck’s book on Lean software development was written—I remember that because it was about the same year as the Agile Manifesto—but where mainstream Agile went more extreme programming, transitioning into Scrum, it sounds like you were an early on the Kanban phase.

Dominica: Yeah, we never really did do Scrum. We just went right into Kanban, and Don Reinertsen came to visit us on The Principles of Product Development Flow in maybe 2006. He was interested in our work because we were, I think, the first organization in the US to be doing Kanban.

Jeffrey: Wow. Which organization was this?

Dominica: This was Corbis, Bill Gates’s other company, in Seattle.

Jeffrey: Interesting. Yeah I think Kanban got more of a start in the UK.

Dominica: Yeah. So I put together the first Kanban for DevOps curriculum in the US for David J. Anderson, and he sent me off to Europe. So first I went to Sweden, Stockholm and I met the Spotify folks. Then I travel to northern England and so I met these sort of pioneers in the Kanban movement who were also interested in doing that for operations, not just development. So one thing led to another, and there’s such a huge community over there, and then after I got the workshop going, I think it was 2011 when I launched Kanban for DevOps in the US. The first class was going to be in California and Gene Kim attended that along with John Willis, Damon Edwards, and Andrew Clay Shafer. That evening I gave a talk in Mountain View to a group of 300 to 400 people, and that’s where I met Adrian Cockcroft, and just a whole bunch of these luminaries. It was a really exciting time, I was just in the right place at the right time.

Jeffrey: That’s great. It sounds like it wasn’t an accident. You’d had several years of experience at that point.

Dominica: That’s true.

Jeffrey: You had been one of the most experienced people in the US on actually applying this.

Dominica: I guess so, yeah.

A Recent Furor

Listen to this section at 04:41

Jeffrey: Yeah. It’s interesting. The topic of Kanban is a whole interesting other discussion. Squirrel and I in our recent episodes have been talking about the value of estimation or not. For people who listen to the podcast I know personally it’s been one of the most contentious topics, but even the whole the two episodes about it Squirrel and I were arguing about the value estimations are not, and he was taking more of an Elephant Carpaccio/ship something every day/you don’t need to estimate if your flow is fast enough, your flow is enough, then the value of estimation is low.

Dominica: Well, if you have the data that shows the probability or the likelihood of delivering within so many days based on historical data, then you don’t have to guess.

Jeffrey: Right. We could easily be derailed into that because I actually was taking the pro-estimate side. Literally as I was walking to the room for this, I had someone respond and tell me, estimates should be underestimating 50% of the time. So if your estimates are accurate, in a sense, they’re consistent, then you should be missing them as often as you’re making them, for maximum learning. That maybe is a different podcast. But we were talking before we got started here, not about Kanban, but you said one of the really exciting topics for you is something you’ve changed in your second edition of your book: more emphasis on change. Tell me about this, what’s made change so front and center for you right now?

Dominica: It’s so hard to change. There’s a lot of resistance to new ways of working. I work with a lot of really large organizations to help them understand flow metrics, use flow metrics.

Jeffrey: Maybe explain who you work for, why you’d be talking to a large organization.

Dominica: I work for Tasktop, and I work a lot with a product called Tasktop Viz this which is part of a framework-

Jeffrey: Making your flow metrics visible.

Dominica: Yeah. So we were looking at the standard flow metrics of WIP and throughput and flow time and flow efficiency. When people who aren’t familiar with that see that for the first time, which is what happens with a lot of customers who are under some major transformation or initiative, “Let’s do flow metrics.” They’re usually curious about what flow metrics are, but then they wonder why. How does this apply to them? There’s a lot of learning and understanding the higher level. Flow metrics are really not intended to replace door metrics or team metrics that are useful at the team level, but we’re trying to bring visibility to the higher level, the organization or the product value stream level so we can see end-to-end how work is flowing and how we measure the performance of that.

Jeffrey: Right. For me, as someone who’s into system engineering and the system view, hearing “end-to-end” I’m going to light up, “Exactly!” If we don’t have visibility end-to-end, we can’t be making global optimizations.

Dominica: Exactly. That’s the thing, teams are still measured in their team. “Tell me how you’re going to measure me and we’ll tell you how we’re going to behave. We’re going to optimize locally because that’s how we get measured.” But when you talk to our business partners, they want to make our customers happy! So that’s why we want to start the clock as soon as we’ve decided that we’re going to do something, and not end the clock when we’re dev-done, end the clock when the customer gets their thing and it’s available for them. We’ve looked at thousands of different value streams that have been measured, and it turns out that only about 2-12% of the total flow time of delivery of value to customers is within development: build, test, QA.

Jeffrey: That’s right. Any time I’ve worked with the development team and got them functioning well, what they soon learned is the bottleneck is actually upstream.

Dominica: It’s not them.

Jeffrey: it’s not development! People say, “We’re slow getting stuff to market, we need to speed up development.” They’re almost always looking in the wrong place, but they have no visibility into it, they have no system view, and so then they don’t even realize their mistakes.

It Starts at Misdiagnosis

Listen to this section at 09:43

Dominica: Yeah. I’m doing this learning sprint here at the conference and I’m teaching people about designing product structures end-to-end so we can get the visibility on whether it’s external product or internal product or platform product to help people understand that, say, if the payment product value stream is running really smoothly but it’s dependent on a DevOps workflow that isn’t automated or has people there are just overloaded and don’t have capacity to do all the things needed by the payment system, that it does no good to optimize the payments system, even if that’s where they want to go.

Jeffrey: But see, here we are making the same mistake, right? Because you and I both understand this, we’re both bought in, and we can talk about all the benefits and get really excited. But when you go into a client where maybe they’ve purchased it, they’re looking to adopt it, they’re part of some transformation, you don’t get that kind of excitement with the people who actually need to adopt it.

Dominica: Yeah, there’s resistance.

Jeffrey: This speaks to me, in 2005 when you’re talking about doing Kanban I was a software evangelist for a company called Agitar that was selling developer testing tools to help them unit test. I was living that life at the time: “We have this toolset that could really help with your Java code, help really speed your time to development, developing your unit tests, have much better solid tests to code!” I would come in and find that people had other things to do. “I’m too busy.”

Dominica: They’re back-to-back meetings all day long. Even organizations who say they have WIP limits in place, if you look at their calendars, it’s back to back-to-back meetings, and then there’s all the unplanned work.

Jeffrey: I know that one of the first things Squirrel does when he coaches people is he says, “Let’s look at your calendar, we’re going to cancel some meetings. You’re going to decline. You’re going to use the button that people rarely use,-“

Dominica: The “no” button.

Jeffrey: The “no” button! People aren’t aware they can deline meetings.

Dominica: I think people are going to continue doing what brought them value previously. So if they learn something really well and they’re really good at it and it’s what got them where they are today, they want to keep doing that.

Jeffrey: “Why wouldn’t I do what’s worked before?”

Dominica: To make a significant change is scary. So what leaders do comes down to two sides, one is using fear. Maybe not intentionally. I’ll talk to leaders and they say, “Oh, no, our teams are happy. They have the autonomy to do whatever they want.” And then I meet with the teams and they’re like, “We don’t have permission to do that.” So people who are willing to go out on a limb and do things without asking permission because maybe it’s the right thing to do, if they get squashed or they don’t get the support they need, they stop. They either stop doing that or they leave.

Jeffrey: And everyone else learns the lesson that it wasn’t safe to do something different. They learn compliance.

Dominica: That’s combined with the rate of change happening faster and faster and faster, and needing to do more and more and more.

Jeffrey: But there’s a different kind of change. This is the irony, right? There’s more demand to change the software, but that makes it harder to change the process. It makes it harder to change the system, because people don’t have the slack to change that.

But Surely Change is Free

Listen to this section at 13:47

Dominica: And because there’s very little investment in horizontal capacity, where teams who are learning have documented their new way of working and there’s people who have time and capacity allocated to ensure that that communication bubbles up to some central library and that it’s read from. I’m was just talking with Amy Bechdel who was with Capital One and then AWS and now off to something new and great, she was talking about how at AWS they actually take time to read. They have sessions set up for people to read their lessons learned and their documentation. Similarly what we at try to do is ensure that this review and learning is incorporated into people’s daily work. I think that’s the key missing piece, sometimes I’ll meet with customers once a week and they haven’t done anything the other four days out of the week.

Jeffrey: That’s right.

Dominica: When you’re doing something new or learning something new, unless it’s part of your daily practice, it’s too easy to forget that.

Jeffrey: That’s right. I met with one of the co-founders at Tim, where I was working when I worked on the book Agile Conversations, and we were rolling out training there about conversations in order to help have more of a learning culture, and to have higher psychological safety. He had been reading something to the effect of, you need to do a daily practice, because if you just do it once a week, then you’re practicing the old habits four days a week. That’s not going to work. So making that the new process, with the new behaviors something you do every day is really key. In my the coaching, clients go through a conversational dojo exercise which takes 15 to 30 minutes to do. I tell them, “You’ve got to do it daily. If you say you want to be better, this is what it takes. If you complain you’re not getting stronger but only go to the gym once a week, or once a month…”

Dominica: That doesn’t cut it. I remember Jean Kim’s guidance for me when I was writing the first edition of Making Work Visible. “Dominika, two CPs per day”. I asked “What’s a CP?” That’s a crappy page. Write two pages a day. Then I actually heard that in a really old YouTube from Tim Ferriss.

Jeffrey: I think he may have got it from Anne Lamont. She wrote a book on writing called Bird by Bird. I hope I have this right, her phrase was “SFD,” “shitty first draft.”

Dominica: That’s the hardest one.

Jeffrey: But it’s the practice and discipline of doing it. And it’s hard because you’re bad. I think this is the tension for people who are under a lot of pressure that need to be putting all of their energy into performing. They can’t take time to learn because, if you know the steer change model, you get this-

Dominica: J-curve.

Jeffrey: Exactly! Your output will drop. My background’s in physics so I look at this as conservation of energy. “I can either put my energy into production, or into learning, or some combination.”

Dominica: Isaac Newton says so.

Jeffrey: Exactly! So if I’m going to put energy into learning, I have to put less into production. That’s just what has to happen. Otherwise I’m not learning. And that’s a really hard for people to engage with.

Dominica: That’s where we have this metric called flow distribution in viz where you’re looking at your work item type. Your features, and defects, and risks, security vulnerabilities and debt. Debt is not just technical debt, but debt is learning or experimentation or cross training. So we’re looking at how much capacity of the team is allocated for learning, and if there’s an intent to have a learning organization, then let’s have a strategy.

Jeffrey: What’s your budget for learning?

Dominica: Yes!

Jeffrey: And are you actually spending.

Dominica: How much are you going to invest in learning and allocate capacity? If you say that you’re going to invest 30% into learning, but then you look at the work that was actually released and it’s feature, feature, feature, feature, and no learning? There you go.

Jeffrey: So to sum up then, if you are a leader who is trying to help get people to change, it sounds like you have a pretty clear direction, which is give people a learning budget and make sure they’re spending it.

Dominica: Yeah.

Jeffrey: If you’re the individual who’s trying to be there, any tips for them that you’ve found?

Dominica: Well, I think for leaders there cannot be an expectation that they can go to one workshop and be done with it if it is not incorporated into their daily practice. For practitioners trying to learn something new, go out on a limb and block off time on your calendar—we call it flow time—for deep thinking where you’re not going to be interrupted. Otherwise, when are you going to do that? At midnight, or Sunday afternoon?

Jeffrey: That’s great. I didn’t know you called it flow time, but it turns out that’s exactly what I call it for myself, when I want time where I can get into the flow of what I’m doing and improve, away from the daily back-to-back meetings that have become so common in the remote working world.

Dominica: Excellent.

Jeffrey: Well thank you very much Dominica, for people who have questions for you, what’s the best way for them to get ahold of you?

Dominica: Probably on LinkedIn or my website.

Jeffrey: We’ll put links to both of those in the show. Thank you Dominica.

Dominica: Thank you, Jeff.