In this episode, Justyna and Paul talk with Dominica DeGrandis, author of Making Work Visible.
In this episode, Justyna and Paul talk with Dominica DeGrandis, author of Making Work Visible.
Welcome to the Agile Book Club. Here are your hosts, Justina and Paul.
Speaker 2:Hello. Huh? Is it me that am I making this noise or it's you? Huh? Okay. Hello? Hi Paul. Can you hear me okay? No. Can you hear me? Hello? Hello? Hmm. Okay. I think that my headphones were making weird noise, but I took them away. Yeah.
Speaker 3:Okay. So are you recording on your, your zoom device?
Speaker 2:Yes, yes, yes, yes, yes. I already clicked record and yeah, everything is okay. I hope so. Hello? Hello Paul.
Speaker 3:So this is the first time we've actually done a podcast where we weren't in the same room together. Okay. I've got to say I miss you. But the beaches in Portugal are pretty amazing.
Speaker 2:I know, I saw pictures. You can't have everything. You can't have everything yeah. So, how are you? I'm doing good. But the weather in Krakow is, I think, similar than in Portugal, but worse because no water. So it's like disaster. Yesterday when I was riding on my bicycle, I was feeling like someone is keeping hairdryer on, you know, the highest level and just blow in my face. That's the feeling that we are getting right now in Krakow. So please enjoy your time in Portugal because when you will be back in my be still the same.
Speaker 3:Oh No, no, no. It's lovely. Lovely, lovely. Here. It's, it's like 22 to 24 degrees and blue skies and a constant breeze, so it's never hot and it's never cold and it's so peaceful. Oh my goodness gracious. I could just stay here forever if it would only stay June forever.
Speaker 2:Oh, okay. Did you try to record podcast on the beach? Actually,
Speaker 3:no. I did not try to record a podcast cast on the beach because the waves were too loud. Okay. Those damned waves. Somebody should do something about that. Oh yeah. You should be able to record a podcast on the beach, but no, against the rules apparently. Yeah. So you can't everything. But you know, we can have, and it's something I'm really excited about today. We're going to be interviewing Dominica de Grande is the author of making work visible. Yeah. Which is awesome. Yeah. You know, I met her a few years ago and eight years ago along. Okay. I'm almost 50. And so when I say a few years ago, I mean a decade, not nothing quite so much, but I met her about a decade ago and, and is she, this is kind of exciting for me because this is the second time we've only done two books so far, but I really appreciate the fact that we're talking to authors who actually have done the work. You know, she's the real, she's hardcore. She's an engineer and, and she's not just talking like a consultant. She's not just, just somebody who sells some particular prescription for a solution. She has done the work. She's, she's been in the hole with us and she knows the way out. So this is going to be exciting. And also, um, she is one of the inventors of Kanban. Back in the early days at Corbis when Kanban was still in its infancy, she was on the original team that discovered everything. That became what we now know as the Kanban method for software development. So, so I'm pretty excited about this.
Speaker 2:Yeah, I show your excitement, but I also got a little bit stressed because you know me, I read the book twice or three times before our interview. I tried to find everything that I can find on the Internet regarding the people that we are going to talk to and seeing, you know, her experience and knowledge and everything got me into a little bit, you know, stress. But I hope it will go smooth.
Speaker 3:It'll go smoothly, it'll go smoothly because she, I, I like I told you I, I met her once but she's super nice. I mean she's just like, she's like the voice in the book. She's easy going and casual and playful and nice and you'll like her. So this is going to be a fabulous interview. I'm going to enjoy it and I hope you enjoy it too.
Speaker 2:I will enjoy it even though that I'm not in Portugal,
Speaker 3:so wonderful. We're delighted to have you here. Thank you. Happy to be here. We met, um, many, many years ago. I want to say it was in Boston. I attended one of your talks on visualization techniques and you were the one who first introduced me to the idea of a Kanban board that looked like an actual road, like an a up road and a board game. And I still use that illustration in my classes just to show people how well, how creative they're allowed to be.
Speaker 4:Yes. That's the one nice thing with a physical board is that there are zero constraints. Every tool has some kind of, every digital tool has some kind of constraint that physical board, no constraints.
Speaker 3:[inaudible] yeah. What would I, the way I often convinced teams to use physical boards, um, because most places that we work, we have to use a digital board just because we're coordinating with people who are remote is digital board is the basic information that everyone needs to have. And your team's personal physical board or your company's physical board. The physical board is the place where you have all of your creative modifications that are just for you.
Speaker 4:MMM. Just for you. Oh, just like for the individual,
Speaker 3:not the individual, but um, but you know, there, there are things that you want to do, things that you want to show that maybe Jura won't let you show. Well your, your physical board place in which whoever's using the board, that the team, a group of teams, that company, portfolio board, whatever it is, the physical board is the place where you get to go crazy and be creative and, and really have the information radiating that you want to be radiating. And the digital tool is just for sharing the basic information with the larger audience.
Speaker 4:Yeah. And capturing the metrics too. I like what you said about, um, showing what you want to be showing physically because it's so powerful. For example, if you're focusing on a pain point at that point in time, like I was working with a company in La and one of their biggest pain points was work that required a purchase order. Oh my gosh. If a purchase order was required, it took forever. So they wanted to bring visibility to that. And so they created a board and they had a horizontal swim lane for work that did not need a Po. And then, and then above that they had another horizontal swim lane for work that did need a Po. And then are vertical columns. They had inserted a column called waiting on p o the peach, a purchase order. And they just sort of like rubber stamp the date that it went in there. And they, they placed this on a large wall, uh, in a major hallway, uh, on the, you know, on the finance floor where a county people could see this. And there's just something about a physical board when you walk by it. The eye tries to understand visually the patterns and the colors and we're trying to comprehend the meaning of this visual. And it was just so powerful in it and it got the message, uh, request it got the message across quickly in a way that a digital approach I think would have been harder.
Speaker 2:So how did it actually work out for the accounting to have this visualization? Because I'm super curious. I know a lot of people that works in accounting and they constantly complained that it's always slow and that it has to be slow.
Speaker 4:Yeah. Um, well I think there's a lot of, I think accounting, uh, and the whole funding model right now is getting a lot of attention because of the traditional project based funding models where all work needs to get assigned to a project and then the project has to get funding. And in many organizations that's an annual budgeting process, which is so painful for organizations because if you want something done in 2020 or if he wants something done in 2019 that had to have been approved and your budgeting cycle in 2018 so that in flexibility with that budgeting and funding approach is coming under fire and we're starting to see some change. It was organizations who need to move quickly to adapt. I mean, how can you say that you're doing agile or Dev ops or, or being lean if you've got to wait 12 months for approval or something, you know, to get to keep funding,
Speaker 3:which is why most projects are late before there started. Absolutely no.
Speaker 4:And it's why we're starting to see project managed work, uh, starting to phase out and being replaced with uh, work managed by products and value streams.
Speaker 3:So going back to visualization, cause I thought that was a really nice segue into the book, which is what we're hearing excited to talk to you about because this is the agile book club podcast. Um, one of the things I really liked about this book, it was the second book in a row that we've reviewed that was basically a book about Kanban that hardly used the word Columbine in it, not in the three. What I really liked about it was, was, um, the idea that there can be so much benefit from making work visible and you're not, you're not trying to sell Kanban to somebody who wants to learn Kanban. It's not like a Kanban versus scrum question. We chose Kanban. So we're bought this book. It addresses con bond from the point of view of its benefits and its a kind of benefit that, that everyone can recognize. People want to not be so overburdened and they want more clarity about their work. Managers want to feel like things are being done efficiently and they want to have clear and transparent reporting and understanding of what's going on in their systems. And you do this so elegantly through the idea of these five time thieves, which everyone knows when you introduce them, but you call them out very nicely. Could you, could you take a moment and introduce us to the five time thieves?
Speaker 4:You Bet. So there are five to use of time that rob us of our day. You know, we get so overwhelmed and there before you know it, our day's gone and we haven't gotten done what we wanted to get done. The first t FIFA time is unplanned work. Unplanned work is the foundation of interruptions. These are the, you know, I can't get the bill to compile. I can't log into the server or whatever. Uh, just the, you know, you got a minute. These, these interruptions that, um, play guard day, the second time thief is conflicting priorities. Uh, this is when, um, people will ask what are we supposed to be working on project a or project B right now? And when the answer comes back as both we know that things conflicting priorities is trolling us, uh, which is, which is very common because team A's top priority is often not team B's top priority, right? People aren't available when you need them. Uh, and then we have a thief unknown dependencies. I call this the big bully thief because it's so pervasive across organizations. The larger the organization, the, you know, the more complex it is, the more specialists we have, the more specialists we have, the more dependencies we have. Um, particularly in, you know, large enterprises where you've got, you know, thousands of engineers building hundreds of different um, products using dozens of different tools. And then there is thief neglected work. So this, the, a lot of this work, it's important work but it, it's always like taking second string or second fit all it, it just doesn't get the budget or they'll love or the attention that it deserves in order to be completed. A lot of this work is maintenance or keeping the lights on or it might be security patches or just fixing technical debt. Things that don't get approved because project managers and business people are so focused on just, you know, putting uh, approving revenue generating generation, kind of work through the value stream. And then lastly but not least is the ringleader of all the other thieves. And that's the too much work in progress. And I call him the ringleader because in one way or another all the other thieves are related to having just too much work in progress. There's just so much demand on people today and it just seems to be getting even more so that people don't have teens, that people don't have the capacity or the capability to keep up with their demand. It's a, it's a rather fancy way of saying that a lot of people are drowning right now. They're in there just underwater, varied. We don't have those time to think is the most rose for the organization. Which time thief is the, well, you know, they are all kind of related to one another. But I've posed this question to a lot of people and the um, biggest answer I'll get back is the too much work progress. Although I do think that conflicting priorities plays a really big role here because if we're unclear on what the priority is, we tend to say yes more to taking work on. Like if, I'm not sure if I should be submitting a talk to, you know, this conference or that conference, you know all summit talks to multiple conferences and because I did that now I don't have time to finish this request that the marketing team wanted me to do today that they were expecting. So I, I do think that not having clear priorities that fif conflicting priorities is it's, I think it's right up there.
Speaker 3:I went to make a comment earlier when you were talking about how people are just drowning in work. One of the things that you observed several times in this book, which really appeals to me and it's something that I try to, to, to convince people of or or, or to show people when I'm coaching them. That's so hard to do. But you put it very elegantly when you said work is neglected when people are busy. Could you explain to our listeners why that is
Speaker 4:work? You stay collected when people are busy, while people tend to be allocated or do it to themselves, allocate themselves at a hundred percent capacity utilization. So the people are busy. But if we're also busy, that means that some of the work is sitting still not moving because if we've got lots of balls going in the air and we really can only do one thing at a time, oh, I mean, I can talk and walk at the same time, but, uh, you know, human brains, we can't do too complex if we're deep into, we, you know, there's something, you know, designing or coding or, um, writing, you know, we're not also at the same time learning coopernetties or something. And so a decision to do one thing delays something else. Uh, and so that's why neglect. There's, I mean, there's always going to be something that's neglected because we're focused on something else because we're so darn busy,
Speaker 3:but people like being busy and in my people would rather be busy than to be seen by their boss to not be busy. How do you address that?
Speaker 4:Yeah. And also we like to be busy even even if the boss isn't looking, I mean, especially if the boss is looking, but, uh, it's, I think we're so, we're getting so used to such a fast paced life that even just sitting still, it's, I think it's why people struggle with meditation. They just have a hard time sitting still. Just being still and thinking is uncomfortable for some people. However, if the boss is observing us not looking busy and there's a, a reaction to that or people get belittled because they don't appear to be busy. That's why I say watch the work, not the people, because it doesn't really matter how busy people are. It matters like when the work is getting done and you can't tell that with knowledge work because a lot of it's invisible.
Speaker 2:I was actually laughing a little bit when you said that people are not able to be like, to sit still because actually I'm one of those person, you know? Uh, so I clearly understand that it's, it's, it's not easy, but I'm on my learn and my learn on my path to learn. But I had a little bit different question because when I read your book, I got so many ideas on how to visualize. Then I went to youtube and I watched I think most of your videos and I go even more ideas how to do it. Yes. What's to to say like, you know, take types of work than priorities. Maybe show dependencies. Then the put also the size of the task that we are going to work on. And all of this, uh, things got me into thinking where to start. When you have the team that has zero knowledge about the visualization and you have like these huge basket of things that you can just take and try to visualize. But we are ev no idea where to start.
Speaker 4:[inaudible] so is your question, where should people start? Yes. Yeah. Well we want this to be, to help them, right? That the, the people who, uh, are involved with the team. So we want them to partake in, in the design and, and help decide where to start. And usually I'll do that with a in in part two I have exercises in the book and there's one called the demand analysis and this is where we ask teams what prevents you from getting your work done? Which is a very powerful question because this is where the pain points are and once they define what those are, then that's a great place to start because then they can see that there's some action that's being taken to relieve this pain, this pain. In addition to that, we ask them, what do your customers complain about? So these are usually internal customers, not external customers or you could do it with external customers, but the intent, people who ask you to do things who are upstream from you or people who you hand your work off to who are downstream from you, what are they grumbling about? Because in order to set up a new way of working, you need to have buy in from the people who are asking you to do things and the people that you're asking to do things. And if you can help solve some of their pain points too, it'll be much easier to get what you need from them done, which is usually approval on, you know, limiting WIP impro work in progress. Um, and the biggest complaint, the biggest pain points that I hear teams talk about is that things take too long. They don't know where it's at. Like where's my thing? I made this request three weeks ago, I haven't heard a peep from you since. Right. So they're the, those are the, some of the, the biggest things. And so if for example, things take too long is the biggest complaint from your upstream customer, then bringing visibility to that about how long things take and then you define, you know, when to start the clock and when to stop the clock. Uh, is, is, is going to be real useful for that. Or
Speaker 2:I have an a, a device. Oh, sorry.
Speaker 4:Well I was just going to say the other example I gave about the purchase orders, like that was a huge pain point for a team. Ah, you know, if it has a purchase order, we're just not going to do it because it takes forever. But so for them to create their design and add that column for needs of Po, there's another example of even if you're, you know, after you've started and you, you're always sort of adjusting things, what's our, you know, once you, once you resolve a bottleneck somewhere and it's going to pop up somewhere else. And so it's really, you know, start bringing visibility to wherever that bottleneck is in your, in your context and your workflow.
Speaker 2:Okay. Do you have any advice on how to train people and show them the value of the work visualization when they're actually so busy when their utilization is, you know, on the high 100% and then somehow ask them, like to give us their time to learn a little bit more about the visualization, how to coach them, how to train them, how to show them the value.
Speaker 4:Oh, that's a tough one. Um, because people, because when they go to training and it takes away from what they're supposed to be doing, uh, and so sometimes in workshops, people in the beginning, there'll be disengaged and they'll be on their laptop working. And so I frequently ask a, who in the room here is, you know, is like a prisoner? Like, like who doesn't want to be there or boss mate. And sometimes people were really honest, like, I'm a prisoner here. Like, I really don't want to be here. And then like, okay, so like who's just here to Sorta pick up a few tips and then like, who's all in? And so from the get go, I sort of ask what situation you're in and I sort of want to respect that. But usually when we do this demand analysis exercise and they have the opportunity to write out and explain and describe to people their pain points, then we get some engagement on. Um, because there's hope. Then that may be, you know, we're going to design a system that's going to make this pain visible, which is going to provoke necessary conversations for change and that they will be the ones, um, you know, sort of Ins instrumenting does, uh, their experiments for change. And so that I have found that to be pretty useful for a lot of people, but there's out, you know, it always seems like there's a couple of folks that, and they, they just, they just may not be ready for it. They just made up for it.
Speaker 2:So what do you do with those prisoners? If they raise their hands and say that, yes, I'm a prisoner here, I have a 100 requests waiting for me and I have to be here.
Speaker 4:Yeah. Then I, then it's their choice because we can't teach somebody something that they're not ready to learn. Maybe, maybe there'll be back, you know, six months or something. Maybe they'll, I mean that people are under that much stress and pressure. It's not sustainable. So eventually, uh, well the capable ones who are successful and open to learning and ready to move on, you know, they, they do move on. Um, if they don't, if they're not empowered to have some time for learning or training, we want to be always be learning organizations. And so, you know, a lot of the, well, a lot what we're starting to see now is Dojo has pop up at organizations, especially when it's doing Dev ops and bringing teams in for three to six weeks at a time for new learning, for new training because so that people can adapt to new ways of working and improve the way that they're working. If you're stuck in Myron in organizations that don't empower people to have time to learn new things and do training, then those organizations are losing good people. I wanted to talk a bit about a work progress. You
Speaker 3:talk a lot about this in the book. It's, it's one of the, the cornerstone solutions to so many of the issues that, that are caused by the time thieves. Um, how do you go about limiting work in progress? How do you figure out how much till the mid, where do you limit? How do you convince people it was a good idea? Yeah,
Speaker 4:that's such a good question. I think my answer to that or my approach is, is probably very different than most coaches. What I tend to do is I just say, just, you know, get your, get all your workup on this board, let's see what you have. And then we all stand back and we look at it and we say, does this make sense? Say you've got 300 sayings upon your board for a team of 12 people or something ridiculous like that. Does this make sense? And people will say, no. Now it's like we're drowning because we too much. Like what do, what should it be? Um, actually I did this with team, it was a hundred things. Uh, you know, does a hundred makes no, no, it doesn't make sense. What should it be? It doesn't really matter. 95 is better than a hundred, you know, so can so continuously drop it. So it'd be like, you know, you finished five things, don't take five more things in it, right? Drop, drop your limit. It's like when you, maybe companies will have to let go of some people, but they'll let them go through natural attrition and they just won't hire new people and that's how they'll get their head count done down. Same thing with whip. Just let the attrition of the things finishing finish but don't, don't bring anything new and just continuously drop the number of the amount of work in progress on your board down to a number that where you start to see flow. If work is not flowing, then the web is too high.
Speaker 3:From the point of view of a team. What is flow look
Speaker 4:like? Flo is the smooth, fast, predictable movement of work items through a value stream. Um, so flow is, um, I mean, well flow is the first way a Dev ops. And when we say that, what we're talking about is in order to deliver customer value quickly, we need work to be flowing, you know, quickly and smoothly, uh, and predictably. And so if work is just sitting in your board and not moving at all, it becomes stale. It's sitting idle, that stuck work that's thief neglected work right there. And that's a signal that something's, you know, you've, you've got send dependency or there's a problem there. I mean, that's when you want to pull the and on chord to say, hey, we need some help on stucking this, this thing that stuck.
Speaker 3:You know that, that's a great observation because so often, um, the reason why there's so much work is because it's all important and it's all important because it's tied to somebody who requested it. And when somebody requests that a team do something, what they, what they want, what they appear to want is to have something done right away. And the easy answer to that is, well, we started that. It started, don't worry, we're working on it, but nobody actually wants to say what I mean when I say will working on it is that we are presently in the process of neglecting it. Yes, yes. We are actively neglecting that as well as most other things. They're, they're being actively, aggressively neglected. You can see it on our too. So I liked that a lot. So what do you say to people who resist the idea of limiting working
Speaker 4:progress? Well, I talk about the benefits of limiting work in progress. Work in progress is a leading indicator and we don't get very many leading indicators in our line of work. I mean, if you're looking at cycle time or through put or whatever lead time, uh, that those are all trailing indicators cause you don't know how long it took to do something until it's done. The single most important factor of how long something is going to take to do this capacity utilization, it's how loaded people are, and I'm talking about flow load here. The amount of work in progress that they have[inaudible] an example I like to use is you get on the freeway, you get on the highway to drive home or somewhere. If that freeway is utilized at 100% it doesn't matter if you're in a Ferrari, you're still not going to get home any faster because the freeways move in, they don't go fast when they're utilized at their full maximum. In order to have flow on the highway, you need to have space between the vehicles. And that's why we see, so I live in Seattle and in Seattle we have during rush hour traffic, we have traffic lights at entrances, excuse me, at onramps to the highway and you have to wait at the red light until there's enough space between the car ahead of you that went. And so this allows for smooth merging of vehicles onto the highway and other cars don't have to stop and slam on their brakes because a car just cut in front of them. So did that answer your question? Yes, yes, yes, yes.
Speaker 3:So no, obviously you can't have all the work flowing absolutely smoothly across the board. There's, there's one of the reasons why, um, work might be neglected, which seems to be very legitimate from the point of view of the team is that they have dependencies, all sorts of dependencies, dependencies on specialists, dependencies on other teams. You outline a number of approaches to identifying and dealing with dependencies. Could you tell us, um, when you're in an organization working with a team and they have a lot of explanations for why the WIP limits should be higher because it has to accommodate stuff that's just waiting on things that are beyond their control, what do you do with them to help call these things out and to find solutions for them?
Speaker 4:Well, my practices around that have evolved a bit since I wrote that chapter in the book. Um, I mean it is still h w w cause one of the things is that very few people use dependency matrices. Um, they might for their code or their architecture for it, but they don't really between teens. And I do have a second. So in the book where I talked about managing by product over project, which I think is revelent uh, relevant to your question because if teams can treat their value stream like a product instead of ignoring it, that's immensely useful. If we're managing work in projects and then there tends to be a lot more dependencies. You know, you've just, you're, you're trying to wrap this project up, you've got to go start another project. So now you've got to pull people off of this one project. They go work on another project. They were experts, they were subject matter experts. Now they're not available, but maybe you still need something from them, but now you got wait on them. There's, so there's a dependency for that. Or the other big dependencies lie in shared services teams. So if you've got a DNS issue, you've got to wait for somebody from the network team to come help you resolve it. But people in the network team aren't available because they're dealing with some firewall issue in production. And so instead of bringing the people do the work, we want to bring the work to the people and organize around a value stream where we keep the subject matter experts in their specialty, in their domain for that product to, I mean we're trying to reduce, there's all kinds of ways to organize, but if you can reduce some dependencies by organizing and aligning teams with their, the product they work on or the value stream that they work, that's going to help reduce dependencies.
Speaker 3:[inaudible] I can see how even if these people didn't sit together, even if the network administrators were still state sitting with other network administrators in the subject matter experts, we're still sitting someplace else. If they're thinking in terms of a smooth flow of the value stream per product, then it eases collaboration between people.
Speaker 4:Yeah, yeah. They have the, exactly. Their priorities are aligned to get, you know, whatever it is with that product. Their priorities are aligned. If you're on different projects now you gotta um, escalate things up above to the PMO or some portfolio managers, something, what's the highest priority? A or B because it's going to be different across different project teams. So you're aligned by the product and you have to do a discern, you know, fix some technical debt. You can have conversations about maybe holding off on this new feature requests so we can fix this technical dat and people will have an understanding. I mean you can talk about those kinds of strategies, um, for the different kinds of work.
Speaker 2:Okay. Uh, I would have a little bit farther because I am kind of a curious person. And when I was reading your book and then when I watched the, our talks on Youtube, I was asking myself, how would you solve all the problems that you faced when you are working at Corbis? We have the knowledge and experience that you have right now. So if, uh, if now you'll have a chance to come back in time and work there again, what would you do differently?
Speaker 4:Oh, my stomach.
Speaker 2:Oh, mine.
Speaker 4:Um, top three. Top three. Top three. I never would have taken on that additional role at a SAP, but, um, I just thought, oh, you know, I'll learn something new. And, um, that was a mistake. I, there were, yeah. Uh, so I would've been a lot more open to getting feedback from my upstream and downstream customers. For example, when developers were complaining that things took too long and how they wanted control on their own environment, I would have done, I would have reached outside of Corbis. I would have tried to find a community or find people. I would have reached out to people in other companies to see how they were solving the problem. That was probably my big one. I biggest failures was just sort of staying inside the company. I don't, I don't think though that we had as much community or a different user groups or communities of back then like we do now. Um, but I, I felt, I feel like if I would've done that, I would have learned a lot more about how organizations were building out environments, uh, faster and quicker and I would have heated, uh, I, instead of taking it personally, oh, builds take too long, you know, you're too slow. Instead of taking that personally, I would have maybe asked more for their help. Like, how can I help you solve your problems faster? I mean, the, the problem was they would do, you know, they would do builds and then we would build it and compile it and then the build team would deploy to the Dev environment and the developers wanted to be in control of the Dev environment, which makes, makes sense. The problem was that I, my team was accountable for keeping that environment up and running. If it wasn't it, you know, if it didn't have the right data or if it didn't have the right config settings, then it was me who got paged at 2:00 AM in the morning. So hence I wanted to have control of that environment so that I could troubleshoot it easier. And I knew what was wrong with it. If I handed it over to the development team who is making all kinds of changes from all different branches and code that may or may not have been checked into source control. Um, you can see why I was resistant to that. But what I ended up doing was just saying, okay, you, you build it, you own it. Like, like you, like if something's not running at 2:00 AM then then you handle it. I should have just let it go. Um, so that's one big thing that I would've done differently is I, I would've been more open to feedback from colleagues. I would've reached out to my people who were in my role in other companies to learn what they were doing. I probably would have read, I probably would have, um, I'm just going to say, read, I was reading a lot of business books back then. Um, but I would have tried to find ways to learn about the latest technologies and optimizations that other organizations were doing that we didn't know about yet. Back in 2004, 2005. Yeah. Now, what was a joy ever? The first thing be um,
Speaker 3:those two are good enough. Okay. Yeah, yeah, I'm satisfied. Satisfied. So that's okay. There are a lot more support groups out there right now, but a lot of people don't have easy access to them because they don't live in major cities. Example. And also because when you were, when you feeling like you, your, you were drowning and you're working late nights and coffee fueled weekends, going to meetups doesn't really feel like an option. So I think it's fabulous advice when you're drowning to reach out to peers, even if, if you can't make it to a Friday evening meetup, just call somebody who does the same sort of job because you can't, you can't take yourself out of a hole by doing the same thing you've always done.
Speaker 4:Yeah. And now it's so much, I think it is so much easier now because you've got Twitter and Facebook groups and even if you can't go to a meetup in person, I've just, I've made so many friends just on Twitter and I became good friends with them. I, and I didn't meet them till, you know, a couple of years later that there's so much learning now and all the youtube videos out are out, all that, you know, like all that Dev ops enterprise Tom, that videos are just out there free for the last five, six years on youtube is fabulous.
Speaker 3:So this has been terrific. I want to ask you, um, is there anything else that you'd like to share about the book or about your experience while we're talking?
Speaker 4:Yeah, I think there's a couple of key takeaways I'd like for readers to get out of my book. And the first one is to, is to ruthlessly protect your time and learn how to say no. I mean saying no doesn't make you an arse. It sometimes it's just the right thing to do, a split say no and it's uncomfortable. It's a learned skill and it just takes a bit of practice. And one way to do that is to I, there's a part in the book where I call interruption busters. Ways to prevent yourself from being interrupted and distracted through the use of, um, when I call do not disturb hours on your calendar. If you're, it doesn't really matter what your whip limit is. If your calendar is chock full back to back all day long, like you got the all day cram going on in your calendar and you have zero time to do your most important work during the day. When do you do it? It's how you do it at 10 o'clock at night after you put the kids to bed or you do it on Sunday afternoon. It's like Sundays, the new Monday now. And so it is just essential to protect your time ruthlessly and learn to say no to things that are not, you know, it's, it's no is an honorable response to somebody who is asking you to do something that is not in line with your goals. Uh, and then s I think, um, just whatever you can do to help people visualize their pain points so that it will provoke these necessary conversations to help you do something. It. Uh, and then I just want to bring up flow metrics. There is a flow mat check called flow distribution. It's not in my book, but it should be, um, where the, how you categorize your work. And I think there's four categories that a of work that are really key for people to whatever work you put on your board, put it into one of these categories. And one would be like features, this would be revenue generation kind of work and then one for technical debt or internal team improvements. So that teams, if you can allocate one of those every so often and it's huge morale booster and then have a workout in type for some kind of risks like security breaches or compliance. And then another one for a d facts being categorize your work and those categories. Then you can start to measure them and you can start and you can tag on planned work on that too. So you can start to see how much unplanned work is in your system. Cause if you're, if you're not finishing your planned work because you've got all this unplanned work, then it's, it's like the perfect crime because there's no evidence of all this unplanned work that you're doing. So I, I do talk about flow metrics in the book flow time and flow efficiency and I just wanted to add flow distribution onto that is I think really critical for people to measure.
Speaker 3:I liked that especially since those last three categories of types of work. If they're not budgeted for you for in your, your time and if they're not budgeted in your whip, then they tend to present themselves eventually as crises. Exactly. So that's terrific advice.
Speaker 2:The one more thing that I really got from your book and that changed my current workflow, uh, is that I'm trying to kill my Zombie project. I wish it would be like a bigger chapter to know, you know, how to do it even faster and how to understand faster that it is like a Zombie project and you have to kill it and release your resources. But I really, really would like to say a personal thank you for mentioning that because it's really eye opener. At least it was for me.
Speaker 4:Yeah. The Somby projects. Yeah. It's that um, sunk cost bias that we tend to hang on to things because we've got so much invested in it. Instead of recognizing how much more work it would be to finish it versus finishing something else.
Speaker 3:Just out of curiosity, how many of those Zombie projects came from my ideas that you're squashing?
Speaker 2:It's not the, that in last month when we are preparing for the podcast, I was saying no more often than usual I have noticed. Yeah. Thank you. Thank you. Dominica. Yeah.
Speaker 3:So thank you so much for taking this time to spend with us. Um, it's been delightful talking to you.
Speaker 4:All right, well thank you so much for having me. It's been great to talk with you while I'm here in London.
Speaker 3:Fabulous. Enjoy your time in Europe and thank you very much. Yeah, no. Okay.
Speaker 2:Yes. Thank you very much. And I hope that I will be as lucky as Paul and also meet you one day.
Speaker 3:Me Too. Yeah. Bye Bye. Okay, bye bye. Thank you. Bye Bye. So, so I hope you've enjoyed this, this fabulous conversation that we just had with the Monica to greatness. Um, if you find the work that we're doing here valuable, then I've always said, and you've heard me say this before, it's only four episodes in, but you've heard me say this before, the most sincere form of thanks is cash and it costs us a fair amount of money to make this podcast. We've got hosting costs, we've got all the various tools that we use, we've got editing costs.[inaudible]
Speaker 4:hmm.
Speaker 3:That I'm that any flood, the Portugal doesn't count as a podcast call, but you know, we're spending like what's pretty like$150 a month or so on making this podcast happen. So if you find this useful, then we'd really appreciate it. If you'd help us out. We've got the Patriot and um, you can, you can click on the patrion link in your podcast tool, whatever it is that you use for listening to podcasts. It has a link to our patrion and we'd really appreciate it if you would help us to pay for this because hopefully we'll get to the point at which we're providing valuable enough content that you are happy to help us cover the costs of making it for you. Interviews like this one with the Minica grandis and of course the reviews of all of the fabulous books to come. So, so what can they look forward to next? You're still at what? What kind of listeners look forward to next in our podcast coming up in two weeks. Oh wait, do I? But you mean the podcast,
Speaker 5:uh,
Speaker 3:with Mark's book or, yes. Oh, sorry. Two weeks after this, this podcast will come out on the 15th of July and on the 1st of August there's going to be a podcast about Mark's book. So what can people look forward to in the next podcast if they subscribe now in their favorite podcast listening tool?
Speaker 2:That wouldn't be for awkward people because I don't remember the title of the book. I know that it's about retrospective or don't it on Amazon. And it's too, so maybe
Speaker 3:we won't include that because I don't remember the title.
Speaker 2:Erica. We like you. Oh wait, wait, wait. I got it. Right, right. It's coms. Oh No. I have to log into Amazon to see that it's moving agile and then something, I hear a dog, it's the dog. Actually, the few minutes before he called me the, there was someone started a renovation above me and I was like, no, when they stopped and then they stopped and now I hear it again. Okay. Improving agenda, retrospectives, helping things become more efficient.
Speaker 3:Okay, so what can our listeners look forward to? What kind of listeners expect from our next episode in two weeks? So you're still in two weeks we're going to be releasing a new episode and it's going to be exciting. It's going to be as good as the ones we've done before, maybe better. And it's going to be about
Speaker 2:improving[inaudible] retrospectives, how to help your team to become more efficient. And I'm for a happy to interview mark because I met him only three years ago, I think on one of my first eighth conference and I didn't have a chance to talk with him, but when I've seen he stuck, it was so much fun. So I expect that the book will be fun too.
Speaker 3:Yes, mark is an old friend of ours from the early days of ace. He's been one of the popular speakers at the ace conference for several years and a, so it's going to be really nice to get to talk to him again. And I'm really looking forward to reading and reviewing his book.
Speaker 2:And the specialty does. Mark was one of our friends first fresh faces at the conference as was, he's the first, and this was his first conference that he had the chance to speak in public. That's right.
Speaker 3:And you know, he wasn't planning on it at the very first ace conference. He wasn't one of the speakers. He did a, um, lightning talk is how he found the environments. So encouraging and welcoming that he thought he would get up on stage and use the lightning talk sessions to share a few ideas that he had. And he had so much fun doing it that he became a public speaker. And now he's a keynote speaker, so,
Speaker 2:and the writers are fabulous. It's something
Speaker 3:and a writer, and we're going to be talking about his first book in two weeks. So join us on the agile bookclub podcasts to learn how to make your retrospectives better with the person who is an expert at it, who has been doing it for over a decade. Mark law officer.