#107: How Scrum Can Make Your Company Stronger with Angela Druckman

Guest Introduction (0:00) Sean Weisbrot: If waterfall can be so powerful, why is it that you focus on Scrum? Angela Druckman: Because your predictions are only good if they’re right. So, if they’re a little bit wrong, that’s not too bad, right? Right. But what if they’re a lot wrong? Sean Weisbrot: Welcome back to another episode of The We Live to Build podcast. This is episode number 107 with Angela Druckman, the president of the Druckman Company, which provides Scrum training services. She’s also a certified Scrum trainer and Agile coach, and the author of 30 Days to Better Agile, the definitive guide to resolving the toughest challenges in every Agile implementation. She has been doing this for over 20 years and she has introduced Scrum and Agile practices to thousands of students around the US. And I think outside of the US as well. Angela Druckman: Yeah. Five continents. Sean Weisbrot: I think I’ve been to five continents, so it’s a good achievement for you. She’s worked with some of the largest technology, manufacturing, retail and financial services companies in the world, along with small startups, government organizations, and not for profit entities. So, thank you for taking the time to talk with me, Angela. I appreciate it. We’re going to be talking about Scrum, your bread and butter, I don’t know… Angela Druckman: Sounds good. Sean Weisbrot: …pretty much anything about this. I’m coming at this from the point of view of a five-year-old. So, I guess the best thing to start off with what is Scrum? What is Scrum? (1:31) Angela Druckman: What is scrum? Well, I always tell the people who attend my class, if you like, told me if you gave me the directive, explain scrum in the least words possible. Even if, if it isn’t a thorough definition. What is it? I would say it is an agile project management framework. So, if I get to use a few more words than that, then I would say what Scrum is. It’s a framework for managing projects and other bodies of work is how I’m going to describe it. Such that you focus on delivering smaller bits of usable functionality, getting feedback on that. As in are we building the right thing? Are there other things we should be adding in and then repeating that whole process? So, Scrum is what’s known as an empirical process control system. You hear that word empiricism, you probably think like 9th grade science, right? That’s pretty much what it is. It’s this idea of working in short iterations. Then it’s evaluating the result, taking feedback, folding the feedback in and repeating. Sean Weisbrot: Pretty simple explanation, although there were a few words in there that were a bit high level, maybe college level words, but I think everyone here can understand what they are. So, before we go deeper into Scrum, it would be great if you could quickly, quickly explain a few of the other methodologies that companies might be using. Angela Druckman: Sure, absolutely. We can kind of divide them into two broad categories. There are predictive models of risk control in projects, and there are empirical models of risk control. And anybody who’s listening in who is a project manager, you know all about predictive models of risk control. That is what a project manager might refer to as waterfall. PMs know that word really well. The idea with a waterfall approach or a predictive model is you should hear that word, predictions, right? That you are trying to control risk by making accurate predictions. So, if that’s your approach to managing work, everything hinges on accurate predictions. That’s why when you approach a project, let’s say a long, yearlong project with waterfall, you do these big requirements gathering phase up front. The goal of that phase, ideally, is you’re going to identify every single requirement upfront. And that is cool when you can do it, because then you can give those requirements to, let’s say, a project manager and basically tell that person, this is what we want. Now you tell us how long will that take to build? What will it cost? What resources do you need? In other words, the project manager is going to give you a project plan, which of course, is another set of predictions in a waterfall or a predictive model of managing work. That point right there where we have all the requirements and a plan to deliver them, that is when the technical work could begin. So, if you were, as an example, building software. That is the point where you would start things like a technical design, software development, testing, implementation. And then when you get to the end of all of that and you’re trying to evaluate, okay, we built something. Was this a good project? What you’re really asking is, did we deliver all of the requirements and did we do so according to plan? Project managers listing, you would call that on time and within budget, right? That’s what we talk about. And if the answer is yes, then that’s a good project. So predictive models are kind of the other side of Scrum. And the empirical models. Waterfall vs Scrum (6:04) Sean Weisbrot: Okay, that’s a really good breakdown. I appreciate that. So, if waterfall can be so powerful, why is it that you focus on scrum? Angela Druckman: Because your predictions are only good if they’re right. So, if they’re a little bit wrong, that’s not too bad, right? But what if they’re a lot wrong? What if you are confident, we have all the requirements identified, we can get this done in six months. There were a bunch of requirements you didn’t know and it took you twelve months. What that tells you right there, you use the wrong approach to manage that project, you would have been much more successful with an empirical approach like Scrum. So how do you know? How would you know this project? Waterfall will be fine? This one, we’re going to have to use an empirical approach like Scrum. Basically, you want to look for three flags. These are flags that tell you pretty much, I’m going to have problems on this project, this Scrum can help me fix. So, the first flag would be, it is a project of higher-than-average risk. So, let me give you some examples of what makes a project higher than average risk. This isn’t an exhaustive list. It’s just examples. It’s big. And when I describe a project as big, it could be long or it could be lots of people. To me, either of those are a big project. Other examples would be it’s something you’ve never done before. You have an inexperienced team, even things like working with a new vendor. So, we never worked with these guys before. This is bumping up your risk. So, higher than average risk is the first flag you look for. Second flag you look for. One or more of your resources is uncomfortably limited. So, you don’t have enough of something. A couple examples of that… Sean Weisbrot: Money. Angela Druckman: Pardon? Money? Yeah. Somebody told you, look, I can give you 50 grand for this project, but I can’t give you a penny more. That’s going to have to do it. Other resources, though, like, let’s say you asked for a team of 15, you got a team of seven. Okay? That’s a case of I don’t have enough. And whenever you don’t have enough, you have to use what you do have very carefully. And then the third flag to look for I’m going to tell you right now, this is the most common, is you’re on a project that is going to have emerging requirements. Meaning you cannot get all of the requirements upfront for a very good reason. They don’t exist yet. People are still figuring out what they want. So, what I tell people is, if you have any one of those situations, especially I would say the last one emerging requirements, I would consider using Scrum. But what if you have all three? Let’s just map out real quick an example like Nightmare Situation. Sean Weisbrot: My company. Angela Druckman: Yes, all three of those things going on. Okay. How can Scrum help you? All right, let’s walk you through let’s walk you through a quick example. So, let’s say we’re, we’ll take the pressure off you for a minute. Let’s say it’s me. I’m a great big project. I don’t have enough resources. My stakeholders don’t know what they want. Okay? The first thing Scrum would say about that, let’s say, it’s going to be at least a year long. It’s a big long project. Scrum would say a year is a lot of time for stuff to go totally off the rails. So, the first thing we’re going to do with that year is we’re going to take it and chop it up. And we’re going to chop it up into short predefined periods of work called sprints. Some people don’t like that word, sprint. Okay? Use the word iteration. It’s the same thing. It’s an iteration. So, let’s say now we’re in our first two-week iteration. At the beginning of that iteration, the team doing the work is going to make a commitment to have working product done by the end of that first sprint. So, they make that commitment and then they build the working product. And at the end of the sprint, they share what they’ve built with the stakeholders and they get feedback. But here’s the thing. Before they go on and they do another sprint, whatever that feedback was, let’s say it was some new requirements that gets folded in. And that is why all of the agile approaches like Scrum talked about doing iterations followed by inspect and adapt points. But if your listeners are like that’s a mouthful, call it a checkpoint. Okay? Make a commitment to build working product. Build it, share it with stakeholders. Get new requirements and fold them in and repeat over and over and over again. Sean Weisbrot: I wish I knew you, like, four years ago. Angela Druckman: It’s a very powerful way to work. And for what it’s worth, I, too, had to learn this the hard way. I did. Sean Weisbrot: It was a very expensive mistake. I started a tech company with no tech experience, no tech background. I mean, I understand technology kind of more of the hardware and networking side than the software side. And I’m not a coder, but I somehow put together a tech team, and we were doing Waterfall with emerging requirements and limited financial resources and yeah, it’s a freaking mess. Angela Druckman: Yeah. It’s really easy to see why Scrum got started in software, because if you think about various software projects, I don’t know to say I’ve ever been on one where Waterfall would have been an ideal choice. Now people will ask me, they’ll say, so is waterfall, just, is it just bad? Is it, like, evil or something? And I always tell them, no, but it’s a tool. And it’s like any tool, you use it in a situation where it isn’t meant to be used, it’s not going to give you a good result. And I always tell people, are there projects where waterfalls are perfectly good choice? Yes. There are projects that have these three characteristics, and tell me if yours at any of these. They are short, they are extremely well understood, and this last one is a big deal. It’s something you’ve done a gazillion times before, and every time you do it, it’s pretty much the same. That’s a perfect Waterfall project. Situations where Scrum is useful (13:37) Sean Weisbrot: I didn’t have any of those things. And we absolutely did not qualify for Waterfall. And I didn’t know anything about project management, and I had to learn. And my CTO was helpful. We eventually got into sprints and like a year and a half ago almost, we hired a product manager. And I totally stepped out of project and product management, and that was the best thing we could have done for the team because I was not helpful. No matter how much I learned, I just wasn’t getting because I was so focused as the CEO, I was focused on other things. And so, I was only able to do what I could do. And I was also the UI UX designers. Freaking best. But being a startup, like, with limited resources, you have to do everything until you can afford to hire people to do things. And even then, there’s still never enough people and never enough money and yeah. Angela Druckman: Exactly. Sean Weisbrot: We’re still learning. Angela Druckman: And those are situations where Scrum can be so helpful, because Scrum is all about helping you deal with unknowns and make the best use possible of scarce resources. And that’s every startup I’ve ever worked with is scarce resources. As a matter of fact, I can tell you quite honestly, when I think about clients who I taught Scrum to, where I felt like they didn’t get a lot of positive results from it, or at least not as much as I wanted them to, very often they were clients that had the problem of having too much money. So, I’m thinking in particular, I won’t name the client, but this is a company where the people who fund them have another huge company that’s extremely profitable. So, this other one is kind of a passion project for them, and money is infinite. They’re basically just like, let us know when you need more and you can have it. So, there’s not a lot of motivation to try to, hey, we’ve got scarce resources, let’s really use them carefully, because they don’t have scarce resources. And in a situation like that, all of the urgency that Scrum brings, working in iterations and focusing on commitments, people are kind of like, there’s really matter. If we blow $4 million over here, we’ll get another 4 million and of the matter. Sean Weisbrot: Yeah, I came to realize that as well, because in the beginning, we’re on a VC track. And through the podcast I’ve interviewed, I mean, I’ve had conversations with several hundred founders, and I’ve only published 100 or so of them. And at first, I thought, oh yeah, raising millions of dollars from VCs is great, but oftentimes it takes a lot longer to get profitable. And all of these things happen as you’re talking. And when I talk to people who bootstrap their businesses, and they’re now doing millions, tens of millions, hundreds of millions of profit revenue a year, they had no money to start with. And so, they were lean and mean and they got it right and they were profitable. So, the more I’ve gotten into the interviews, the more I’ve been like, damn, raising money from VCs is just like, people think it’s a good thing. But I’m starting to disagree. I think it’s not beneficial to have all that money thrown at you. Benefits and challenges of Scrum (17:07) Angela Druckman: Well, I think in Scrum we would say, like anything, it has a cost and a benefit. So, the question is, does the benefit exceed the cost? But you can see examples of this in well established businesses. So, I don’t know if this is common knowledge outside Seattle, but in Seattle, of course, the birthplace of Microsoft, it’s common knowledge that the reason Microsoft accumulated so much cash in the beginning, they didn’t pay a dividend for the longest time, is that in the beginning, Bill Gates hired his friends, that was who worked for him, pretty much his friends. And he would think about the prospect of not being able to make payroll to his friends. His friends who had given up other careers to come and work there. So, he said he made it a goal to always have enough cash to cover a year of payroll. And that is why Microsoft started off so cash rich. It was that kind of motivation. Sean Weisbrot: I hadn’t heard of that before. That’s pretty cool. Angela Druckman: Yeah. Sean Weisbrot: So, what are the difficulties you see clients have in adapting to Scrum? Angela Druckman: You know, and I want to say this from place of love, because I used to be a project manager way back when, too. But sometimes, especially in my classes, when I have former project managers or current project managers, I almost feel like what it must be like to deprogram someone from a cult because they have been told so many things that just aren’t true. I was too. I was taught if it’s in a multi color dance chart, it’s true. And I was taught if I go to a client and say, okay, tell me every requirement you want. Is that all of them? Will you sign this document that says that’s all of them, there wouldn’t be no other requirements that cropped up? And that, of course, isn’t true. So, kind of deprogramming them from this belief that somehow giant air quotes, we can get all the requirements upfront when the people who are asking for this thing to be built don’t even know what they want, but somehow, we’re going to get them all upfront, convincing people that that isn’t true. You’ve been lying to yourself. It’s a huge challenge. It really is. The way I describe it in my classes is I talk about staying in Reality Land. That’s what I do when I do Scrum, I stay in reality land. And I feel like the things I was taught as a project manager, and when I say things, I was taught basic things about how to report on Project Health, how to report progress. I feel like those things are not based in Reality Land. They are based in some other universe that I don’t live in. I think probably where the fairies and the unicorns live, where it’s like, yeah, it’s in a project plan. So, it’s true. It’s hard to get people to admit that’s not. Sean Weisbrot: So, what do you mean by that? Like, not having Project Health and all of these things be in reality land. Angela Druckman: Oh, I can give you a crazy funny example. Anybody, any of your listeners who have even a little bit of project management background, they’ll laugh at this one. They probably had an experience similar. There is a common way of reporting on project health. I’ve seen it in thousands of companies called green, yellow, red. So, if you have a project that is green, I guess all well, yellow is supposed to mean maybe there are some issues, and red is supposed to mean we’re on fire. So, true story. This is way before Scrum. This is back in my consulting days. I was a consultant project manager, worked for a consulting company, and I manage projects for external clients. Part of my kind of duty that I did with my clients is, once a week, I would do a status report for them about their project. I would say whether their project was green or yellow or red. And then I would give some reasons. And if it was a local client, which it usually was, I would drive over there and we would talk through the status report. We’d talk about issues, questions, all of that. So, one day, I am putting together my status report because I’m going to go see my client that afternoon. And my boss calls me. He says, hey, I want to come over and see your status report before you go this afternoon. I’d like to see what you’re going to say. So, I said, sure, I’m working on the status report right now. Come on over. So, he walks over to my cubicle. This is like an office situation. And when I say I was working on it, I was typing it up so it’s on my screen. So, he walks up behind me, and he’s just reading it on my screen, standing behind me. And I hear this big sigh. And he says, Angela, don’t call that project yellow. Whenever we call a project yellow with this client, we get in a big argument about whose fault it is yellow. And the whole thing just turned turns into a finger pointing exercise. Nothing good is going to come from it, just on the staff’s report. Just please don’t call it yellow. So, I said his name was Mike. I said, Mike, I kind of have an ethical problem with that. I mean, there are some pretty significant issues on this project. They’re on the client side. I just wouldn’t feel like I was doing my job if we didn’t talk through those. And he looked completely relieved. He said, oh, yeah, I want you to talk to them about it. But on the status report itself, I don’t know, maybe you could just call it Green with problems. In case you can’t do the math, green plus problems equals yellow. And I will ask people in my class, you know, how many of you have had something like that, just even for your listeners? I will would ask them, how many of you have ever looked at a project status report and saw the words trending green? You know, the only way you can trend green, if you’re not green, because otherwise you would just say green or a status of orange. Not red. Oh, God, no. Not red. Red is going to get everybody all upset. But orange, see, orange is hopeful, right? It’s like a sunrise. I would feel like I was making really just playing a collective game of make believe. That’s what it felt like to me. And it was so different when I started doing Scrum because all that stuff red, yellow, green, made-up colors, who knows what percentage complete? All of that went away. And here’s all I wanted to know from my team. What’s done and what’s not done. That was a very different conversation. Implementing Scrum approach (25:19) Sean Weisbrot: Yeah, for sure. I can imagine. There are times where I’ll peek into tech and I’ll be like, hey guys, what’s going on? I go through these cycles of like, once every quarter, pretty much. I’ll kind of be like, hey, look into a specific aspect of the business to see what’s going on. The team never likes it, of course, but I have to see. I don’t normally bug them with their decision making, but I do want to see where we are and where we’re going and all that. I’m glad I can say we’ve never had any of these project report things. Most of our reports are based on how many story points did we get assigned this Sprint and how many did we actually complete and what’s the lag if there’s anything that hasn’t been done and what’s being moved on to the next thing and to the next Sprint, these kinds of things, I don’t know if that’s more valid for you as a report. Angela Druckman: Pretty much what I want to know when I function in the role of product owner, which is one of the three Scrum roles, scrum master, product owner, and the Scrum team members, what I want to know at any given time, throughout an iteration, what Scrum would call Sprint is you committed to a number of requirements. How many are done right now and how many are not done. That’s all I want to know. Now, for somebody like you who leads a company, you don’t need to get into those minutiae. Not at all. You want to take it up higher and say, okay, there is, let’s call it a feature that we want to roll out to our customers, where are we on getting that feature done? Maybe that feature had a total I’m just going to make this up of 60 requirements in it. Okay, how many of those 60 are done right now? How many are there yet to go? That’s the kind of stuff at a higher level, at an executive level that people want to know about, because that’s the information you can use to plan. Sean Weisbrot: Right, of course. So, yeah, it seems like we’re kind of matching in terms of what we’re referring to those points, where, yes, I do understand my CTO and my COO have tried very hard to keep me out of the minutiae of the product. It’s difficult because I was the product person. I was the product manager, the project manager, the specifications person, the UI UX designer. I wrote all of the documentation, I created every ticket for the team. Like, I was all of it. And it’s difficult to walk away from that. It’s been over a year now, but it’s still difficult. Angela Druckman: Yes, I have a client in Houston. I guess I wouldn’t call them a startup anymore. They’re still fairly small. They’re probably about 400 people right now. But I’ve been working with them since the beginning, pretty much since they were about 60 people. And their CEO is extremely, extremely talented, technically. So, he enjoys the technical work still. And so, he is not only a CEO, but he likes to function right down in the teams as a team member. And it is miserable for the people on those teams. He does it because he enjoys it, because he finds that work very fulfilling, and it’s his company, so he can do what he wants. But I did take some pains to help him understand how unpleasant that is for his team members, because it’s just difficult to function. The thing about a Scrum team is everybody’s equal, but on his Scrum teams, when he acts as a team member, he’s like a unicorn, and everybody else is a quarter horse. So that doesn’t feel that great to the quarter horses. But he’s weighed that out, and that’s what he has decided to do. So, what I told him is, as long as you’re thinking through the cost benefit, and the benefit exceeds the cost for you, okay? That’s all Scrum really asks you to do. Sean Weisbrot: Yeah. We’re at a point where we don’t really have many resources still, so there’s only 13 of us, and we only have one full time tester, and we have a QA manager. So, when there’s overflow for testing falls on me. I know the product better than anybody else, and there are times where I am the employee of the QA manager. Right. Because I’m a junior tester. But there are times where I’m the CEO talking to the QA manager. So, sometimes it’s difficult because he’s like because then he’s actually reporting to the CTO. He doesn’t report to me directly, right, but as the employee. But when I’m the junior tester and I’m reporting to him, I may say something as I have noticed a problem with the documentation. As the person who wrote the documentation, I can tell you that there’s something wrong here. The product isn’t functioning the way the documentation says or somewhere it doesn’t fit. So, it does become quite awkward where I’m trying to talk to him as like, I’m a junior tester, and I’m reporting this to you. But also, hey, by the way, as the CEO, the documentation for the test cases is wrong, so I can’t test correctly. Can you fix them? And he’s like, hey, CTO, what am I supposed to do? And he’s like, listen to the CEO, I guess. Kind of do it. Angela Druckman: That is pretty common if you’re 13 people. If you think of a company having a life cycle, like a human being, you are a toddler. That’s where you are right now. I work with a lot of companies that are awkward teenagers. In other words, they’re big enough that they can’t just wing it anymore, but they’re not so big that they have a ton of momentum behind them. So, if they make a bunch of mistakes, it’s forgiven just because they have all of that momentum. I find it very funny that when I go into a company of let’s say, 60 people, a lot of times that they have an argument with Scrum. They’ll say, Scrum has so many rules and so many restrictions and so many things you have to do. I think it’s way too restrictive for us. When I go into a company of 60,000 people, they say, Scrum has no rules, Scrum has no restrictions. People can do whatever they feel like. And I realized this is nothing more than a difference in perception. That’s really all it is, based on where that company is and its life cycle and what they have been doing. Sean Weisbrot: Yeah, my team, most of the people have come from larger companies, and by larger, I mean anything is larger than what we are. So, like, our QA manager, I think he had 15 or 20 testers that he managed in his last job, so now he’s managing one. So, of course, for him, it’s like teeny. But they have introduced a lot of this structure to the processes and the things that we do, and I think it’s been great for us, things that I had no knowledge of. So, they love Scrum. I mean, we don’t really call it Scrum, but we’ve got the sprints. They’re two weeks long. We got the storylines. I think we do a good job of doing it without me really knowing what the hell is going, because I let them do it. Angela Druckman: Yeah, which is a good thing as a CEO. Sean Weisbrot: I want to know this stuff, because the more I can learn, the more I can do for the company. Right. So, the more I learn about everything that everyone’s doing, even if I’m not telling them how to do their job, the more I learn about everything that the company can do, the more I find everything fascinating. I love to learn anything I possibly can. That’s one of the reasons I do the podcast. It’s so great. I get to learn Scrum from you. Why? I don’t even use it. But it’s cool to know. Maybe there’s some way I can use it later. Applying Empiricism (33:48) Angela Druckman: Definitely. I mean, there’s always a place in life for empiricism. This idea of any of your listeners, whoever had to take a science class in high school or university where you had a lab, if you think about if you ran experiments. For example, let’s say you took a chemistry class, what is an experiment look like? Well, you form a hypothesis. You execute your experiment. If it’s a long experiment, you check on it periodically, right? Then you evaluate the result at the end, and then maybe you change one variable and then repeat that whole thing again to see how that variable has affected things. That’s all Scrum is. It’s basically the experimental method applied to managing work. So, if you just think of it that way, it should feel very familiar to you and makes sense. And then you begin to realize, well, gosh, would there be other places in life where that kind of approach would be useful? And you realize, yeah, we talk a lot in my class because I really want people to get this. Scrum is not a tool for building software. Scrum is a tool for doing work. So, think about things in your personal life, just everyday personal life. Now, we’re outside of work where something like that, that empirical approach could be useful. And I find it’s very useful anytime you’re doing something you’ve not done before. I’ve known many people who use Scrum to run their first marathon because that’s something they hadn’t done before. They done shorter runs, not a marathon. Or you’re doing something that is, you have limited resources. And the classic one that I always bring up as an example is planning a wedding. If you think about planning a wedding, a wedding, once you send the invitations out, is now a date driven project, right, that we’re going to get married on August 15. And whether everything is planned by that, it’s still all happening. And usually, budget is limited. So, what has to flex is scope. What you’re actually going to spend on, this is something that your listeners, who, again, have a bit of a background in project management, they’ll recognize what I’m talking about here. I’m talking about something called the iron triangle. And that’s because the iron triangle is like what they teach you in project manager kindergarten. It’s like the first thing we learn. They have you draw this equilateral triangle and label the points of it. One point will be something to do with money. Let’s say it’s the budget for your project. One is something to do with time, maybe the date you want to deliver on your schedule. And one is something to do with scope. And then they teach you what’s known as the rule of the iron triangle, which goes like this. I’m sure you’ve heard it. You can optimize a project for any one of those easily, and you can usually optimize for two. But here’s the catch. If you optimize for two, the other one is probably going to have to flex a lot to make that happen. You can’t ever optimize for all three. So, in Scrum, when we take that person who is the product owner, the one who drives the vision, here’s what they have to know from their leadership. Here’s what your product owner has to know from you as a CEO. Every time that individual starts a work effort. On this particular work effort on that iron triangle, is there a point that you need me to nail in the ground and not let move, at which point do I have most flex on? And the answer to the first one can’t be all of them. You got to nail all, and the answer to the last one can’t be none of them. I don’t have flex anywhere. You always have to have flex. Sean Weisbrot: Yeah, I wish I knew this stuff years ago. So, there’s something I learned that relates to this in a way that I think is interesting to share here, which is when it relates to paying someone to do something for you, where they say you have this thing and the result can be good, fast and cheap, it can’t be all three. It can only be two of them. If it’s good and fast, it won’t be cheap. If it’s fast and good, it won’t be cheap. If it’s good and cheap, it won’t be fast. Angela Druckman: Yeah, we actually take the good when we go through our classes. If you think of the iron triangles being in two dimensions, we take good out in three dimensions and we talk about what happens when you try when you try to lock down all three points of the iron triangle. And usually when that’s happening, it’s because someone on a project has gotten a lecture that goes like this. The lecture sounds like, OK, look, I know this is a pain, but here’s the reality on our project. Let’s go back to my triangle. The budget signed off with a client like, I’m sorry, it’s in the contract, I can’t do anything about it. And the dates then set for delivery and the scope is all signed off too. And then they tell the poor project team, look, I know it’s not fun, but you guys are going to have to figure out a way to make that happen. I’ll ask people in my class, give me an honest show of hands. How many of you have ever heard that, all the hands go up, they all go up. So, here’s the thing. When you take a technical team and you lock down all points of the iron triangle, kind of what you just did is you put them inside like a pressure cooker and they’re going to look for a place for that pressure to relieve. You’ve told them, I can’t get you more people to help, so it’s not going to be relieved that way. I can’t push the date out a little so I can’t really leave it that way and I can’t cut scope. So, the technical people start thinking, okay, what do we have control of where we can get a little relief here? And the only thing they have left that’s totally under their control is technical quality. So, they start making technical decisions not like they should, which is things like thinking about long term system quality and maintainability no, that’s all out the window. They make technical decisions based on the answer to one question, is it quick? Because if we’re what you’re proposing is quick, we’ll do it, but if it’s not, we’re not going to do it. And I asked my class, I tell them, give me an honest show of hands. How many of you have had someone say this to you verbatim? Just get it into production and we’ll worry about it later. Like three quarters of the hands go up. Well, the thing is, if we let’s take another agile framework, extreme programming, the extreme programming, people would say, hang on a minute, cowboy. There is a flaw in your reasoning. You’re going to create a system that’s cheap to build, but it’s going to be nasty to maintain. It’s going to be expensive to maintain. Technical debt (41:47) Angela Druckman: In Scrum, we would just say you’re creating technical debt. And technical debt, I always give people the definition of it because a lot of people throw that phrase around. They don’t know what it means. I can tell by how they use it. So just for your listeners, if they care, here’s what technical debt is. Technical debt is weakness built into your system because of decisions you made about how you put it together. And the reason I emphasize that is I’ll have clients say to me, oh, gosh, we have so much technical debt. We have, like, a million bugs in production. No, bugs are bugs. They’re not technical debt. Technical debt, that is much worse because usually you don’t know you have a problem with it until it’s endemic. It’s everywhere. Sean Weisbrot: Yeah. I think my CTO realized we had technical debt sooner than I did, and it wasn’t his fault. It was kind of my fault. And some of the bad hires that we made that were also my fault because I was the final decision maker on who we hire. Angela Druckman: Yeah, it really is, it’s something that accumulates over time and kind of a hockey stick curve where in the beginning, you don’t notice it, probably, or you notice little things here or there, but once you’re becoming very aware of it, it’s usually a massive problem. Probably the most infamous case of technical debt in computing is Y2K. Most like, you’re too young to know about Y2K. I work on a Y2K project. Sean Weisbrot: I resent that. I was 14 years old. Angela Druckman: I remember at the time, it used to bug me, where newscasters would talk about the Y2K bug. That was not a bug, people. We knew exactly what we were doing. So, here’s the deal. Back in the day, computer memory used to be very expensive, and you are constantly pressured. Don’t use so much of it. Don’t use so much. Well, one way you can cut down on memory is you store a date as a two-digit number instead of four. So, it’s 96, not 1996. And a whole bunch of us did that until someone said, you do know there’s going to be a problem with that? Yeah, I mean, during that time, there were billions and billions of dollars spent on Y2k cleanup because it was in every system. It was everywhere endemic, it was endemic. Sean Weisbrot: Do you think they solved it permanently? Like, when 2100 comes around, will there be another bug? Angela Druckman: It’s not a bug. People are doing it on purpose. That particular problem is solved. But there are other kinds of technical debt, too. Let’s give a nontechnical example, because technical debt can be in any system. Sometimes, I share this example with my class just to kind of convey that to them. So, for your listeners that are in America, I want you to think about if you’ve ever seen the television show, even just in passing, as you’re going through channels. If you’ve seen the television show Hoarders. Hoarding is a technical debt problem. Think about the definition. It’s a system that has weakness in it because of decisions that were made about how it was put together. So, the next time your listeners are flipping through channels and they see Hoarders, here’s a suggestion. Stop and watch it just for a few minutes. When you look at that dreadful house with things everywhere and it’s terribly sad, what you want to remember is there was a time when that house was clean, but what happened where there were a series of decisions made. So, one decision might have been, I’ve got this stack of 120 National Geographics. I don’t want to throw them away. Where should I store them? Maybe the decision is, well, for now, I’m going to store them in the hallway and I’ll find a permanent place later. And then now I’ve bought 75 boxes of macaroni and cheese. They won’t fit in the pantry. Where do I store them? Well, in the corner of the kitchen, but just for now, and I’ll find a permanent place later. Now, you multiply that by hundreds, maybe thousands of decisions and you get to what you see in the television show, which is that poor person can’t even get in their kitchen and there’s a dead cat on their sofa. Hoarding is a technical debt problem. Sean Weisbrot: My great uncle was a hoarder, and when he died in 2007, he was living in St. Augustine, which is like an hour drive from Gainesville, where I was living. So, my parents were living in Miami, and they drove up and I drove to the east to meet them. And I spent, like, three straight days just trying to clean I mean, you would not believe hundreds of black bags of things that are not trash stuffed into the bags. The garage was probably 5- 6ft high of just black bags. And that’s not to include the things inside the house that were on stacks. He didn’t have a will. Like, we found cash in the house lying around. We had to find the safety deposit boxes and the deeds. We had to find all this stuff in, all of that crap. And we went there several times and spent several days each time just trying to clean his freaking house. It was incredible. And I hated every second of it. Actually, no, I take that back. I love purging. Sorry. I enjoyed that. But it also sucks. Angela Druckman: Yeah. Systems like that let’s call your uncle’s house a system. They don’t get put together like that overnight. And that’s the thing that I want people to remember, is anyone decision. In my example, leaving the National Geographics in a stack, is that the worst thing in the world? No. Have we all left a stack of something somewhere and said, I’ll get back to that? Yes. It’s when it is multiplied by a thousand, and that’s in technical systems. That’s what happens in technical debt. It’s multiplied by millions sometimes. Sean Weisbrot: Yeah. I learned to not allow any stacks to pile up. I am so minimalist. I don’t think I have any paper or pens. I have a backpack and a duffel bag. That’s how I live. But then again, my mom is also starting to be a little bit of a hoarder. She’s got stacks of papers and their bills and stuff. Some are paid, some are unpaid, some are, like, magazines. I was like, the only reason it hasn’t gotten into, like, stacks your head high is because whenever I’m there, I purge it all. I’m sorry. This stuff is, like, from 2017. Come on. Why is it sitting here? Angela Druckman: Yeah. And I want to say something to your listeners. I am absolutely sensitive to true hoarding is also a mental illness. So, I’m not saying that isn’t the case, but I’m using it as an example of a physical manifestation of a system that was put together that, you know, it’s going to fail. It’s ultimately going to fail. Scrum can be used for many different things (49:58) Sean Weisbrot: Right. So, is there anything we haven’t covered yet that you’d like to talk about? Angela Druckman: Oh, my goodness. This is pretty much it. But I guess the one thing I would say is for your listeners that are small business, business people, I do think there’s a lot of potential for you to use this way of working, even if your business has absolutely nothing to do with technology, if you have limited resources, right. If you’re constantly dealing with emerging requirements, if you’ve got risk. This is a way to help a small business make the best use of their resources they can to be competitive with much, much bigger competitors. I hope people will give it a try. It’s a very powerful tool. Sean Weisbrot: It’s actually really cool you said that. And I like it because we have a marketing director and we’ve got a website designer and developer. And I saw the three of them adapting this kind of a system to their own use. And they went pretty deep in having Sprints and weekly calls and like, this is what we’re going to design this week, this is what we’re going to develop this week, and these are the goals and this is why. And they use story points and things like that as well. It’s incredible because they’re totally not a tech team and I didn’t tell them to do that. That was the thing that the marketing director wanted to do. So, for this other company, We Live to Build with the podcast and all that, I’ve recently hired two people. So, what do I do? I set up Sprints with them and I say, okay, so I do a weekly Sprint, not two weeks, because we’ve got specific content and things, we need to get ready. Okay? So, I’ll have a 20 minutes call with each of them on Monday morning. And I’ll say, here’s your Click Up list. This is the stuff you have. Do you have any questions for me about what you need to do? And as they get it all ready for review, I’ll go and review it and then say, okay, there’s a problem here. I’ve totally learned how to do this by watching them even, like, planning how to do a design scope. Like, I had to hire the designer from my start up to do a rebrand for my other company on like a private, kind of on the side things. And I saw my team doing like, design scoping and website mapping and all of this stuff I had never heard of. And they all use the Scrum method to plan it out. So, when I went to go hire him, I’m like, oh, I’m going to copy what they did because I’d never done it like that before. It’s like I’m totally learning how to be more organized with all this planning because of them. Angela Druckman: Absolutely. I really feel like it doesn’t surprise me at all that your technical people already knew Scrum. It’s pretty ubiquitous out there in tech. What I am excited to see is the rest of the world starting to use this approach because it’s just so effective. And once you start using it, it’s going to feel natural. You’re going to wonder why we ever work any other way. Like, it’s is what makes sense. Follow up with Angela (53:01) Sean Weisbrot: For sure. So, how can people follow up with you? Angela Druckman: They can go to the DruckmanCompany.com or AngelaDruckman.com either, when they go to the same place. And there you can find more about what we do. You can watch some of our videos, and you can sign up for classes as well. Sean Weisbrot: All right, great. So, thank you very much for your time and energy, Angela. I appreciate it. This is very exciting for me. I think Scrum is really cool. I’m glad I learned about it with you specifically. I think you’re a great teacher. You have a really great way of explaining things at a simple level. It’s really cool. So, don’t forget that entrepreneurship is marathon, not a sprint. And take care of yourself every day. Thank you, Angela. Angela Druckman: All right. Thank you, Sean. Nice to speak with you. Sean Weisbrot: You too. Thank you for staying with us until the end of this episode. We know that you’ll like the other two that are on the screen now. The one in the top right is the episode that we think you would benefit from listening to next the most, and the one beneath it is what YouTube believes is also a really good choice for you. So, thanks again for sticking with us, and we hope to see you on the next video.