EPISODE TRANSCRIPT
S03-E02 – Jon Fazzaro – Cannot Value the Work Until It Is Done and In Use
[00:00:00] Announcer Introduction
[00:00:31] Drew Podwal: Welcome to another episode of the agile for agile, this podcast, I’m super excited that you guys are listening today , Brad and I actually, we recorded this. I want to say. Towards the end of the summer. So it’s, it’s been on the shelves for a little bit now. but we got to sit down with an agile coach. Jon Fazzaro. Who coincidentally, overlaps our circles twice. I met him back about a year and a half ago. and Adam Weissbart’s agile mastery community group and i noticed that both Jon and brad were speaking at the same conferences often
[00:01:08] at the same exact time. And it turns out they didn’t actually know each other. And so I put them in touch and they wound up speaking at a conference and. So we carved out some time, put our heads together and came up with this great topic that you’ll be listening to in today’s episode.
[00:01:22] Jon’s got this great mantra that he’s been been using for awhile now. And it’s, we cannot value the work until it’s done and in use. And it’s a really great phrase, right? Because it’s true. We don’t actually know the value of the work until we finally finished it. It’s done. It’s been tested and customers are using it. So we’re going to revolve around that, topic today for a bit. I just want to call out, like later on in the conversation, we actually figure out not only does that apply to the work that our teams are doing in delivering value to customers. It also aligns pretty strongly with ethos that we as coaches. Need to have. In order to help our clients to see the pathway for their transformation, adoption of capabilities and an agile maturity. No two organizations are the same. And as a result, we don’t know the value of our coaching and our customers won’t realize the value of our coaching. Until we incrementally work with them. coach them through their agile maturity.
[00:02:24] So we’re glad you’re here.
[00:02:25] Pull up a chair, take a listen and let us know your thoughts.
[00:02:29] You can find us on the web at www dot Agile for Agilists dot com. Or you could email us at podcast at Agile for Agilists dot com.
[00:02:39] Also, we’ve got some pretty groovy looking new sparkly stickers that, that Brad. Created and designed using our logo. If you’d like some stickers, please reach out to us either by posting on LinkedIn or through email, and we’ll make sure to send you out some stickers.
[00:02:56] Jon Fazarro: I’ve been on teams that get being agile and on teams that don’t, and, you know, they’ll both tell you that they get agile and, you know, they’re, they’re the best at it or whatever, you know, their process is awesome. But, the ones that really get it, I was like, what is it about these teams?
[00:03:16] What’s different about these teams that’s not present on the ones that are struggling with this? And when I talk about struggling, I’m, I’m thinking of specifically the whole thing where, you know, this is, this is our process and, uh, it doesn’t say so in the good book of Scrum and so therefore we can’t do that other thing that you’re trying to get us to do.
[00:03:38] just the kind of rigid thinking that, everything stems from having the perfect process. and being inflexible in, in trying new things. What I find is, is missing there is that, that they, they have a faith in the work that’s not there in the teams that really get agility. And by faith, I mean, Well, the whole thing is we have to get as much work done in as little time as possible. And that’s how we succeed. Whereas, if you actually look at, the things spelled out in the Agile Manifesto, or even if you go back before then, to things that were being discussed in, , any of the lightweight processes, before that.
[00:04:19] really, there’s an underlying assumption. And I kind of got to this by asking, why? I would take an Agile practice and I would ask why. Why are we doing that? until I got to something that seemed to be common to all of, all of the practices that I tried it with.
[00:04:35] And it always came back to this one thing. Like, the work is not inherently valuable. We don’t know. And we, indeed, we can’t know. We cannot know how this is going to turn out ahead of time. And so the worst thing we could do is try to fit as much work into as short a time as possible, because what we’re doing every time we add more work is we’re adding more variables, more risk, more [00:05:00] unknown to the pile of things that are going to get validated when we hand them off to somebody who’s going to use
[00:05:08] Drew Podwal: What I’ve seen a lot of is that, that where teams falter on this is the value comes from the stakeholder is asking the work, This must be valuable because the stakeholder is asking us to do this. as opposed to recognizing that, all right, well, you know, we need to actually get some feedback from a customer, to understand how it’s valuable, why it’s valuable, what are the jobs to be done that are valuable here? and testing out that hypothesis. I often find though that it’s the tyranny of the urgent, , that gets in the way of… of being able to then slow the roll down on that and say, all right, we, we know that what the stakeholders are asking us to do is this big bohemoth thing, right?
[00:05:55] And we could trust them to say, well, they must know what it is that they’re asking for because they get paid more than us. You know, they’re, they come from the, the
[00:06:04] profit center side of the organization. what I’ve seen
[00:06:08] time and time again, and also my experience back before I was an Agilist, was that like, we would accept that mostly because we didn’t have a choice to not accept that, and that sure enough, three weeks in, a month in, another six months in, right? there’s new things that are being discovered about what it is that they want. And nobody’s ever paused for a second to say, well, what is our customer actually saying about this? Oh, they don’t have it yet? Well, how will we
[00:06:36] know, you know?
[00:06:37] Jon Fazarro: Yeah, I, I, um, and I forget where I heard it, but I heard it recently. It may have even been on a prior episode of this podcast, but it’s not scope creep. It’s, you know, it’s validated learning.
[00:06:48] Brad Nelson: I think the problem is we’re prioritizing work, not value. And it goes back to how stakeholders and leaders still have this mindset that work is inherently valuable and they have a productivity mindset as opposed to a value mindset, which is something I talk a lot about. Uh, but you also made me think of the cone of uncertainty, which is also something I teach almost every chance I can get where.
[00:07:17] You know, we know the least when it’s just an idea, we just throw it
[00:07:21] Jon Fazarro: Yeah. So how could you, how could you possibly do all of your planning when you know the least? How could you be successful that way? Yeah.
[00:07:27] Brad Nelson: Right. yeah, and furthermore, I teach, right, like the cone of uncertainty, it never touches. You never 100 percent know. Even in production, you don’t fully know, but there’s ways to try to figure it out. And as Marty Kagan says, it’s going to take several iterations. You’re not going to get it right the first time.
[00:07:46] Jon Fazarro: And that’s actually, that’s, uh, one of my mantras that I’ve started collecting is you’re not going to get it right the first time. And I find, I find that, that’s definitely, that is something I say maybe two or three times a week
[00:08:00] and there’s such a strong instinct, in all of us. Developers, uh, and, and There’s this
[00:08:12] There’s this instinct we have to get this right the first time. Then we’re not going to get a second chance. And it couldn’t be further from the truth in a medium like software.
[00:08:22] It’s right in the name that it’s soft,
[00:08:24] Drew Podwal: So I was listening to Alanis Morissette last night. I don’t, like, every now and then I get these really weird… like hankerings for musicians or songs And it usually gets triggered by something else, right? So I started on the pipeline because Sinead O’Connor died last week, right?
[00:08:45] and and so that kind of got me down this like rabbit hole But I was listening to the song you learn by Alanis Morissette Have you guys ever listened to that song and ever actually listened to the lyrics?
[00:08:57] Brad Nelson: I’m not sure. I don’t know all of Alanis
[00:09:00] Jon Fazarro: I remember it on
[00:09:01] Drew Podwal: straight up agile It’s straight up Agile, right? so let me read a couple of verses for you. I’m not
[00:09:08] going to sing it.
[00:09:09] yeah. you live, you learn. You love, you learn. You cry, you learn. You lose, you learn. You bleed, you learn. You scream, you learn. Right? It’s all about this
[00:09:17] learning process,
[00:09:19] and I, and I feel like that part of, learning the value of your work, right?
[00:09:24] They try to accelerate that by saying, don’t, don’t pay attention to the man behind the curtain, all right, just focus on what we’re asking. you guys to get done and just get it done. the idea of, of learning, like we learn the value, we learn how to communicate with each other better, We learn, um, how to move code along the CICD pipeline better, And if we just focus on getting the work done because somebody else has defined that it’s valuable for us, we’re missing out on the opportunity to, have software team that’s singing an Alanis Morissette song.
[00:09:59] Jon Fazarro: Do you know,[00:10:00]
[00:10:00] Brad Nelson: Hopefully keeping their clothes on
[00:10:02] Jon Fazarro: what comes to mind when you say that is, I’m imagining like a hard nosed sort of, uh, maybe middle management, director of IT type saying, yeah, that’s nice, but learning isn’t what we’re here to do. That’s not what you get paid for. We get paid for shipping software.
[00:10:19] We get paid for writing code. And, You know, I have to say, like, there’s obvious evidence that learning is good for business and propels us forward and indeed helps us to, like, ship the next thing. But there’s this devaluing of it at a cultural gut level, and I think, that that comes from, 20th century attitude of learning is what you do when you’re a child, when you’re in school.
[00:10:42] And, it’s a lot like, sort of a phased approach to delivering something. It’s a phased approach to delivering a whole person. Like, first we have the phase where they go to school and they learn. Then they’re done learning and we have the phase where they go and do. And if they have to learn in the middle of doing, that’s seen as a failure.
[00:11:01] That’s seen as a remedial. Things. Something went wrong in phase one, and now we have to correct it in phase two. That’s broken. And that’s, you know, that’s kind of this industrial shadow that hangs over the work we’re doing in this century now. But it was so baked into our culture that we don’t even see when it sneaks up and, causes these logical fallacies.
[00:11:25] In the work of software, where learning is valuable.
[00:11:28] Drew Podwal: Well, it’s project based thinking, right? It’s, you know, we build software as a project as opposed to realizing it’s a product. And one of the things that I’ve been noticing lately is I’ll hear Masters or product owners refer to their features as projects, and, and I call their attention to like, okay, what you’re building is a product.
[00:11:49] And it’s wonderful that you’re incrementing and iterating on that by having different projects come through the pipeline. to then be able to deliver new enhanced functionality. what would it be like if we called that a feature instead? Right? And how could we slice that feature so that we get early learning involved in that?
[00:12:07] I, I still think that’s a remnant of, of this project way of delivering software that… I don’t know, I’ve never seen it work and people always argue that like, Oh, well, what if we know everything we’re supposed to do, right? Shouldn’t it be a project then? It’s like, all right, well, show me when that actually has ever been true.
[00:12:25] That you, you know, everything that you’re supposed to do.
[00:12:28] Jon Fazarro: Yeah, that’s never happened. I mean, people have felt like that. and I’m sure, well, okay, I can’t say never, that’s not very scientific of me, but I’ve never seen it. I’ve never seen that happen, I’ve never heard of that happening, there’s always learning that, that explodes from the doing.
[00:12:46] Brad Nelson: Couldn’t agree more. but before we started, and you just touched on this now, your mantras. you have several mantras that you’ve kind of collected, created. can you explain to us, like, what is a mantra to you? And then is this like something that you
[00:13:02] promote other people doing? And then what are some of yours?
[00:13:05] Jon Fazarro: this is a, this is an idea I straight up stole from, uh, um, Joshua Kariefsky, his book that, came out earlier this year, Joy of Agility. He kind of organized, there’s, dozens of stories in, in this book, and he chose to organize them them into six, what he called mantras.
[00:13:25] one of the, you know, maybe one of them is, uh, be poised to adapt, or be quick but don’t hurry. And they weren’t, they weren’t necessarily things that he had come up with, but they were like, bits that he had collected and made sense in order to group the stories in his book. And I found, you know, not only just, you know, reading the book and, and learning his mantras that he had collected, but also realizing that I had a few of my own that I have been collecting kind of in the background.
[00:13:56] I didn’t think to call them mantras or anything yet. But I, I made a list of the things that I find myself saying a lot from, you know, from team to team or week to week. one of them that I mentioned earlier is stop trying to get it right the first time. You’re not going to. another one is, on the topic of, uh, working sustainably, take a break before you need a break.
[00:14:19] You know, most people take a break after they need a break. When you need a break, it’s too late. You’re already broken.
[00:14:27] Brad Nelson: Guilty as charged.
[00:14:30] Jon Fazarro: So, yeah, yeah, I’ve got, you know, a good, a good handful of those going. I don’t think I’ve got a, uh, a book yet, but, you know, I’ll leave that to Josh for now.
[00:14:39] Drew Podwal: was it we were talking to who said, uh, uh, they opened up their hard drive one day and they found a book that they had written. So they decided to publish it.
[00:14:47] Brad Nelson: That was Jason
[00:14:48] Drew Podwal: Yeah.
[00:14:49] Jon Fazarro: I’m gonna go look at my hard
[00:14:50] drive now.
[00:14:50] Drew Podwal: Like,
[00:14:51] Jon Fazarro: Be right
[00:14:52] Drew Podwal: yeah. Yeah.
[00:14:53] Brad Nelson: Yeah.
[00:14:55] Drew Podwal: Back when I was in the Navy, right?
[00:14:58] I had a side [00:15:00] job when I was living in Puerto Rico as a tattoo artist and what happened was I met a woman who owned one of the tattoo studios and and so she was like, Drew, it seems like you really are interested in this.
[00:15:12] If you get your own equipment, I’ll, I’ll let you work here. And so all my friends chipped in to get me, my, my tattoo equipment and, skipping to the end real quick. I was a terrible tattoo artist. I call myself a tattooist, but, and so she gave me a job there and I, I, I gave my friends free tattoos in exchange for, you know, buying me the equipment, so the first tattoo that I ever gave was to a friend of mine, Robert Rooney from, uh, in Long Island, we’re still good friends. but he wanted this tattoo on his chest. And so I’m sitting there, he’s laying down in the chair and I’ve got the tattoo machine running, but my hand is like frozen and I can’t get it to actually touch his chest.
[00:15:53] I just. Don’t have the the nerve in me to actually start like start down this path that I was like super interested in doing And so he looked at me for a second and he said, all right, stop the machine And he said I want you to breathe in I want you to breathe out, or I want you to breathe in deeper now I want you to breathe out.
[00:16:12] He said, now, now start. Start the machine. He said, I want you to breathe in again. hold it. And then he grabbed me by the shoulders and pulled his chest into the running tattoo needle. And he goes, drew, you’ve now made your first mistake. Now give me the rest of the tattoo. And that was. Part of my necessary part of my learning, to be able to, get over my yips that I had about putting a fast moving needle into somebody’s skin. Um, the same thing is true in software, right? You’ve got to break a few eggs to figure out, you’re not going to get it perfect the first time around.
[00:16:48] And so, like, let’s not. Try to get it perfect the first time around. Let’s know that in the first sprint we’re going to be making some mistakes. Let’s learn from those mistakes. Let’s keep that mindset going incrementally over time, and get to a place where Drew finally gave a good tattoo, which never happened.
[00:17:05] But,
[00:17:06] um,
[00:17:06] Jon Fazarro: story about, like, having
[00:17:08] to, just having to do something, having to begin and commit and not, get it all right the first time, because that involves so much, you know how much work in progress there is involved to get something right the first time? You have to juggle all the things all at once.
[00:17:24] That’s bananas.
[00:17:25] You’d never start. You’d never get anything done.
[00:17:28] Drew Podwal: yeah, and I didn’t know the value until I started actually really giving a tattoo, right? I didn’t I still don’t really know the value, but the value was it was really fun It was enjoyable and now I have a great story But um, but we have this in so many areas of our lives Like I bet you guys can each come up with at least one or two Similar sort of stories where there was something that you weren’t sure of how to do You thought you knew how to do it exactly, but maybe you didn’t get started because you weren’t sure how to actually get over the hurdle and start.
[00:17:58] And then when you did get over the hurdle, you know, you realize it’s not as difficult because you learned something about that first go around. And now it’s just become like this part of your life and become part of your persona. It’s a hobby or something like that, that you do every weekend or whatever, and we often don’t treat ourselves with that level of kindness, but when we do, great things happen. Right. I know you have kids, Jon, do you have kids?
[00:18:27] Jon Fazarro: I do.
[00:18:28] Drew Podwal: Yeah, like the idea of, helping your kids to make mistakes and make it feel comfortable for them to make mistakes as they grow and learn so that this way they can become better at things, as opposed to being so nervous to jump out onto the soccer field because their friends are going to
[00:18:46] laugh at them or whatever that might
[00:18:48] Jon Fazarro: Well, and I, you know, it’s funny you mentioned the
[00:18:49] parenting thing. The, that’s kind of what I consider my job as a parent to be. Is not to create a child. Not to shape and mold a person. You know, in this sort of, again, this industrial kind of Taylorist way, um, I can’t do any of those things. What I can do is create an environment where my child is going to make mistakes in a safe way, where they’re not going to get killed or sick or maimed, you know, before they’re done being in my care, and so that they can, you know, Make those mistakes, learn, and become
[00:19:24] better people for them.
[00:19:26] They’ve got to do the job of making the mistakes. I’m, I’m just responsible for the container.
[00:19:31] Drew Podwal: when you talked about having faith earlier, admittedly, I didn’t fully, you know, grok what you were getting at. But now that I’m thinking about it, the parenting perspective, if you provide your child with the right opportunities, , the light guidance and some boundaries and whatnot, you have faith that they will then Pick those things up and go forth into the world to then develop the interests that they want to develop, And some people have that level of faith in their kids and [00:20:00] trust, To be able to give them that freedom of space to go make a bunch of mistakes as they learn how to become better painters, better, Musicians or whatever that is, and other parents don’t have that faith. They have to be the helicopter parent that says, this is what you need to learn, how you need to learn it and where you need to be by any given point in time.
[00:20:22] And I think that that’s that project based waterfall mindset in the world that we’re talking about. uh, am I on track with how you were
[00:20:30] talking about faith before now that I put it that
[00:20:32] Jon Fazarro: It’s interesting, because it almost sounds like the opposite, but what I’m really talking about with faith is not, um, it, it, it can sound like the argument that I’m making that they have too much faith in the work. It almost sounds like it’s, it’s sort of a, almost an atheism argument about work, like you shouldn’t have faith.
[00:20:52] Right? But what I’m saying is the faith is misplaced. Um, when you’re talking about, like, they have these people, parents who have faith in their children to, you know, make mistakes and work it out and, you know, do their thing. That, I think, is appropriately placed faith. Even, you know, whether you say it’s the faith is in the child themselves or in just the process of humanity.
[00:21:18] Like, you have, you have faith that this thing is going to work itself out and you just have to keep people from dying. Um. Where the helicopter parent part of the analogy comes in, is that they have faith in a different thing. They have faith that they know what’s right. They know the next thing the child
[00:21:37] should do, and so it becomes this command and control, project based arrangement, where the child merely has to follow instructions, and the right result will come of that.
[00:21:45] They have faith in the work, not in the child.
[00:21:49] Drew Podwal: Oh,
[00:21:50] Jon Fazarro: And similarly,
[00:21:51] in an… In an Agile team, company, whatever, any kind of venture that’s truly Agile, you have faith, not in the work, not in the plan, but in the people that you’re asking it of.
[00:22:05] Drew Podwal: Got it. Yeah, that’s wild. I hadn’t considered it from that perspective. So I feel like,
[00:22:11] yeah.
[00:22:12] Jon Fazarro: Fantastic. Well, I
[00:22:13] better go home now, quit while I’m ahead.
[00:22:18] Brad Nelson: Yeah, I like that. I like that a lot. And I do think it’s true, focusing on the wrong thing. And, I reflected on this a lot. Like, why is this the case? Why is it seems so prevalent? because you don’t see that in startups, like startups inherently have to be more agile to survive, to make it.
[00:22:37] And I think that’s where like Eric Ries came up with the Lean Startup and where that became like, uh, like these major companies are now like trying to copy the startup mindset. the conclusion I’ve come to, and I’m curious if you have a different one, Jon, is that… These organizations have been this way for a very, sorry, my dog is very barky today.
[00:22:58] It’s been one of those days, so I’m rolling with it. Uh, I’m getting smiles
[00:23:02] Drew Podwal: Good for you, man. Go with
[00:23:04] Brad Nelson: Um, the conclusion that I’ve come to is that these organizations have been around so long that people are indoctrinated into these environments. And so all they’ve known is this system. And so they have belief in what they know. And so you, and you don’t have the owners anymore of these companies. You don’t really have anyone that is like, Hey, this is why I created this company, this is what I’m trying to do. So you just have this faith in this hierarchy and this system. And so you could have someone who’s worked their full life in this environment, never experienced Agile.
[00:23:41] And so they think Agile is new when in reality, it’s not. And so that’s kind of the conclusion I’ve come to is just like, we’re all products of our environment when it comes to this kind of mindset and the struggle,
[00:23:52] Drew Podwal: Well, I feel like it’s been since the eighties where we’ve had this, principle of how can we, drive up profits by doing more work with less people, and I think that that’s definitely a part of where it stems from as well. the people with the most money are the ones who make the strategy and make the plan.
[00:24:10] and then we give it to the people who make less money and, they. Should just follow our plan because we smarter And so why can’t you follow our plan?
[00:24:22] Jon Fazarro: Well, and this is, that’s played
[00:24:24] out right down to the way we visualize the organization. when I say visualize the organization, what image pops into your mind?
[00:24:31] Brad Nelson: a hierarchy.
[00:24:32] Jon Fazarro: Yeah,
[00:24:33] an org chart that is specifically an upside down tree, that splits as it goes down. What does that picture mean? That picture means the person at the top, they know everything there is to know about the work being done at this organization. but they don’t have enough hands.
[00:24:50] And so they have… Basically, they take their job and they split it in two or three pieces, like you do the finance, you do the operations, you do the whatever, and, and they hand [00:25:00] those jobs down to those people. Those people also don’t have enough hands, although they’re very good at, they know that area of that work, and then they split that job.
[00:25:07] And then those people split their jobs, and so on, until you get down to the, the bottom rung of, the employees, the leaf nodes. and those people simply, their job, in that picture. Their job is to come in, on time, and follow instructions given to them. Because the job has been broken down so finely that they don’t need any expertise to carry it out.
[00:25:30] They just need to follow the instructions of all the breakdown that happened above them. That, that’s what that picture means. And it’s bananas to me that, a modern, uh, reactive knowledge work organization would even think that that’s a good way to… Visualize themselves.
[00:25:49] Brad Nelson: that reminds me of a quote by Henry Ford and I love a lot of Ford’s quotes, but one of them is why is it every time I asked for a pair of hands, a brain comes
[00:25:57] attached.
[00:25:58] Jon Fazarro: Uh huh. Which was appropriate! That was appropriate for Henry Ford. Henry Ford was a genius who took, you know, Taylor’s ideas and applied them the right way for, I think, I believe, the first, he was the first person to do it. At scale, at least. And that’s what the
[00:26:13] world needed at that point. They needed a giant machine made out of people.
[00:26:18] And he was right to complain that the brain was attached because that fouled up his whole plan. And that was brilliant. But now, like that’s that we look at that quote a hundred years later and go, what an asshole, right? It’s like what why does he want to strip the humanity out of out of people? Well, of course he wanted to strip that he was true.
[00:26:35] He was building a machine. He wasn’t building an organism.
[00:26:39] Drew Podwal: Yeah, well, you know I just was at a conference a couple of months back where they were talking about like one of the things that really set Henry Ford aside was His vision for what he was trying to create and I’m gonna butcher it was something about like, you know every Household in America should have a vehicle, should be able to afford a vehicle to be able to drive the great parkways of the United States and so on and so forth, and then at the end he said as long as it’s black, um,
[00:27:08] but um,
[00:27:09] Jon Fazarro: Talk about an MVP.
[00:27:10] Drew Podwal: Yeah,
[00:27:12] Jon Fazarro: That’s how
[00:27:12] you limit scope.
[00:27:13] Drew Podwal: well, you know, I’m not against the idea of hierarchy, right?
[00:27:17] I’m just against the idea of management principles like if you have hierarchy that’s based upon leadership principles like actual true Leadership principles not not corporate America modern, you know, I’m a leader principles, then I think that’s okay, right? Because, you have to respect that there’s a brain on either side of the hierarchy, and as a leader, you, honor that there’s a brain on the, the leaf nodes, and you ask the leaf nodes, like, what do you need? what can I do to help you out? so I’m not against the idea of hierarchies so much as long as it’s, Got bi directional communication, bi directional trust, bi directional respect, and things like that.
[00:28:05] being handed, a project to work on, even if somebody write, writes an epic and breaks it down into features and then hands you features, say here that they’re, if they’re all written, do this, In this order. that’s the management principle getting in the way of innovation, quality, faster cycles of learning. and so that to me is, one of the key distinctions, not specifically the hierarchy, right? Because you can have hierarchies, In a healthy way, the other side of that coin is things like, holocracies, right?
[00:28:38] Which there’s like no hierarchies at all. And I think that that’s a wonderful thing if your company can adopt those kinds of ways of working with one another. I don’t see too many companies that I’ve been with in the United States that’s ready to take that plunge to say, you know, we’re all at the same level in this
[00:28:57] company.
[00:28:58] Jon Fazarro: it’s interesting when you, there are so many different ways than upside down trees to organize a group of people, and I think part of the hesitancy of, you know, embracing something like a holacracy or some other, you know, non upside down tree type organizational structure is that, this is the, the top down structure was so So inculcated into how we were taught to think about work. It’s, it’s how a school is organized, right? There’s a one teacher at the front of the classroom and everybody faces that person and follows their instructions and that teacher reports to an administrator or a principal of some kind and then that, you know, it’s a factory all the way up. And so those, those, it’s like there’s, it’s the water and we’re fish.
[00:29:49] There’s, there is no to where companies that try alternative structures to that just say, they say things like, we’re a flat [00:30:00] organization, we don’t have an org chart, but really there totally is a hierarchy, there totally is an org chart, nobody’s just, they just haven’t written it down, and it’s secret, and it’s different in everybody’s head, and then It’s It’s chaotic. I’m not saying that nobody’s made a holacracy work, but I’m saying that that’s probably the reason there’s either hesitancy or failure in implementing some, you know, a structure like that
[00:30:23] Drew Podwal: yeah, we had,
[00:30:24] Jon Fazarro: hard to break free
[00:30:25] of the default.
[00:30:26] Drew Podwal: we had a guest on an Agile coach who was a former, teacher I think the public school systems, if I recall correctly, her name is Patty Eluskowitz. I her whole thing that she was talking about is that, you know, we learn these hierarchies from grade school and elementary school and, you know, and it makes sense that that carries on into the working world as a result of that.
[00:30:48] It’s interesting that you bring that up as well because that was her that was her whole platform on this episode Which I thought was really cool, and I’d never thought about it from that perspective
[00:30:58] Brad Nelson: Yeah. I, I can’t help but call out the human side of it as well. Thinking back to even myself when I first became a scrum master and I was no longer responsible for the work. I was no longer responsible for sharing my fantastic ideas of how we’re going to accomplish this that no one else could possibly have.
[00:31:20] And I think that there is a bit of that. Human nature is like, I’ve worked really hard to get this executive position. I deserve it. And so I’m going to keep it. If you get rid of it, then I’ve worked for nothing.
[00:31:35] Jon Fazarro: Yeah, there’s so, so many, you know, the logical fallacies, a good handful of them come to mind in, in this whole discussion. We’ve got, um, appeal to authority in, in terms of having faith in the work or faith in what somebody tells you is the work. Um, and that one is definitely, there’s a bit of sunk cost fallacy.
[00:31:54] Well, I don’t know if it’s, is that, that’s not right. Is it the sunk cost fallacy of like, I’m attached to what got me here. And so therefore I have to keep doing it.
[00:32:03] Brad Nelson: I could see that argument. Yeah, I could see that correlation.
[00:32:07] Drew Podwal: yeah, what works somewhere else is gonna work here and so let’s keep that going
[00:32:11] Brad Nelson: another one. And you touched on that early, Jon, which I loved, because I think that’s a trap that Agilists fall into a lot. I
[00:32:19] Drew Podwal: Yeah,
[00:32:20] Brad Nelson: I’ve seen good. Well, most of them actually haven’t seen good, which is my other argument about it, but, uh, you know, hypothetically I’ve seen good, or I’ve seen it this way.
[00:32:30] So every other organization has to work this way.
[00:32:33] Jon Fazarro: yeah. And, well, and they’re all chasing the dragon of, of that, that one team that was so good that one time.
[00:32:39] Drew Podwal: was that a Steely Dan reference or was that just
[00:32:41] a euphemism that you used?
[00:32:43] Jon Fazarro: I believe that’s a drug use reference. Chasing the drug.
[00:32:47] Drew Podwal: a it’s a quote from also Time out of mind by Steely Dan the chorus is tonight
[00:32:53] when I chase the dragon
[00:32:55] Jon Fazarro: Dude, I’m big on Steely Dan, but
[00:32:56] I have not exhausted their catalog. I’ll have to look that one up.
[00:32:59] Drew Podwal: Yeah, that’s my ridiculous, like, area of music that I spend way too much time involved in, but, we’ve talked a lot about, like, why the problem of not being able to, , get a better understanding of our, the value of work when it’s done, is upstream, right? Yeah. Let’s flip the coin around, right?
[00:33:22] And think about those times where, in the teams, The people are in the trenches, because it’s not just leadership, there’s a lot of teams that just kind of want to be given work. And they want to do their job, and when I’ve coached them to say, don’t you guys want to get some customer value and get a better understanding of, of what it is that you should be building incrementally.
[00:33:45] And, and they’re all like, look at me like with like blank stares and it’s like, no, we, we get blocks, we break those blocks down and then we build them up again into the features. Why do we need to talk to the
[00:33:59] customer? Um,
[00:34:01] Jon Fazarro: the
[00:34:01] work’s all here. It’s all, it’s, yeah. No, and, and
[00:34:04] I’m not sure if this is what you’re getting at, but this is what you’re making my brain noodles do. the thing that a lot of, a lot of folks, both in leadership and in the trenches and teams don’t seem to connect is that it’s Agile turtles all the way down.
[00:34:18] This stuff is fractal. so if we take that core principle of. we cannot know the value of our work until it’s done and in use. That matters at the sprint level, that matters at the, I suppose, the quarter and the strategic level, but it also matters at the day level, at the hour level, and at the line of code level. And, and this is maybe, this is where my, you know, my technical agility kicks in. This is, this is what test driven development is about. Are you guys familiar with test driven development as a
[00:34:54] Brad Nelson: We are,
[00:34:54] but
[00:34:54] why don’t you
[00:34:55] explain it for our listeners to
[00:34:56] Jon Fazarro: I will, sure,
[00:34:57] sure. So test driven development is sort of this, [00:35:00] what traditional developers would look at as this is an ass backwards way to write code, but, what you do in test driven development when you’re ready to change the code, the first thing you do is you write a test, for the thing you want the code to do.
[00:35:14] And of course that test, when you run it, it’s going to fail because the code doesn’t do that yet. And so you use that failure as your leverage to go write, enough code to make it pass. And then, once it passes, once it works, then you refactor, you clean, clear up the code and, and make it easy to work with.
[00:35:31] And then you go and write another test. And this is, it sounds bananas, it sounds slow, it sounds weird that you would write a test for something you haven’t even built yet. but it’s, it’s more like, it makes a lot more sense if you think about it as the scientific method. I have a hypothesis, the test, that fails.
[00:35:52] and then I carry out an experiment, the line of code that’s supposed to make it pass, and then I run the experiment, I run the tests, and it either passes or it doesn’t, and then I refine my hypothesis, and once that’s, you know, that part is proven, I move on to the next failing hypothesis. And you just, that, that’s the fractal nature of agility that I’m talking about here, is that we don’t even have faith in a line of code.
[00:36:20] We start with by doubting that line of code by writing that failing test and it has to prove itself Before we move on to the next one.
[00:36:29] Brad Nelson: I liked your explanation. I want to be stealing some of that. Um, I, I don’t remember if it was Kent Beck I read it from, or maybe it was even Joshua, uh, Kuriewski, called it red green
[00:36:43] Jon Fazarro: Yeah, that’s it. That’s pretty common It was likely Kent because he invented TDD, but that yeah, the rest of
[00:36:50] us are just you know, hanging on his coattails
[00:36:52] Brad Nelson: yeah, he did have an extreme one he came up with a few years ago. I don’t know if you read it. He shared it on social media, where it was like, if the test fails, it deletes all the code and I
[00:37:01] have to start over.
[00:37:02] Jon Fazarro: Yeah, I was I was talking to my friend my friend Stephen Baker actually earlier this afternoon about TCR test and commit or revert and he’s He actually, uh, he, he thinks he might’ve been part of that, uh, that conversation with Kent because he knows Kent and, uh, and they were, they were talking about it, you know, and once, once you give something a name, it’s real.
[00:37:25] So or an acronym in this case, an initialism. Not technically, did you guys know it’s not technically, technically in a, an acronym unless it makes a word?
[00:37:33] Brad Nelson: Yes, I have a friend who, who reminds me constantly
[00:37:37] when I use the wrong word.
[00:37:39] Jon Fazarro: I’ve been, I’ve been so struck by, uh, by pedantry on that one from other people.
[00:37:44] so yeah,
[00:37:44] TCR, so that’s this notion that you would test, and if the test passes, that commits that part of the code, and then, but if you make the test fail, it erases everything you’ve done. That’s this, that’s a whole other level of not having faith in your work.
[00:38:02] Drew Podwal: that’s, uh, that’s like, uh, who wants to be a millionaire? Where you now get the chance to go for the million dollars, but if you lose, you lose it all.
[00:38:11] Jon Fazarro: yeah, yeah, it’s a little bit, it’s a little bit double jeopardy, but what that, it’s obviously, it’s a crazy idea if you work in long stretches. If you type for an hour, and then run the test. and it deletes an hour’s worth of work, that’s terrible. Don’t do that. But, what that
[00:38:30] is, that mechanism is meant to force you to take smaller steps.
[00:38:36] To take tiny tiny little baby steps toward the goal. And what’s remarkable is how slow that feels and how fast it is.
[00:38:45] Drew Podwal: You know, I’ve brought TDD concepts, to many organizations as a coach and, um, Sometimes they love it, they get it right away, it makes perfect sense, right? But there’s two reasons why I’ve always found organizations don’t like TDD. The first is from a developer perspective, right? On organizations where your team has developers and testers. Nine times out of ten, the testers are looked at as second class citizens. They’re, you’re a tester because you… Become a developer, right? So we’re better than you and the idea of putting the test first Really has to honor that we’re all on equal planes here, and so that’s one reason why I found To be something that gets in the way of of people adopting TDD The other is that like with TDD, especially if you use like Gherkin Syntax to write the stories and you’re using cucumber for like automated testing and things like that.
[00:39:48] , what that means is that as a product owner, you get exactly what you’re asking for. And what I found is that many product owners don’t like [00:40:00] that, ? Because what that also means is if I forgot to ask for something, then I’m not gonna get it. and so the idea of the product owner writing the test, case in the form of a gerkin syntax, and talking about that with the developers for refinement and better understanding, it forces the product owner to really be a truly, detail oriented and, precise, voice of the customer, right? They get a little, lazy or lackadaisical and forgot that one thing, Oh, yeah, we need that too, And so I find that product owners Who don’t have developer backgrounds if they have developer backgrounds, I don’t that it’s usually golden It’s easy to do but the ones that don’t have developer backgrounds who are used to being somewhat of an exalted member of the team because again, they’re on the Profit Center side of the house, they don’t like the idea of, of test driven development
[00:40:59] Jon Fazarro: I want to pick a bone with what you’re, what you’re describing, though. And…
[00:41:07] I’m sure that there are really healthy arrangements, um, on a team where somebody, a product manager, product owner does write Gherkin themselves. And then there’s this really nice, precise level of communication between that person and the people writing the code.
[00:41:25] But that really, to me, has a great danger. of devolving into, I’m the manager who gives you the broken down tasks and you just carry them out. And if that doesn’t work right, that’s my fault for not having specified the instructions to the machine correctly. And they become like one, like there’s now one programmer on that team and several typists.
[00:41:52] Drew Podwal: I’m not suggesting that that should replace team refinement, right? Like, so for instance, in a project that I’ve been working on lately that is actually a project, right? I’ve been trying to bring some Agile to it. I’ve been writing all of the requirements, And I’m using the word requirements as, given when then, Gherkin style syntax, right?
[00:42:11] And, and I’m doing it that way, typically in a very bloated way, and I’ve… Worked with my developer to have him push back and say let’s slice this this way, Or hey, I feel like you’ve created the happy path really well, But what happens when it’s in this condition? And so I don’t think that having a product owner writing in that style of syntax is inherently a problem as long as there’s still a, strong emphasis and value placed on card clarity and conversation that happens in a refinement session.
[00:42:51] Jon Fazarro: Yeah, no, I don’t think it’s inherent. I think, uh, in my experience,
[00:42:57] Drew Podwal: Okay. that’s…
[00:42:58] Jon Fazarro: That
[00:42:58] maybe is how
[00:42:59] it would, that’s how it would manifest coupled with people’s instinct to want to show up on time and follow instructions and that be the extent of their commitment to the team. it’s a
[00:43:09] much better arrangement to me, in general, to have somebody who’s a product owner or, head thinker of what the product needs, whatever that role is for you and your team.
[00:43:22] If that person focuses so much more on… Describing the problem, rather than detailing the solution. Then what you’re gonna get is all the brains on the team that are being paid for. all of those brains are going to say, we could do it this way, we could do it that way, and they could have maybe, one thing that the team I’m with right now does really well, was they have this notion of bake offs, When there’s more than one solution in the room, we do both. We timebox it, of course, but we do both things. And then at the end of the time box, we go, okay, which one is better? And then we go with that.
[00:43:57] Drew Podwal: Yeah.
[00:43:58] Jon Fazarro: There’s not a lot of,
[00:43:59] there’s not pre judging one another’s ideas. There’s just, let’s, let’s do it and find out.
[00:44:05] Drew Podwal: Yeah. I fully respect where you’re coming from. I definitely feel like I’ve seen that as well. in the absence of an actual like customer journey map. that that condition is probably way more likely as well.
[00:44:15] Brad Nelson: So what I’m hearing is that Jon’s saying product Gherkin. And that fits my narrative, so I’m running with that for all eternity now. Because as a product manager, who has a technical background, I absolutely hate writing in Gherkin. So don’t run me over Agilists, don’t run me over product managers, but to me, it is not human.
[00:44:38] Because it’s written for a machine to run. Right? And so to me, I struggle with it because, given when then, Reminds you of like the old like IEEE standard of the system does this, now the system does this, and it just makes me want to quit. I just want to like,
[00:44:54] throw in the towel and be like, nope, I’m done.
[00:44:56] Jon Fazarro: I, yeah, I’m, you know what? I’m with both of you in, in [00:45:00] different parts of this, I think. because there’s, yeah, if you try to do everything in Gherkin, or for that matter, IEEE, you know, the system shell nonsense. you’re going to suck all the humanity out of the work and you’re probably going to confuse more people than you help.
[00:45:14] But where those things, those syntaxes really shine is when you really, really need to have precision in your language and be clear about something that’s kind of hairy and complicated, like it has to work this way. and that’s because the laws of physics over here or something like that.
[00:45:30] And in those cases, that’s the appropriate tool. But in most cases, it’s like, okay, you got to talk about the customer as if they’re a human person or the, you know, the user of the system and they have this human problem. one thing that I tell, I tell teams to do is when they receive, a requirement in whatever form, you know, I use that word loosely.
[00:45:52] So like a user story or a task or an actual requirements document, whatever, when, when they receive something telling the, this is what we need to build. Ask. Why? If it’s not already immediately apparent in the thing you’ve received, ask why and don’t stop asking why until you get a reason that’s not about software.
[00:46:13] Drew Podwal: yeah,
[00:46:13] Jon Fazarro: need to build this, we
[00:46:14] need to build this endpoint so that the front end team can, can access this data.
[00:46:19] Drew Podwal: Why?
[00:46:21] Jon Fazarro: Why? So that, well, so that the front end team can access this data. What are you talking about? Why? And so you, you see where I’m getting, like in, especially in a
[00:46:31] larger organization, you run into these brick walls where Nobody in the room knows why, but we just know we have to do it, and everybody has faith that we have to do it, and because nobody has appropriately attached the human reason for the work to the work itself.
[00:46:46] Drew Podwal: And you know, where I see that come up the most is when there’s an effort to sunset one platform and stand up another one, and the go forward strategy is let’s just make the new platform with the new architectural principles and we’ll just use the same logic that the old platform had, And usually it’s because it’s in absence of a product manager or stakeholders who are willing to lean in and talk about things. But, you know, in those cases, what I always find is that like a month into them, three months into them, somebody voices, Oh, but you know what? We don’t. Um, we’ve actually created an outside system to do a workaround that enables us to then, you know, figure out that value.
[00:47:34] So we, we now want you to do it like this, right?
[00:47:37] Jon Fazarro: outside system, you mean Excel
[00:47:38] Drew Podwal: Excel or, yeah. like that to me is a great example why, all right, why would We think we know what we need to do, right? That must mean we know the value of what we’re trying to deliver. because somebody asked us to sunset this platform and stand up a new one.
[00:47:55] that’s the furthest thing from the truth. And people just are either unaware of that or aren’t able to challenge the status quo to say, Hey, we probably need to break this thing down, right? Sure, we could look at the as is system as a source of reference to break it down. but what are the flows that we’re trying to hit in this system?
[00:48:16] Who are the personas that the system serves? And, Where would be a great place to start for an MVP in this new platform? as opposed to a project based binary, either it works for everything that the, business stakeholders need or it doesn’t,
[00:48:31] Brad Nelson: I want to circle way back to the beginning because there’s something I’ve been kind of noodling on because it’s near and dear to my heart. And you talked about Jon. Good ways to code and bad ways to code.
[00:48:44] Jon Fazarro: Ooh.
[00:48:45] Brad Nelson: And a lot of times we talk about technical agility, things like TDD come up, things like CI CD pipelines come up, but I, I feel like there’s this huge gap when it comes to training people, and I have a whole talk dedicated to, to this kind of notion too, in that like we think we just have to add what have been classified as DevOps tools and now we’ve checked the box of our technical agility. However, like the code itself has to change the code, the way we write code has to change. And I’m curious, how prevalent is that for you that you see that it’s like, you know, the code is really the bottleneck is the barrier to true agility.
[00:49:27] And like, how do you move forward with
[00:49:29] that
[00:49:29] sort of situation?
[00:49:31] Jon Fazarro: All the time. and, it really does come down to, can we change this confidently, safely, and quickly? And with… 90 percent of the code out there, at least that I’ve seen and I, you know, uh, I’ve seen a fair, a fair amount of code, most of it, the answer is no, we cannot do that. And so bringing in, you know, something, like safe or like scrum [00:50:00] or, you know, whatever outward framework of, uh, of agility that you want, you can grind away at that all you want, but the code.
[00:50:10] and the team are not going to be able to keep up with that until you have the technical practices in there to support it.
[00:50:19] Drew Podwal: When
[00:50:19] Jon Fazarro: have to be able to, yeah,
[00:50:20] go
[00:50:21] Drew Podwal: when you say code, do you mean architecture or do you mean code as well?
[00:50:25] Jon Fazarro: That’s the same thing. architecture is a big hairy word. but it’s important to understand that that’s, you know, a lot of people take it to mean these are the platforms and the tools that your team uses. But architecture, it could, it could include those things. But the most important word.
[00:50:42] that you could associate with software architecture is boundaries. And boundaries happen at the, the higher system level. Like this app talks to this app, or this process talks to this process, this machine talks to this machine. But they also happen in the code itself. This function calls that function.
[00:51:00] This class, depends on that class. And those, those boundaries, at the code level are some of the most important things. in, in the, the concept of software architecture and a clear and agile architecture, a soft architecture that, that allows, quick, safe changes. And that’s, those are the most overlooked aspects of, of software architecture,
[00:51:28] Brad Nelson: Yeah, Uncle Bob has an amazing video on his site. It’s like cleancoders. org or something like that. That’s free. Anyone can watch it for free. A lot of this stuff you have to pay for, but it’s a fundamental, beginner’s talk
[00:51:43] on clean code. And he shows a little bit of code, but I used to encourage, like, every scrum master, every, well, developer, of course, like, anyone I came across, like, watch this one video because he explains it so well, the importance of, like, simplicity and clean code and And I think once people understand that, they can wrap their minds around like, Okay, we have some serious tech debt that we didn’t even know we had.
[00:52:10] Jon Fazarro: yeah, he does a great job of, of explaining that. And there are so, there are so many, there’s so much good stuff on this out there. If you just. If you know what to look for, if you take interest in learning about this, it’s a deep rabbit hole, but I promise it’s worth it. one thing you said that actually, triggered me was the word simplicity.
[00:52:31] Or, making the code, clear and simple. And, people who haven’t seen. good, clear code before we’ll say things like, well, we can’t do that here because our code is complicated. Our code is complex. We do big complex things. And, antibodies go up.
[00:52:50] but that’s only, it’s only because they haven’t, they just haven’t learned what their code would look like in a well architected form that makes it simple. The complexity in your code is not inherent. And that’s what good architecture does, is it takes complex code and makes it simple. Things like, a switch statement It’s really an expression of polymorphism hiding in a complicated expression.
[00:53:17] Like, if there’s five different paths that this code could go through based on maybe a type of something, then what you have is five different classes, potentially that inherit from a class. Inheritance isn’t that great, let’s just make five different classes that sort of have the same interface, and substitute them in for each other, rather than having this long and winding road, in a method as long as your arm.
[00:53:40] Brad Nelson: Are you a microservices guy? Or monolithic? Or somewhere in
[00:53:44] between?
[00:53:45] Jon Fazarro: I think it would be a very big mistake to associate a large system architecture pattern with my identity.
[00:53:53] Brad Nelson: Well,
[00:53:54] Jon Fazarro: I think, because, and that’s
[00:53:55] inherently not very, not very agile, that’s not very soft. So what I would say on the subject of microservices, is you start with the assumption that you don’t need them.
[00:54:06] and start building your. Start building your monolith, take good care of it, make it modular, keep the, keep the code clear, and keep refactoring it, and when you encounter that problem that says, Hey, this one part of the system really needs to scale, break it out, make it its own process, put it in the cloud, make it a microservice.
[00:54:29] You ain’t gonna need it.
[00:54:30] Brad Nelson: I love it. Yeah. Yeah. DHH just put out an article like the return of the monoliths or
[00:54:36] Jon Fazarro: Yeah, yeah.
[00:54:37] Brad Nelson: it was really fascinating.
[00:54:38] Jon Fazarro: I did, I did see that one. It was a good, he’s good at, at like deflating people and their, and their bullshit, isn’t he? He
[00:54:45] Brad Nelson: Yes.
[00:54:46] Jon Fazarro: comes with plenty of his own
[00:54:47] too,
[00:54:47] but…
[00:54:48] Brad Nelson: Yeah. I don’t always agree with them, but he gets me thinking and that’s what I love about them.
[00:54:53] Drew Podwal: Yeah, you know, I feel like everything comes in cycles, right? Every few years, there’s always something that was like inherent to who we were [00:55:00] as Agilists that’s no longer, embraced. the thing that comes to mind the soup du jour today is, methodologies are bad, right?
[00:55:07] Um, all methodologies and, you know, and that, um, The manifesto is actually no longer relevant anymore. What we really need to focus on is meeting teams where they are and, and helping them to scale and grow. and I get kind of what they’re saying there, I get it because it’s like, you know, I can’t fit into my high school genes anymore.
[00:55:27] And so why should I try? although a few years ago, I was still able to fit into my Navy uniform and I’m not
[00:55:32] anymore. But, um,
[00:55:34] Jon Fazarro: Back in the Alanis Morissette days?
[00:55:35] Drew Podwal: in my Alanis Morissette days when I had, I used to have a rat tail, I was talking to somebody about that the other day. Did you ever, you guys ever had a rat tail?
[00:55:42] Jon Fazarro: I did in, in
[00:55:43] seventh grade when I was my youngest son’s
[00:55:45] age. I had a, I
[00:55:47] did have a rat tail.
[00:55:48] Brad Nelson: Oh man. So I’m the, I’m the one
[00:55:51] missing out apparently.
[00:55:52] Jon Fazarro: You should grow one. Just, uh, you know, gotta try everything once.
[00:55:58] But I think, and, and
[00:55:59] Drew, the problem, the underlying problem, uh, where everything, you know, comes around again, it’s all because really the underlying problem is that nothing works and we’re all going to hell. So, we just gotta keep trying the next thing.
[00:56:13] Drew Podwal: yeah, yeah, you know that there’s a lot of truth to that, you know, just just keep trying just keep, Throwing the spaghetti against the wall seeing which which pieces stick, and I think
[00:56:22] Jon Fazarro: a
[00:56:22] technical Agilist, I’m inherently allergic to your spaghetti metaphor, but
[00:56:27] Drew Podwal: Well, no, I think it gets right back to, the topic that we were talking about, right? Knowing the value, until it’s done and in use, right? Knowing the value of any sort of principle or process that we decide to adopt
[00:56:40] cannot actually be understood until we
[00:56:43] put it into
[00:56:43] practice.
[00:56:44] Jon Fazarro: this applies this applies as you say, methodologies falling out of fashion. This applies to methodologies. We cannot know the value or the impact to the effectiveness of a methodology, until we’re using it in a specific context with, this specific problem. and you guys may bristle at this, but this is where I have a problem with Scrum, specifically.
[00:57:06] Because, and, and I pick on Scrum in the same way that hackers picked on Windows in the 90s, it’s because it’s, this is the one that everybody has. there’s this, again, there’s a sort of appeal to authority in the concept of the Scrum Guide being the be all and end all of how we do things, and, or at least, when people treat it like that. And… It’s sort of assumed that if we follow these rules, if we play this game, that everything’s going to be okay, which is ironically not terribly empirical. That’s a,
[00:57:38] Brad Nelson: Yeah, you know, we’re not the Scrum for Scrummers podcast, uh,
[00:57:43] Drew Podwal: And
[00:57:43] that’s true. We, we,
[00:57:45] Jon Fazarro: that’s a
[00:57:45] Drew Podwal: there was Scrum in one of our original titles when we were bouncing around ideas and Brad specifically stated, like, we, we don’t want to lock ourselves into Scrum and it, it made a lot of sense. And so we didn’t.
[00:57:56] Brad Nelson: yeah, and the funny thing is that we’ve had more conversations against Scrum than for, I think at this point in our, you know, 20 some episodes so far, and that’s not to say that Scrum doesn’t have a time and place. I’m definitely not anti Scrum, but I do think that it goes a little bit with the fad right now where we’re all kind of burned out on the frameworks.
[00:58:18] Jon Fazarro: Yeah.
[00:58:19] Brad Nelson: But it’s also, you know, as we mature, we realize there isn’t a one size fits all.
[00:58:25] Drew Podwal: Yeah, but so I want to take a counterpoint on that because I would say there’s I’m not just there’s nothing bad about scrum Like I think scrum is great. And I think it can work really well I find that nine times out of ten if somebody says we hate scrum, Whatever their reason for hating scrum is not actually in the scrum guide.
[00:58:45] It’s just they think that that’s part of scrum, right?
[00:58:49] and and so like, you know, I love the idea of the role of Scrum Master. I love the idea of a role of a product owner, and I love the idea of a small team, and I, I love the idea of, of creating regularity within your cycles. I think that, you know, regularity within sprints and regularity within certain types of Scrum events have a lot of value to them.
[00:59:14] beyond that, Scrum doesn’t say a whole lot, right? And so, most of the time I find when people say they don’t like Scrum, it has nothing to do with Scrum. It’s just a bastardized interpretation of, you know, what someone told
[00:59:28] them that Scrum is, you
[00:59:29] know?
[00:59:30] Jon Fazarro: Now that’s a terribly good point because I agree with you, Scrum can work very well. Um, and
[00:59:38] you, you bring up the notion of like Scrum isn’t specific on a lot of things in, in its definition. And that’s one of the places where teams get into trouble because, they take it one way or the other too far.
[00:59:52] Like, the official reason for this is that Scrum is silent. When Scrum is, as they say, silent on something, it means you can do whatever you want in that [01:00:00] area, in that area. We’ll do what works for you. Scrum is not telling you not to do it. but, I think a lot of folks get into trouble where…
[01:00:08] Where they say, well, Scrum doesn’t tell us to do this, and so therefore we should not. And, you know, it’s sort of a, they, they, don’t do it. Or, as, you know, the other, and the other problem being that people affiliate things like, uh, story points. Or using stories with
[01:00:23] Scrum that are not part of that
[01:00:26] Brad Nelson: I, I totally agree with that sentiment. I would, for me, I would say the biggest challenge of Scrum is that, you know, it’s the number one framework, like in the world when, when we’re talking about Agile, it’s like, I don’t remember over like. 80 percent of organizations are doing something Scrum like, like they’re taking from the Scrum Guide, and like 50 percent are trying to truly be Scrum.
[01:00:51] I don’t know if I’ve ever gone into an organization that I would say is actually doing Scrum. Like, fully empowered product owners, fully empowered teams, self managing teams. I’ve never been in that situation, and so my qualm with Scrum is that I don’t think it’s realistic.
[01:01:08] Drew Podwal: I I don’t think it scales very well either. And I think that most companies, can’t operate with like two or three scrum teams, they need to have way more technologists to move the amount of code to, to increment the value within the products that they’re, you know, creating, whether they’re back office systems or products that are being sold to end users.
[01:01:33] I think that. the idea, like, you know, scaling is like, yes, you definitely shouldn’t try to scale first, But I think that we have to figure out ways to operate at scale, right? Um, we don’t have enough info around scrum with scrum in the scrum guide To be able to then figure out ways to scale that out without looking for other, you know Tried and true ideas for how to
[01:02:03] scale.
[01:02:04] Jon Fazarro: Let’s talk about scale for a second.
[01:02:05] Drew Podwal: Sure.
[01:02:06] Brad Nelson: Go ahead, Jon.
[01:02:08] Jon Fazarro: you talking about, when you say, when you talk about scale, are you talking about? scale in terms of the size of the team or scale in terms of the capacity of the system we’re building, which scaling are we,
[01:02:21] Drew Podwal: the, The,
[01:02:22] capacity of work that can flow through the value stream, right?
[01:02:27] That if you trace out the value stream, in an accurate sort of way, we realize that, there’s a lot of overlapping areas. There’s a lot of, you know, dependencies across multiple, technology units. And they have to figure out a way to dance.
[01:02:44] in concert with one another, and without some methodology that, and maybe let’s forget the word scale, right? Let’s put it in there, collaborate, right? Let’s forget I used the word scale. We’re an organization that has greater need for collaboration because they’re building far more volume of, code to support their products back office and, and customer facing. We need a way for organizations to be able to collaborate better.
[01:03:21] Jon Fazarro: I think there’s a, there’s a problem inherent in, in most larger organizations, larger software organizations, in which we’ve separated, back end developers from front end developers from database developers
[01:03:36] Drew Podwal: Yeah. No, no arguments for me on that.
[01:03:39] Jon Fazarro: I wouldn’t yeah I’m sure I wouldn’t I wouldn’t dream of Trying to bring in an agile framework even an agile scaling framework Before we hit solve the problem of can each team deliver?
[01:03:52] independently
[01:03:53] Drew Podwal: Right. But what, what I’ve found, so like back in my days as an actual project manager, right. the number one thing that I came up against was You know, my project was part of a program that required technology teams that that weren’t within my spoke of the, or leaf of the, of the org chart, right, reported to a different senior vice president, and so always had competing priorities, and that was the number one reason why we got stuck.
[01:04:26] because they wanted us to prioritize something that was part of their project and I wanted them to prioritize something as part of my project. And if, and it was because we didn’t have a, a way to collaborate together to be able to increment the value for a value stream, the reality was, was our platforms were doing, had to do the dance together, right?
[01:04:53] Like they were. Very close on the value streams to each other. as a result, we didn’t have the right way of collaborating. So that’s [01:05:00] when I
[01:05:00] say scale, that’s kind of like what I’m talking about.
[01:05:02] And so maybe scale
[01:05:03] is the wrong word.
[01:05:04] Jon Fazarro: Yeah. I Incredibly complex problem because The impediment, in most cases, is the organizational structure, the reporting structure itself. And when you talk about fiddling with that, you are directly impacting people’s livelihoods, because that structure is largely made up of managers whose compensation is probably tied to how many people report to them.
[01:05:29] And when you solve that problem, you create personal problems for a lot of the humans on board.
[01:05:35] Drew Podwal: Right.
[01:05:36] Yeah.
[01:05:36] Brad Nelson: Yeah, yeah, I think you hit on it like organizations have already scaled and so when you’re going and you’re trying to teach them Agile Yeah, you’re dealing with with things at scale. However, like at my core like fundamentals I am anti scale pretty much period and the reason is because 80 percent of Features in production aren’t used.
[01:05:59] 80 percent of the software we put out in production is not used. So you do not have a capacity problem
[01:06:07] At all. Like, remove 80 percent of the stuff in your backlog. You don’t need more people. The problem is, we’re
[01:06:13] busy building the
[01:06:14] wrong things.
[01:06:15] Jon Fazarro: it’s almost as if, and hear hear me out here, work is not inherently valuable and we should stop right
[01:06:21] now.
[01:06:23] Brad Nelson: Man, I teed that up. I’ll take my check in the
[01:06:26] Drew Podwal: Yeah. And I agree with that as well. Like most of most of the, aspects of the project that I was working on way back when, you know, we never questioned to say like, Hey, what’s the value here? It was just, thank you for these
[01:06:38] stacks of bricks. We will, we
[01:06:40] will
[01:06:40] Jon Fazarro: you would literally, you know, in that, in the, in a culture like that, you’re literally questioning authority. You’re questioning power. And that’s a, that’s a
[01:06:47] fraught act.
[01:06:48] Drew Podwal: Yeah,
[01:06:49] Brad Nelson: Yeah. So, we should probably start wrapping this up. I feel like I could easily go another hour with you,
[01:06:56] Jon. Um, so you just, you just spoke at CintiDeliver. Do you have more
[01:07:01] conferences coming up?
[01:07:03] Jon Fazarro: I do. Um, I’m speaking at IndyCode, in Indianapolis. on, August 10th. and I am, uh, I’m also speaking at DevOps Days, um, giving actually a, a lightning talk, encompassing all the, you know, the main thrust of what we’ve been talking about here.
[01:07:23] Brad Nelson: Awesome.
[01:07:23] Which location?
[01:07:25] Jon Fazarro: Uh, Indianapolis.
[01:07:26] Brad Nelson: Indianapolis.
[01:07:27] Jon Fazarro: Yep. Yep.
[01:07:28] Brad Nelson: Very cool.
[01:07:28] Drew Podwal: So, this was a great talk. I’m really glad that this came together and, you know, back when you and I first spoke, Jon, like I, I knew that there was going to be a connection with you and Brad, and that it just hadn’t happened yet. cause you know, I would see both of you guys posting on LinkedIn about the same conference that you were speaking at.
[01:07:49] And I was like, how did these guys not know each other yet?
[01:07:52] So,
[01:07:54] Brad Nelson: Well, when you’re there, it’s like a head spin. You’re just like trying to get to your talks and then like people are stopping you. So it, it can be, you don’t usually end up interacting with a lot of the other speakers is the
[01:08:06] reality.
[01:08:07] Drew Podwal: got it.
[01:08:08] Jon Fazarro: But you know what? That’s, if I, if
[01:08:10] I’m honest, that’s the reason I do this. You know, it’s, it’s what, it’s the main reason is to, you know, is to connect with other folks like, like you, Brad. And so, Drew, I’m really grateful that you got us together
[01:08:22] Drew Podwal: Yeah, and
[01:08:23] that’s why we started this podcast also,
[01:08:24] right? For the same exact reason. So
[01:08:27] Brad Nelson: Yeah. So Jon and I will be hanging out now.
[01:08:29] Jon Fazarro: Damn right.
[01:08:30] Brad Nelson: So.
[01:08:31] Drew Podwal: very cool. Well, guys, great episode. , I’m sure the listeners are going to enjoy it. I know I learned a
[01:08:37] lot. So thank you both.
[01:08:39] Jon Fazarro: Fantastic. Thanks so much for having me, and Drew, I’m really grateful that you got us together
[01:08:42] Brad Nelson: Thanks guys.
[01:08:51] Drew Podwal: All right. Let’s see.