Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
/Agile: dead or transformed?
108 Plays4 months ago
In this episode of The Forward Slash Podcast, James and Aaron sit down with special guest Tracy Beeson, Director of Transformation at Health Alliance Plan. They explore shifting Agile methodologies, new frameworks, and evolving industry demands, and ask the big question: Is Agile dead, or has it simply transformed?
Recommended
Transcript
Internal Teams as Consultants
00:00:04
Speaker
What I teach teams who are internal to organizations is be consultants for the business, right? Partner with them in the same way um to try and bridge that gap, to try and bring them together so that they're working together.
Universal Agile Principles
00:00:20
Speaker
Frankly, I don't care if a team is agile or waterfall or extreme programming or any of that. All of these principles that they laid out apply regardless.
00:00:31
Speaker
People in the Agile community might not be too happy with me saying that, but it's true, right? You can apply all these principles, regardless of the process that you use. Because at the end of the day, you're just trying to get to that value.
00:00:51
Speaker
Welcome to the Forward Slash, where we lean into the future of
Meet Tracy Beeson
00:00:54
Speaker
IT. I'm your host, Aaron Chesney, with my beautiful co-host, James Carmen. And today we have with us Tracy Beeson. I didn't mispronounce that today. um That one's a hard one to mispronounce, so it was kind of a softball pitch. Tracy has worked on or with Agile team since 2002. She started her career in software as QA and has worked in consumer experience, business analysis, and project management. She has an undergrad degree in computer science and MBA and is currently working
00:01:27
Speaker
as the Director of Transformation at Health Alliance Plan, or HAP, or HAP. I think we always used to call it HAP. so HAP. ah Yep. Tell me you have a newsletter that says the happenings or something. there There has to be some cutesy thing there. I don't think so. It's not that I'm aware of. Welcome, Tracy. And so today we're going to be talking about Well, actually, we're going to be talking about not talking about agile, um you know which reminds me, I used to be really good at agility, but there was this so always this one border collie I couldn't beat on the course. so
00:02:11
Speaker
Not so I had to retire without ever beating that one. It was the weave poles. I couldn't, couldn't navigate the weave poles fast enough. They're really good at this. I could twist my spine like that. They're like a snake.
00:02:28
Speaker
So anyways, welcome Tracy. it So how are we not going to talk ah about agile? Well, I mean, I think maybe let's take a step back. So we, we met Tracy, one of our, our folks, actually our producer, uh, our editor, uh, went to a conference and Tracy gave a talk ah about, you know, like stop saying agile, something along those lines.
Valuing Purpose Over Mechanics
00:02:48
Speaker
And it was like, wow, like I need to hear that this whole thing. I wasn't at the conference, unfortunately, but I was like, I want to hear all about this. So that's why I invited Tracy on to, to talk about that.
00:02:58
Speaker
I think I was in that section too ah as well because I went to the same conference. Okay. oh And and and i think I think that was one of the the lectures I went to because I was like, oh, that's interesting. Yeah, so it it all began because quite frankly, um I had been and watching my LinkedIn feed and I kept seeing all of these questions that people would post to the Agile forums and there were valid questions like how do you do this or you know what's the goal here and then you know 50 people or more would chime in of um well you need to do this in your scrum process or you're doing this part of the process incorrectly or and it was just this role of um all these debates around
00:03:59
Speaker
process. And I have to admit, when I decided to write a presentation to speak at the Agile and Beyond conference, I sort of was reading that and said, we need to stop talking about Agile. And that's where this all began. Because we get so caught up in the mechanics of the process, we forget the whole point of what we're trying to do in the first place. So that's really the gist of the presentation and where it came from. I'll fully admit that during the conference, I went to about three other presentations that were all saying similar things. And so I was rewriting the presentation in real time um to to kind of
00:04:56
Speaker
piggyback off of what others were also saying.
Back to Agile Basics
00:05:00
Speaker
Well, in, in your talk was one of the few that wasn't based on AI, you know, trying to replace developers. So that was, it was a nice, it would it was a nice refreshing change to that. So I caught a couple sections like that, that weren't focused because that was when ah the big scare of AI replacing all the developers was going on. So hearing about this was, it was, it was a good topic. So, um,
00:05:27
Speaker
So with this, like what's the focus of not trying to talk about Agile? Yeah, so it's really, a um I describe it as, but we got to get back to the basics for why this whole movement came about in the first place. um And so I really, when I coach teams and talk to organizations about Agile, one of the first things that I often do is say,
00:05:56
Speaker
Have you read the manifesto? right Because nowhere in the manifesto does it say thou shalt have ceremonies. right You need to have planning every two weeks or whatever it is. um The manifesto is trying to build ah the best way to describe it as a way of thinking right into the system. and And if you really look at it,
00:06:26
Speaker
and really read the words that that they have listed, it's not it's not about process at all. um In fact, you could apply, it and I've been having these conversations with my employees la lately, mike my coaches in particular, you could apply the teachings of from the Agile Manifesto to any process that you choose to do. It's just good practice for building software.
00:06:55
Speaker
um And so I think we have a bit of a brand. ah Issue, if you will, when it comes to agile we've we've Build it as a magic solution that will fix everything it will deliver faster, it will deliver better, right? It'll meet user needs, all those things that businesses want to hear. And in particular, managers want to hear because that's what they're being held accountable for. And in reality, it's not the process that will get you there. it it The process is important. I don't want to, i don't want ah you know, I don't want anybody to walk away from this podcast and say, Tracy said, you know, forget process because that's not at all what I'm saying.
00:07:45
Speaker
What I'm saying is processes the the means to the end, but it's not the purpose. um and And I do think we've we've lost that along the way. um Yeah, it's one ah one of the things that I try and tell people, and I on a regular basis will go back and review the manifesto just to make sure I'm like yeah resetting my thinking, you know, when I'm talking with other people,
00:08:15
Speaker
Because it is it's more of a philosophy or a mindset than it is an instruction manual.
Methods vs. Manifesto
00:08:23
Speaker
And I have the same issue with DevOps too. People think DevOps is like a team or process or or that kind of thing, but it's really just a mindset. It's more ah it in and that realm of things and reminding people of that, that nowhere in the manifesto does it say scrum.
00:08:43
Speaker
Kanban or safe, you know, those words don't exist in the manifesto, right? Those, those are the ways you're implementing your process to allow for this group think this, you know, in, in, in facilitating that mindset. Yep. Yep. Um, you know, in preparation for this conversation today, I actually was thinking about,
00:09:11
Speaker
my past experiences in Agile and kind of going all the way back to when I was a novice, right? So when I started Agile, it was 2002. I mean, I didn't, I was so naive, I didn't even realize that it was practically brand new in the industry, right? um I didn't know what I didn't know. And I recall distinctly going to, I landed myself on an Agile team. We were a small team.
00:09:38
Speaker
We had some dysfunction that we were dealing with. I'll just call it dysfunction. And um I went to a conference and I went up to one of the speakers at the conference who was seemingly well known. I forget who exactly. I'm sure it was actually one of the the bigger names um that we know today. and And I described whatever problem we were having um on my team and he just looked at me and said, well, it's because you're doing it wrong. and That was his answer. and i was It just ended there. and i just As a novice right in that moment, I was like, but but like like what do I do with that? and He's like, well, you're just doing it wrong. um I may have told somebody that before.
00:10:36
Speaker
ah You're just doing it right. And I get the I get it. Right. um And i I may have used words quite similarly in my career as well. um But, you know, perhaps time and experience plays into factors into all of this. But at the end of the day.
00:10:59
Speaker
So often the business comes and I watch these teams, the business comes and says, but I need to get this done because I need to you know i need access to my data or I need this ah feature or function to be delivered because we're trying to gain members or we're trying to get some value out of it, whatever that value is.
The Mislabeling of Agile
00:11:25
Speaker
And the team is like,
00:11:27
Speaker
Well, let's talk about the scrum process, right? Like let's talk about the ceremonies and let's, let's, this is what planning is for. And, and the business is just like, I don't care. Right. He, when do I get my stuff? When do I get my value? yeah Um, well, and I think, you know, when you talk about agile in that way,
00:11:57
Speaker
You're kind of dragging it through the mud and then the business starts to lose its appetite for, for, you know, Oh, and no, we don't want to do agile. Jeez. Oh, Pete. So we never get anything done when we do agile. Absolutely. like They associate agile with the process. Yep. And it's slow, right? Because you couldn't, because the team was like, well, let me talk about story points. And if we.
00:12:25
Speaker
You know, if we look at all the sprints and we write out all the stories, and then we can calculate the story points, and then maybe we can kind of get to when we'll deliver this in numbers of sprints. And the, like, by the time you've gone through that whole logic, theyve the business is checked out, right? Because, again, they just want to know what date are you going to deliver this.
00:12:47
Speaker
Or how much it's going to cost. Or how much it's going to cost, right? And the worst case scenario are the teams that say, Oh, we're agile, we can't answer those questions, which I have heard, right? Oh, yeah. Oh, yeah. So, so we shoot ourselves in the foot by not actually speaking to what the business cares about, and helping them understand how the process or how the thinking, right the mindset can get us there.
00:13:23
Speaker
um and And we get caught up in the mechanics of the right or wrong or you know s scrum says this or scrum says that. We get caught up in that and we forget to flex what we need you know what we're doing in order to meet those needs for the business.
00:13:44
Speaker
and And I think that's the that's the trick of it all is you know and the reason why the manifesto never said thou shall have ceremonies was because they were really trying to say, flex your process for what the team needs, for what the business needs, for you know the dynamic, for the work that you're doing, the nature of the work, all of that factors in to what the final what the process itself winds up being. But at the end of the day, you're trying to line it all up with the same set of values of, hey, we care about our people. We care about our customer. right We're trying to get this work out as quickly as possible so that we can learn from it and do something better the next time. like That's really why we're here. That's really why we ended up doing Agile.
00:14:42
Speaker
um Not a the rest of it is just a means to the end. Yeah. And one of the things that I, I try in and with like people that are struggling to communicate up the chain on things. I try, I try to tell them, I'm like, you got to think about it as a business person. There's two major categories of business, nonprofit and for profit.
00:15:11
Speaker
And so the whole reason for the business is to make profit. That's what makes everybody happy is when a business is producing profit. So you have to translate what you're doing into dollars. And if you can, if you can do that and have that conversation and relate it back to dollars, now you're on the same playing field. You're, you're playing with the same roles and you're talking their language.
00:15:35
Speaker
right If they can't do that, if there's a disconnect between, I can't translate this into dollars or time, which time is money as as the old saying goes. right so Again, that translates back to money. Then here you've got a communication gap that you've got to try and cross. Yeah. so I've seen a lot of teams where the engineers will say, I don't want to care, you know, I don't want to think about all of that, just tell me what to do and I'll do it. Right? um Or the business that doesn't want to necessarily ah help the team understand the why behind what we're doing, right? So it's they kind of take on the stance of, I told you what solution I want, just build the solution I want, right? Just do what I say. And
00:16:33
Speaker
Well, I can appreciate both of those sentiments. What it actually is doing is undercutting the team's ability to um to help be part of the solution, right? to To help create that dialogue around how does this actually relate to dollars? How can we you know how can we ah work the problem ah so that it does actually meet the needs of the business in a faster way. um Which again, going back to the principles of Agile, that's what they were trying to get at. That's what they were trying to teach us to do was to dare to have those conversations and not take it not do this as a top down, just do what I say, okay, I'll just shut up and do what you say.
Is Agile Failing?
00:17:23
Speaker
and instead have a ah richer conversation around what we're trying to do, what problem we're trying to solve. Why are we trying to solve that problem? And then let's work together to get there and figure out how best to do that. um So it's like, of course, companies now 20 some odd years later would be like, this isn't working, right? Agile is a problem.
00:17:52
Speaker
you know Of course, we're now in the state where we're industry-wise collectively throwing this out the window almost because we never got to the, we never really got to the point of it all, which was let's collaborate. And I mean, not just say the word collaborate, but actually collaborate on the solution and and innovate together.
00:18:19
Speaker
Yeah, and that's one of the that's one of the things that I've always pegged as a high functioning team is when they have that predictability where the business knows exactly the amount of workload that this team can accomplish in a given timeframe so that scope can be adjusted to say, okay, based on based on the numbers, based on you know what this team can do,
00:18:44
Speaker
in this three months, we should be able to get this, this and this. And then asking team, do you guys agree? It was like, okay, well, let's go take a look at that. And, and they come back and go, yeah, that work looks like it fits within this timeframe for our team. And that's always kind of the conversation that you want. You don't want to have that top down. This is what you're going to do. And this is when you're going to give it to me because they're going to be like, you don't know anything about the technology. You don't know all the hurdles. You don't know.
00:19:14
Speaker
what it takes to do this. So how can you say it's going to be done by this time with this functionality? It doesn't work that way. so and that's And that's really what I get out of the agile is it's it's giving empowering a team to be able to say this work won't fit in this timeframe.
00:19:37
Speaker
the way that it the way that you're asking for it. Now, here's maybe a couple different solutions that may get you to where you need, or can we trim the fad? Is there some things here that maybe aren't as important? Can we prioritize this and have those healthy negotiations and conversations between the team and the management?
00:19:58
Speaker
i I agree.
Safe Environments for Feedback
00:20:00
Speaker
The problem that that often is the case for why teams can't have those conversations is because it's not safe. And I mean, people don't like hearing that because, oh, of course my organization is a safe place. Of course they can tell me, you know, and managers will say all the right words and they intend all the right things, but that doesn't actually make it true, right? So the minute you have,
00:20:29
Speaker
um Any hint, any hint from the business or the top of the organization that if the team were to push back and say, we can't get all of this done. That's when the trust and the ability to have those effective conversations goes away almost immediately, right? And so it becomes the soft skill, the people issue that Nobody wants to talk about, that's the harder harder problem to solve, right? um and And leaders, I mean, they're being held accountable to delivering these things. So they're under the gun, they're they're under pressure. um And so it just, it it all kind of falls apart really quickly. Now, what I often teach teams that I work with is
00:21:29
Speaker
rely on the facts, right? So lay out the facts, lay out options, right? Tell your leaders, look, you asked for X, Y, and Z, X will take this long, Y will take this long, Z will take this long, right?
00:21:51
Speaker
We could do these combinations. We could do these combinations. We could dial X down a little bit and then fit all three in. It could look like this. It could look like that. You don't want to lay out too many options, but if you rely on the facts and you piece it out and in in the process of doing that, you have to then also consider what is the most important thing to the business.
00:22:19
Speaker
then you can have a much more effective conversation. You're not telling the business, no. right You're saying, well, yes, and here's how we get there.
00:22:31
Speaker
You have been a consultant before. Yes. and Yeah. i You know, the tricks of the trade. I do. And if this is really important to you, here's some ways that you might be able to get that. I think one of the biggest things that that I see in organizations and Tracy, you do
Collaboration Over Processes
00:22:51
Speaker
coaching. So I'm sure you see this is, you know, anytime we, we start to talk about the business. I mean, I think that's just a red flag immediately. Like that, that shows that you're not,
00:23:00
Speaker
cohesive together as one team. um you know and I know we've talked about the manifesto, but the very first thing is individuals and interactions over processes and tools. like The very first thing they say is like it's important to collaborate. As you were saying, collaborate with each other, interact with each other.
00:23:15
Speaker
individuals and interactions over the processes and tools, but we come in from the process side all the time. I was like, well, ah did you have your daily standup? Did you do your planning meeting? Did you do, you know, like we we get very litigious about it. Um, and then, I don't know, the way I always phrase it is like the the brainy smurfs, right? That sounds kind of natural for every, every time you, you learn something new, you're kind of, you want to do it by the book and you're like, okay, but the book says to do this. And now I always say but the brainy smurfs, papa smurf always says, right? That, that thing.
00:23:45
Speaker
That's how I think of people who are, you know, that that's what always is in my mind. But how, how have we not evolved? Like actually has been around for a long time. Why are we still brainy smurfs? Like we shouldn't have evolved past that face where we've learned like, okay, the book doesn't like work perfectly every single time. And there are nuances and there's, there's ways to do that differently. How have we not evolved? Yeah. Um, have you heard of the competency scale?
00:24:13
Speaker
Now, i'm I can't remember the lower levels of the scale, so I'm not gonna try to repeat it here off the top of my head, but there's a point on the scale called unconsciously competent, right? So the idea of the scale is like when you're learning, you don't know what you don't know, right? In the beginning, you don't know what you don't know. Then you start to learn and you get a little bit, you kind of start to pick it up, right? And there's some middle portion of the scale where you're You're getting it. And then there's a point where you hit unconsciously competent. And the problem with unconsciously competent is you're so good at it. You can't explain it, right? You can't bring it into your consciousness to explain what you mean. And I've thought about this a lot and I do think
00:25:12
Speaker
Collectively, we are possibly at unconscious competence. And that those who have been doing this, those of us who have been doing this for 20 plus years, we get it. we see them We see the problems in our head. We know what we're trying to do with these organizations or teams when we're working with them. We're not always very good at bringing really what we mean into consciousness to be able to explain it. yeah And so the but top of the scale of the competencies is conscious competence, where you really, as an expert in whatever topic, you have to kind of step back, think about it, learn how to explain it,
00:26:10
Speaker
And then teach.
00:26:14
Speaker
And so that may not be quite what you were looking for in terms of my answer to your question, but I
Unconscious Competence in Agile
00:26:24
Speaker
do think there's a little bit of that going on in our industry that, you know, it kind of goes back to that guy when I was a novice who was like, well, you're just doing it wrong.
00:26:36
Speaker
Right. He was clearly unconsciously competent in that moment, and probably could have given me a better answer, but didn't. Or maybe he couldn't. Maybe he was good at doing it and didn't know how to tell you how to do it, but he still yeah was doing it wrong. Yep. And he could have been at a different point in time in this scale. And I just, you know, as a novice assumed that he knew or must know.
00:27:02
Speaker
um I have a guess who that was. I'll run that by you. I think I know who that might be. But I think that's that's an interesting that's an interesting concept. I mean, you think about, like, I was just trying to think what would be a good analogy. Like, if you tried to describe to someone how to, like, the very specific things you do while you're driving a car, right? Like, most of us, the layperson, probably can't do that. But somebody who's a driving instructor who does it for a living, they probably do know. Oh, we hand over hand. Like, you're explaining very,
00:27:32
Speaker
very meticulously how you go about doing these these maneuvers and everything, but we wouldn't be able to do it. We can do it, but we can't tell you how we do it. And that's interesting. Yeah. i I've had my son do that as to me before. It's like, I'm like, how are you doing that? And he's like, I don't know. I just do it. And and that's kind of that. I was like, I don't, I don't know how to swing. I just do it.
00:27:56
Speaker
I think behind you know this presentation, for me, it's a it's been a journey, right? And I've spent so many years helping these teams and watching these teams and the pattern is always the same, um right? um And we know we know it and we know the struggles that inevitably you get the business, because you're you're right going back to the, why is it like business against, you know,
00:28:27
Speaker
um And I've been on the consulting side where we're the we're the experts that come in and just magically know everything. And the business is hiring us to solve all their problems.
00:28:40
Speaker
um
00:28:43
Speaker
What I teach teams who are internal to organizations is basically but be consultants for the business, right?
Agile as a Toolbox
00:28:52
Speaker
Partner with them in the same way.
00:28:54
Speaker
um to try and bridge that gap, to try and bring them together so that they're working together. um But it all is is to go back to your roots and and why are we even trying to do this in the first place? Frankly, I don't care if a team is agile or waterfall or extreme programming or any of that. All of these principles that they laid out apply regardless.
00:29:24
Speaker
And I, you know, yeah people in the agile community might not be too happy with me saying that, but it's true, right? You can apply all these principles regardless of the process that you use. Cause at the end of the day, you're just trying to get to that value. I think there's, it's interesting. I guess we're waiting for the other shoe to drop in the industry. It feels like we've, we tried a lot of these things that you, you just outlined a lot of it, right? So there's.
00:29:53
Speaker
There's extreme program, which started and then everybody signed the Azure manifesto. And then everything came up like the scrum and all of these different things. And then we've got lean manufacturing and then yeah um we've got product. And so there's a lot of things like kind of just swirling around right now. And they're all starting to kind of, um, you know, try to combine together to create this kind of Voltron of, of of how we build software that all these different methodologies combining to make one Uber methodology. Um, but it's, it's interesting that we,
00:30:22
Speaker
There's this pushback against like, well, don't do the agile thing to what in like, well, what's the alternative? I mean, we're not going back to waterfall. Everybody knows that nobody's, nobody's advocating for that, but it's like, so we just stopped doing anything and just, well, I'll just, I'll just figure it out. I was like, Oh, what is, what, what's the, what's the new hotness? What's the next big thing? You know, I, I've been asked this question, um, more than once, and I don't,
00:30:50
Speaker
I don't have a magic answer. I'll i'll be honest with you. um I do think it has to lie somewhere in thinking of these things as more of tools in a tool belt, right? that That really what we're building up is a different set of tools with different sets of skills, right? With different uses and different value add and the the teams that are going to be most successful are the ones who can evaluate what they need and apply the right tools in the combination that makes the most sense that at the end of the day stays focused on don't burn out your people, you know, people over processed, right? All of those good things. And on top of that, speaks to the business and gets to that value.
00:31:46
Speaker
Yeah, I've, I've actually spent a lot of brain cycles on this as well. And I think, I think the, you've both have said this about that disconnect between business and developers. And I think the next thing is going to be something that promotes that, that like one world kind of vision of we are all on the same team and we all work together to get something done. It's like the global economy of development, right?
00:32:13
Speaker
So there is no us and them, it is yeah we are moving together as one and it's gonna be some kind of methodology like that that I think is going to replace Agile with the like the one world scenario of we are all working together and this is how we need to think about things so that we're on the same page and moving together forward collectively instead of as individual departments and groups. Right. If you think about it, um you know, the industry moves so fast, right? Technology is changing faster than we can blink. On top of that, companies that are trying to employ tech solutions, they can't
00:33:03
Speaker
just it's not a It's not a world where you can just do it once and then let that thing live for 30 years, right? of you know Of all of our collective industry experience, I'd be willing to guess there may be a handful of projects that we've worked on that would fall into that category of do it and then never touch it again, right? So the reality of the business that we're in and the world that we're in is that there's always going to be change happening in front of us. we In order for a business to stay relevant, they have to be changing and innovating. And so if you can line up the ah thinking, right, if you can apply the scientific method, if you can kind of get people to realize that really ultimately that's what we're trying to do,
00:34:02
Speaker
then build a process that meets that need, whatever it needs to look like. I was i was going to say, are the failing ah the failings might primarily around scale? Because I think if you got a group of people together, 10, 12 total people, and you're like, let's let's build a software product.
00:34:22
Speaker
I think we've got that figured out. I think if you've got people that are like, Oh, it'd be great if it does this and all that, you know, like, I think we've, we've got that sub optimized in that size of a group. I think where things start to go off the rails is when now we've got another group of those 12 and none of the group and they need to depend on those interdependencies and you get the scaled agile framework. And that's, that's where people, I think the, the most visceral reaction, uh, to the anti agile is when scaled agile came into the world. And that seems to be the, the,
00:34:52
Speaker
the tipping point where everybody's like, stop this. This is this is outrageous. This is this is too much. Stop doing this. um is it Is it just a matter of scale? Are there or is it is there something else underlying there? I do think you're right. And that scale does have something to do with this. um And I do agree. I mean, scale that when I looked at the scale that job framework for the first time, I was like, oh, my gosh, you know, because it just It has great intent, but it missed the point in my ah humble opinion. But yeah, I think we it's like we overthought it. when When, again, going back to the manifesto, they were like, just keep it simple, right? It doesn't have to be this complicated. Just keep it simple.
00:35:52
Speaker
You have a product. If you need to slice the product up, ah maybe one team can keep this one product going. Maybe you need to slice the product up into pieces of and parts and have multiple teams. Maybe some of those teams need to coordinate with each other. Maybe they don't. um you know So talk it through. And whatever you come up as the right answer today has to be OK for it to not be the right answer tomorrow if things change.
00:36:22
Speaker
Yeah, I think from the software engineering side, we've, we've tried to, to tech our way through this, right? So do you think of like microservices and event driven systems? So you put these layers of abstractions between pieces of software for one, but it's between people, right? I don't think we've mastered that art of thinking about, I mean, you hear about the Conway's law and all of that sort of stuff, right? But I don't think we've mastered the art of, of those abstractions between, between people.
00:36:51
Speaker
to the degree that we need to. it you know Everybody's doing the microservices thing. OK, split everything up into microservices, and then everybody has to add the features of their microservice at the exact same time, because we're going to release it all together. Well, you could just get a distributed monolith at that point, right? That's not solving the problem. So I think that we're starting and with event-driven systems. you know that We're using messaging and all of that sort of thing. That's helping. Microservices is helping. But that's it's not it can't be the only thing, because I think from a technology standpoint, we figured out the The isolation and and and that sort of thing we understand that with domain-driven design and a lot of these are these things are they're focusing on that but I think it's Maybe the people aspect of that hasn't fully landed yet. Maybe that's it I don't know that that seems like where we're lacking for sure so I used to have a boss who would say ah Software would be easy if it weren't for the people you know And I and I you know, I laugh right and he was a very highly intelligent
00:37:51
Speaker
ah intelligent man who just often saw the world differently than the rest of us, which I appreciated. But I think he was right. I mean, we, we blame the process first, because it's easy to blame. But at the end of the day, a lot of these problems are people problems. Right? We all have to work together and We have emotions and feelings and you know engineers really love to get in touch with their feelings. Sorry, that was some sarcasm. I picked up on it. I'm sitting here going, what are you talking about? I know, right? And it's it's uncomfortable, right? it's It is an uncomfortable topic for anybody, no matter who you are. um and And yet that's often the thing that's really getting in our way.
00:38:50
Speaker
Yeah. And if you've ever worked on a startup project, you know, where there are very few people between the top of the food chain and the bottom of the food chain, then you know that that communication always flows openly in those small groups. And then as it gets bigger, that starts to break down more and more because you get more separation from the top and the message isn't clear. You kind of get that, that telephone or grapevine effect.
00:39:20
Speaker
of the message from the top doesn't always translate to the bottom. And if in it breaks out. And so then when you get into like the massive enterprise companies, ah like your blue chip companies, there's so much distance from from what the strategic goals of the company are to the individual developer is that it's it's almost just like you're getting a list of instructions and you have no idea how it plugs in to the goals of the company as a whole. And I think that's that's where the the issue of scale comes in is that separation from you know the the top down
00:40:05
Speaker
in in the size of the company. And one of the one of the things, it was, I don't know if it was like a movement or it was just like this one company's philosophy or something like that, but the the idea of having startups within your enterprise, right? Yes. Yeah, i'm I am fond of this idea. um Startup companies, so I've worked with Large organizations and I've worked with tiny little startups. um Startup companies have two advantages. One is what you're talking about is the distance between you know the head of the company and yeah where the ideas get generated to where the ideas actually have to play out is much shorter. um The other is they don't have the budget to mess around.
00:40:58
Speaker
right So those two things combined force a startup to to utilize their resources in the best way that they possibly can. When you only have five people on your team, then all five of those people have to know the business inside out and backwards because you simply don't have the bandwidth to, you know, the CEO
Challenges in Large Enterprises
00:41:25
Speaker
or whoever the the founder is doesn't have the bandwidth to do all the thinking for them. So you have to enable the team to to help with the thinking, right, to help with the problem solving. When you get into large scale organizations, the distance between the ideas being generated and the people have to do the work is significant.
00:41:51
Speaker
um Oftentimes the people doing the work have no idea why, right? No idea why. um And so they're no longer armed with being able to really partner on the solution in the way that a business would need. And on top of that, there is seemingly sometimes infinite budget, right? So the sunk cost of reasoning
00:42:22
Speaker
plays in, factors in, and the organization will just start throwing money at the problem. That doesn't actually get to a better end either oftentimes, um which I think is perhaps another thing that I might be very blunt about. but And people might not like me calling it out, but it's true. when you throw money at a problem, you're not necessarily getting the best solution. Whereas if you had tight resources, then you're actually more apt to innovate and come up with solutions that really work within those constraints.
00:43:07
Speaker
Yeah, and sometimes the form of that is like, oh, we'll just put more people on it too. and and with it When you only have five people, you can't do that either. You know, it's that whole problem of, Oh, well, if we have nine women, we can make a baby in one month, right? it' egg You can't do that. It takes us long to do it no matter how many people. And then there's also that problem of, okay, yeah, we're, we're up against the deadline. And then you're going to add people that have ramp up time and pull, you know, the, the velocity of the team down because we've got to bring them up to speed.
00:43:45
Speaker
So there's that kind of, it's it's subtraction by addition, right? Yeah. Nice. Yes. I think you the one word you said that that jumped out at me, and this is the same, honestly, for any real business these days, is that that why word, right? If people people don't know why, they're not as engaged, they're not as motivated,
00:44:09
Speaker
They don't get it. They're not deriving meaning from what they're doing and you're going to get less out of folks when they don't understand the why we we used to. I don't know where this was. I don't think it was at Cengage when we worked together. But it was, we would have folks when we were going through like our standup or our something, out I think it was standup, where you would basically, there would be like kind of an architecture of what we were working on. And everybody would have to go up to the diagram and say, this is me, this is this is the part of the world that I'm responding, this is what I'm working on right now, this is where I fit in and and um I'm working on this. So everybody understood when you were kind of driving that home of what what piece do I play.
00:44:44
Speaker
But that's on the very micro level. You you also, as you as you said, as you scale, we get farther and farther disconnected or or you know from the why behind these decisions and and disseminating that. It's a hard thing. and you know Corporate communications, it's very hard to to get that done well. Yep. When I worked in consulting, we spent so much time talking about the why.
00:45:09
Speaker
and I am sure that people thought we were crazy. right Outsiders looking in would be like, why are you, fit that what I don't understand. why That costs so much money to do that. But because we did that, every single person on the team was armed with enough information to question, right respectfully question.
00:45:40
Speaker
um hey, this story was prioritized. It says to do X, Y, and Z. But I'm thinking about it and I'm looking at the flow of how this all pieces together. And I don't think this is going to end up having the right you know feel for the end user. What if we did it this way instead? right And now we can have a much more dynamic dialogue around, is this the right piece of work to do?
00:46:11
Speaker
And that can sometimes be scary for managers to allow to have happen, but man, like the value you get out of that, I just, it is so, it is it's hard to put your finger on it, right? And this is where I fail, right? Because I i see it and I don't, I can't necessarily articulate it very well, but Why wouldn't you want a whole team of people armed with the ability the ability to understand why you're building this, what goals you're trying to accomplish, you know, how it all connects together so that everybody can be thinking and working the problem problem instead of it all being on the leaders?
00:47:05
Speaker
Right. Yeah. You have to have, you have to try to like foresee and think of every single thing. Whereas if you just say the why behind it, then you have, it you can kind of, um, you know, crowdsource that so to speak, right? right Like you, like you said, if I'm looking at a ticket and I know the why behind what we're trying what we're really trying to get at, what's the outcome we're looking for as this ticket, the story, if you will, it's not really hitting on, maybe if we tweaked this a little, I can, I think we'd be better off when we can get closer to that why than, than this. Right. I think that's absolutely helpful.
00:47:35
Speaker
I actually did this with an offshore team, which generally like with offshore teams, it was kind of that this is what we want you to do, just go and do it. And they're used to getting that kind of work without feedback. And I took this approach of explaining the why on everything we were doing on this project to them. And at the end of it, they were like, this is probably the best project we've ever worked on, because we knew exactly what we were doing and why. And and they did, they were able to come back and and give that kind of feedback. It's like, well, what if we did this because it'll accomplish this in a better way? And in it was ah it was a wildly successful project um because of that, in which typically, you know you say, well, we outsource this. And they're like, oh, so it's not any good. It's like, hey, type of thing. It's like, OK, so that's something we're going to have to replace. But this one wasn't. It was it was kind of the, this is the way you should do outsourcing.
00:48:30
Speaker
type of project because I had nobody in house on my team. I was it. I was the liaison project manager contact for this project. And all I had was an offshore team that didn't even know the language that we were going to do this in at the start of the project. But by the end of it, it was, it was wildly successful. And it was in ah in a lot of when, when you're kind of talking through the end of the project, they were like,
00:48:58
Speaker
The reason why we think this was so successful was because we we had the full image of what it was and why it was important from the very beginning. And so we could drive ourselves to providing the right solution.
Understanding the 'Why'
00:49:16
Speaker
Right. People connected to it, right? Yeah. um I mean, isn't that what we all want out of our jobs?
00:49:24
Speaker
but if we want to We want to feel connected to the work that we're doing. We want to feel like what we're doing is valuable. ah We want to feel like we have the ability and the freedom to use our brain on the problem.
00:49:41
Speaker
um
00:49:44
Speaker
yeah We read all the things. yeah We know that it's not money that keep people in their jobs. it's connection to the work that they're doing. So we know this. And we don't spend the time to do it. um I talk a lot about to teams about storytelling.
00:50:10
Speaker
Right. Storytelling is a great way to get teams to talk about the why without really talking about the why. um right So you ask the business, come in and walk us through the problem that you're trying to solve. right Tell the story of what this means to an end user. Tell the story of, I don't know, I'll pick on a call center application if it's internal. right so this person calls in, they're mad, you know, tell the story about all of that to the team so that the team can then have a greater understanding and context of who they're building this for, what the purpose is.
00:50:55
Speaker
um And then you will have armed everybody to to help find the right solution. And you'll get belief behind it too.
00:51:08
Speaker
Yeah. Like they'll believe in the product that they're building beyond just doing a set of instructions or working to a requirement. They'll they'll actually believe in it and want it to succeed. So they may even go the extra mile to to do something with it. I've i've worked on a couple of projects like that where there was a belief in in the motivation for doing the product and we all kind of got behind it and push it forward even even to a fault.
00:51:37
Speaker
where maybe we shouldn't. it we know Sometimes those things, they need to die on the vine because it was just, it was not kind of the right direction for the time or, you know, we push a little too hard to get it up because we believed in it so much. But yeah, having having that story is is very powerful. um And speaking of stories, do you have any any stories from the trenches of like maybe a good and a bad, maybe a rose and a thorn type story of of how some of this worked and didn't work?
00:52:18
Speaker
um So I'll start with a rose. um
00:52:25
Speaker
ah I'll relate it to the, you cracked a joke at the start of this about dog agility. I actually worked on a project for a company that runs dog agility ah program. And I won't get into the details of her story, but suffice to say, she needed us to rebuild her application. And she was a single woman running this business. And she was caught between a rock and a hard place.
00:53:10
Speaker
and we um We worked very closely with her over several years to to help her rebuild her business and a thriving business. And did it look agile? No, we broke a lot of the rules, but it met her needs, right?
00:53:37
Speaker
And we all knew why we were doing it, and we were all connected to the work that we were doing. um It was a very small team. It was maybe four or five of us at any given time working on this project. And and I would say you know that's that's
00:53:58
Speaker
We were all happy doing the work. We were all, you know, we worked well with the client. All the values that are listed in the manifesto were at play, even though it didn't mechanically look at the way somebody says it should look. What do you mean like the ceremonies by the book? The ceremonies, yeah, the processes, right, planning, you know, story card writing, none of it.
00:54:28
Speaker
really matched what should be, right? What somebody would say is the right way to do it. And yet it was a very successful project and the client was very happy. And so I would i would say in terms of teams, you know, darda dare to work the problem of how you build your process and in the same way as working the problem for delivering value for the business. um Make it fit your needs. Okay, now how about the thorn? um I love the thorn sometimes. Every other project. Yeah.
00:55:22
Speaker
Yeah. i yeah um the the team that I worked with when I was in consultant that had the directive to be 80% agile by the year, whatever year it was. And really the way that played out was to be agile for agile's sake. I was particularly brought in as a consultant to help with the quality assurance team because they were trying to figure out what does this mean for them.
00:55:56
Speaker
And it was so funny. I mean, we'd go into standups and they'd be walking through the mechanics of it. And then they'd all look at each other and then they'd look at us and they'd say, why are we doing this? Right. And I remember very, very clearly the day Well, two things. One is in that stand up, I was like, how about we try stand up again and do it this way and said, and when they did that, they were all like, oh, that's what we're supposed to be getting out of this, right? um Because I bothered to explain to them what the purpose of stand up was, because they were just told to do stand up.
00:56:44
Speaker
um There was a moment in this consulting gig
00:56:51
Speaker
where we were you know we had done all these observations. We had been trying to kind of figure out what wasn't quite working. How do we help them? And I was talking to the leaders and I blurted out, because you want your people to think. Like you're telling your people to stop thinking and just do. And the whole point of Agile is to get them to think.
00:57:20
Speaker
and to actually leverage the fact that you have hired an army, because this organization was huge. You have ah hired an army of really smart people. And all you're doing is telling them to turn off their brains, stop thinking, and just do. And instead, but the whole point of Agile is to ask them to think again. So those two things are completely at odds with each other.
00:57:50
Speaker
right now. ah yeah That's why you have to install the the revolving door at the front of the building is because you're going to end up rotating people a lot when you have that kind of mentality. And the reason why engineers gravitated towards Agile was because they wanted to think, right? I mean, all of us, the reason why we want that why we prefer to work under that process is because there might be the hope of us being able to use our brains and applying it to to the problems and and feel valuable from that. I think we've broken a few people along the way too, though, of because I have had folks that are like, i just just tell me what you want me to code. yeah I just want to sit down and code. We we do have those people in the industry and there I don't think there's a lot, but but I think we've broken folks and to think that that's what that's what software engineering is, is just
00:58:48
Speaker
Sit down, shut up, and do what I tell you to do. Code what I tell you to code. There are people that think that's what we do, and that's, but yeah, nothing could be further from the truth. Right. No, I take the soapbox away from me before I stand on it. There's still a lot I don't want to say on that. Sorry. It's a great topic. I am often on a soapbox. It's all right.
00:59:15
Speaker
All right. ah This week, we came up with an idea of, so the, one of my, my favorite answer to somebody when, so as a consultant, you know, we often integrate and interact with clients and asking them about their environment. What are they up to? And so do you guys kind of follow it? and You know, we're agile. Are you, would you say you're more on the waterfall side? And the answer was this one client was like, Oh yeah, we're agile. We do, we do stuff real fast.
00:59:38
Speaker
That was, that was, that was their answer. They said, Oh yeah. Yeah. We just stuff real fast here. That was my favorite answer of, of, yeah, I don't think you get it. Any, any, any of those from you guys. so
00:59:55
Speaker
I mean, they're the obvious ones of, um, you know, we're agile. We can change. Right. And you know that they're using it in more of a,
01:00:09
Speaker
a negative stance of like change for change sake. yeah
01:00:17
Speaker
um Yeah, I'm sure I could think of a few others that fall into that category too. and What's your favorite? um it I think it was like, you know, a big scope change was like, I thought we were agile.
01:00:35
Speaker
yeah And I'm like, that's yeah. You just can't come in and change everything and expect us to pivot on that without. Without response and delivered to the same date. That was the, that was the thing. Oh, I'm going to change all this, but we were not changing the date. And I'm like, you just added like 30% more work. Yeah. We got to change the date. It was like, Oh, I thought we were agile. That's not what it means.
01:01:00
Speaker
right i Yeah, those misperceptions are very interesting for sure. So I think at at this point, what advice would you give as like, you know, to kind of put a bow on this? What message do you want people to walk away with to to move forward in the community?
01:01:32
Speaker
Read the manifesto often um and be pragmatic, right? Don't get caught up in should or shouldn't or, you know, what's right or wrong or any of that. Just just take a pragmatic approach. um I'm going to do a book plug here for the pragmatic programmer.
01:02:02
Speaker
We hand that book to everybody that walks in the door. what I always say in our, we have a, uh, an onboarding program we call calibrate. And that's one of the things I say be pragmatic, not dogmatic.
Pragmatic Agile Approach
01:02:13
Speaker
Like that is, that's probably one of the best bits of advice. id love Yeah. So Andrew hunt and David Thomas are the authors. So, you know, sound familiar. Take that, take that, uh, to your Amazon, get yourself a copy.
01:02:30
Speaker
Oh, and then by the way, those are two names on the Agile Manifesto, by the way. That's our two of the names, the signatories. It's funny. Every time I join a new team, inevitably there's somebody who who edges up to the question of, are you going to be ma dogmatic with us?
01:02:58
Speaker
And you can see the fear and you can see them like they kind of, they find like some sideways way of asking it um because they're afraid that I'm going to just swoop in as a coach and suddenly tell them that they're doing everything incorrectly and change their whole world for the just because. And I, you know, it's I can catch it every time. And now I'm like, I'm not,
01:03:28
Speaker
I'm not going to be that person. Don't worry. You know what I mean? And I just call it out. Because but i have no you know I have no interest in shoving process down your throat just for the sake of it. It's not fun for me. It's not fun for you. So um yeah, I find that really telling when I join teams. And that's that's the pattern I'm seeing.
01:03:55
Speaker
If ever there was a slogan for the software engineering industry, at least from the software engineer perspective, you ain't the boss of me would be that I think that would be, yeah. All of them would wear that t-shirt. They don't like to be told what to do. Software engineers don't. I mean, they're really smart people. They, they tend to know if you just ask them. Or they'll figure it out. Yeah. Yep.
01:04:25
Speaker
All right. Well, that was great conversation. Thank you, Tracy. Uh, we want to move on to our next segment, which is our ship it or skip it, ship or skip, ship or skip everybody. We got to tell us if you ship or skip. So now we come to the part of our show called ship it or skip it where James and I asked our guests to give their opinions on trends in the technology industry. And if they ship it or keep it around or skip it and just get rid of it.
01:04:56
Speaker
So James, our first topic is.
01:05:02
Speaker
oh So I came up with a couple. One was. um there's There's a and it's been around a while, but the the whole kind of a movement in the agile world of zero estimates, no estimating what's our stop doing the estimates. Where are you on that? What do you what do you think about that that world? Skip it. OK, say more words.
01:05:24
Speaker
um
01:05:26
Speaker
More words. Look, I don't, ah teams shouldn't get hung up on estimates because they really are just estimates. Um, but zero estimates negates the fact that the business really does need to know when something is going to be delivered. And so how else are you going to answer that question?
01:05:49
Speaker
So are you aaron I'm an asterisk on this one. Um, I say ship it, but you have to have, You have to have either like a good refinement or planning process in place to ensure that stories are like sized because if you're not doing points, you have to go by story count. And so if they're not, if all stories are not created equal and you don't have ah a story velocity, then you need to have story points in there. So with the right tooling in place, and I've seen teams do this where they can go by story count.
01:06:27
Speaker
um then it it it could be a ship it, but you have to have a very mature team that knows how to work ah um the requirements in in a way that they're predictable in their delivery. So and that's my asterisk. With the right tooling in place, it it can be a ship it, but otherwise skip it. You need those points to be to to measure your your delivery.
01:06:55
Speaker
i think so the important word that you just said is predictable, right? The the whole point is be predictable and however you get there, um you know.
01:07:07
Speaker
Yeah, I've seen, and I think we, I've seen either counting stories, which is effectively the same thing, or I've seen another team that basically did a kind of an empirical look at it and they were like, well, our average story size is like with very little standard deviation, blah, blah, blah, blah, blah, blah, over a period of time is five points. So let's just call everything five points. zero You're effectively counting, right? So you're basically multiplying your count times five to get a velocity. I think the bigger issue is.
01:07:36
Speaker
You know, what, what is it? When, when a measurement becomes the goal, that's the whole problem with velocity stuff. It's like, well, you didn't get as many points this time. What's wrong with you? No, this isn't wrong with it. It was something, you know, we had production or whatever. There's that there's an, whenever you try to blend in things like, okay, well, let's add in a point per day for going to lunch and all that. Like it's not a timekeeping mechanism. You're just masking the issues. When you do that, you try to blend it and make it a nice,
01:08:03
Speaker
blended curve that, that always messes everything up and it doesn't achieve what I always, I always tell management that to expect a sine wave type of velocity out of a team, because it's going to ebb and flow like a sine wave. And you're going to have certain weeks that you're going to over-deliver and then you're going to have weeks where you under-deliver, but in the end, it's going to average out to, to ah an average that.
01:08:29
Speaker
over time, because if you think about projects, they're not like, this is a one week project. It's usually months at a time. Over those months, you're going to see a, you know, uh, either, um, a level delivery or an increase in delivery. You'll that's your trend line. You want to trend it. You don't want to just base it on a single sprint at a time.
01:08:53
Speaker
If it's a one-week project, throw all that crap out the window anyway and just get to work. right You don't need any of that stuff, right? like Just get stuff done get it done. All right. You want to do the next one? Sure. So our next one is, it kind of goes with this that we were just talking about is measuring software developer productivity. So trying to measure individual developers for productivity.
01:09:24
Speaker
This, this just comes from that. You remember in 2023, Mackenzie, I'm sure you're nodding and you can see you're not, you know exactly what I'm talking about. There was a big blow up about this. And then, you know, so I don't know where, where are you on measuring? Where am I on that? Yeah. So, um, I tell my teams that this is the one thing that I will die on my sword about. Um, there's no need to measure individual, uh, contribution. In fact, it, it.
01:09:54
Speaker
creates so many bad habits across the board. The whole point is to get the team to work together. So I'll use this analogy. like you You're running a relay race. One runner can't finish the whole race by themselves. right So to measure a single velocity,
01:10:21
Speaker
like the You're just promoting the one runner to run ahead and leave everybody else behind. And that doesn't actually get us to the value and the, you know, the goals that we set out to accomplish because that one person can't do everything.
01:10:41
Speaker
So just to be clear, you're a skip it. It feels like, it feels like a skip it. I'm just, I didn't want to put words in your mouth, but it sounded like a skip it. A strong, a strong skip it. Yeah. I'm, I'm going to echo that sentiment. Um, almost for being, because I've actually had this happen where, you know, somebody looked at my personal velocity and was like,
01:11:09
Speaker
I noticed that you clear more points when you're working so than when you're paired. And I'm like, well, of course I am. When I'm pairing, I'm teaching, right? right i'm I'm trying to get them to do it.
01:11:25
Speaker
in in a way that is going to help them in and raise the collective watermark. So we all increase our velocity. If I'm working by myself, I don't need to teach myself anything. I'm just going to go do it. Right. So there's no, of course it's going to be, so my velocity is going to go down when I'm paired because I'm trying to teach.
01:11:46
Speaker
And it was like, Oh yeah, that makes sense. So, and if you just go by the raw numbers, it's like, well, we can't have him paired because he, you know, he's wasted all this time and not doing work and blah, blah, blah. Right. You know, because the numbers tell a different story. Yep. If I complete five of my own story points in a sprint, and then I also turned around and helped everybody else move their stories forward. Right.
01:12:15
Speaker
Does that mean I only added five points of value? How many people helped you do those five too? Right. you know And others are helping me. Yeah, exactly. So, so it just, it, it's just a useless number because it, it fails every time to really tell the true story of what's happening on a team and what somebody's contribution to the team is.
01:12:41
Speaker
If you really want to know what somebody's contribution to the team is, ask the team. They already know. We don't need data for that. We try to concept on trying to capture this that we'd call lift and drag. Like, you know, how did you provide lift to the team by, you know, accelerating it or how, you know, what were the drags on the team? And it was one of these things, like it was.
01:13:10
Speaker
When we did our, um, uh, well, the name just escaped me, uh, retro, we did our retro at the, at the end of sprint. We would always try a different theme. And, and one of the ones that I always thought was, was kind of funny. Was it was, it was a boat retro and you had so anchors, yeah anchors and in. in I don't like Gus or something like that, you know, the so the things that moved you forward and helped you go forward, where your Gus and then your anchors were your drag items and in capturing those things I always thought that was an interesting tank because those are the kinds of the things that really lead
01:13:51
Speaker
you to changing what you're doing as a team to try to eliminate those anchors and get more gusts of wind behind your sails to actually move forward. So I thought that was good. So yeah, tracking individuals, hard skip it.
01:14:10
Speaker
Yeah, this one, it it is a tough one because I mean, I get where they're going. They're coming from where where people are coming from. they There needs to be some account of it because what the, the business, what, what, you know, the point of hearing bosses here, when we developers say, no, no, no, no, no. I don't want you measuring me. You know, they they hear, I don't want to be accountable to anything. I want to just be able to, you know, mess around and slough off and and and not do my job.
01:14:32
Speaker
I think the the key to that, to to empowering the team, like you all are saying, and measure the team as a whole, is where you have ah a ah good cohesive team, where they do have that radical piano with one another. because if there there are let's Let's just face it, there are people who don't do their job. But the team has to feel empowered enough to say, hey,
01:14:50
Speaker
Billy what's going on you're not going to stand up every day you're not you know you're you're not you know carrying your weight on the team that they you know i i think they should be able to you know vote somebody off the island themselves the team should be outside that you you shouldn't be on our team anymore what usually ends up having the home is.
01:15:07
Speaker
Billy, and we'll just use Billy as the example, if he's sloughing off the other team, just, just pitches in and and overcomes the the dead weight of Billy and Billy just gets a free ride for a while. That's a lot. That's what you see a lot of times, but and they don't feel empowered to to go to Billy and say, Hey, you know, you're, how can I help? What's going on with with you right now, Billy? goes you You were great for the last six months and now there's a struggle. what but How can we help? How can we come alongside you?
01:15:30
Speaker
If you can build a team that but is truly a team working together and and with one another, um absolutely the team-based metrics work. Maybe we just need the reality TV diary room that everybody can go into. it And then the managers can review it. It's like, oh, man, everybody hates Dr. Will for some reason.
01:15:53
Speaker
We might need to get rid of him. That's a good idea. Oh yeah, these are these are just for historical purposes. Nobody's reviewing these. It's just a way for you to vent and and deal with the the things that you have bottled up. The camera doesn't even work, we promise. It's just a mirror. There's there's nobody behind a mirror.
01:16:22
Speaker
All right. Do we do we have anything else for a ship it or skip it today? I had a lot. but We were were keeping Tracy here way too long already. So OK. So we will move on to our final segment, the lightning round.
01:16:43
Speaker
It's time for the lightning round.
01:16:57
Speaker
So on the lightning round, James and I will go back and forth asking you a series of questions in a rapid fire fashion. um These are just short answer questions that are meant to give us a little bit of insight on who Tracy is. That's right. That's right. OK, so James, why don't you kick us off?
01:17:20
Speaker
And then again, these are the hard-hitting questions we save for this. Why can't we tickle ourselves?
01:17:29
Speaker
Sorry. I think you tickled her with that question. but But that's not her tickling herself, right? I don't know. I mean...
01:17:47
Speaker
i that I don't know. Sorry. I don't either i don't know just broke my brain on that one. I don't know the actual answer. I don't know that I've ever tried.
01:18:00
Speaker
um Do you want to buy something? I do, yes.
01:18:08
Speaker
Let's see. yeah that's we We would have all also accepted no. yeah yes It's a running gag where we have a binary answer. and um Do you like the name Charlie for a girl? um Yes, actually I do. And in fact, my son's name is Charlie. um But I also like it as a girl's name.
01:18:37
Speaker
ah What temperature do you like your thermostat at? Currently, it is at 69 degrees, which is kind of warm. I feel like I would probably normally set it to 68.
01:18:55
Speaker
I'd love to have your electric bill or war what a gas bill, man. You don't want the electric bill in the summer at that, because that's where we keep ours at. And that's and oh yeah the AC struggles at times.
01:19:08
Speaker
Yeah, my AC temperature is different. Yeah. Okay. You're going higher on that one. Yeah. Yeah. Yeah. Keep it. Keep it reasonable. I understand. All right. Would you eat a day old taquito from 711? No.
01:19:25
Speaker
Using an Elmo voice. and Tell me how you would like your coffee.
01:19:34
Speaker
So my kids are too old. I don't even know what an Elmo voice is these days. I'm like way out of that. But um I drink tea. That's me. um So watered down is how you like your coffee.
01:19:54
Speaker
I suppose you could call it that. who All right. ah
01:20:03
Speaker
For journaling, do you like to use actual paper or computer? Paper. I am, I am a Luddite at heart. I love it. Oh, I got to remember that one. I love that. I'm the same way. I'm, I'm, I have to love the feel of the, the Ludd against paper. Um, Oh yeah.
01:20:30
Speaker
So since we're all dog people here, is a human life more valuable than the life of a dog?
01:20:41
Speaker
I mean, how do you define value? His story. Great. That's a great.
01:20:54
Speaker
thats Perfect. That was great. That was perfect. How many story points is it? In memory, it has to be hours. They equate to hours. We're going to tie that back to hours. Yeah.
01:21:14
Speaker
It's seven times as many for a dog, so there's your answer. There you go. to that yeah All right, so have you ever slapped someone in the face? No. I had to think about that. Not in the face.
01:21:35
Speaker
Upside the head, maybe. that can. yeah That's how I used to keep my little brothers in line and flip the class ring around and pop them in the back of the head. that's yeah I mean, I grew up with two older brothers and we were all athletes. So there was a lot of energy in my in my house, physical energy at that rate. Yeah, a lot of physical energy, um for sure.
01:22:06
Speaker
So would you rather lose all your hair or gain 50% more hair?
01:22:15
Speaker
I would rather gain 50% more hair. I've already lost all my hair. So if I could not have to shave, I would prefer that you know what I mean like this just let it be bald and not yeah, 50% more hair I look like bozo the clown
01:22:33
Speaker
wood. because mean i would i would have ways to contain that There's products that would help with that. Yeah. yeah we But I would still just have 50% hair. Fair enough.
01:22:51
Speaker
yeah all right are we one more one more one more the final rounds the final this is the final round okay yeah you need your you need your little effect there sour patch kids or Swedish fish sour patch kids climb a mountain or jump from a plane climb a mountain yeah I don't like heights. Why jump out of a perfectly good airplane? Yeah, seriously. Definitely not. And mountains are there to be climbed, right? Yep. That's their whole purpose. i so I still have my feet on the ground if I'm climbing a mountain. Yep. You hope.
01:23:42
Speaker
Unless something goes horribly wrong. Exactly.
01:23:48
Speaker
All right, and that completes the lightning round. And you survived. <unk> All the way through. That's fantastic. Second person so far to make it all the way through. i Yeah, I think so. Somewhere between two and 100. At this point, um are you want to give a shout out to anyone? any final thoughts, things that have come to you that you would like to plug? ah Yeah, books. So while we're plugging books, I would say leadership and self-deception is one of the most powerful books I have ever read. It turned a light bulb on for me. And I think anybody
01:24:48
Speaker
Well, really anybody in any industry should read this book, especially if you're working on teams of people, which we all are. It's a fantastic book. It was one of the biggest like, like you had to kind of struggle through it yourself with that book. Like, man, am I a jerk like this? Wow. I feel like such a slimeball. I know how to answer that.
01:25:11
Speaker
yeah yeah
01:25:14
Speaker
I mean, the reality is sometimes we are, right? Yeah, I mean, unknowingly. Yep, unknowingly. Yeah, that's a good book. All right. And if you want to get ahold of ah Tracy, you can reach her on her LinkedIn at, I lost, the here it is, um, at linkedin dot.com in ah Tracy dash-Beeson, that's B-E-E.
01:25:45
Speaker
S-O-N, Tracy with a Y, not an I-E. Or just an I. Or just an eye I, yeah. Yep, just Y. If you have it with just an I, you have to dot it with a heart. i And it's not like T-R-A-Y-S-E-E. Yeah, you it's T-R-A-C-Y. Just keep it simple. we Exactly, keep it simple.
01:26:14
Speaker
Well, I'd like to ah thank Tracy for her time today in speaking with us about not speaking about agile and what that means. And hopefully you have gleaned some information. Join us next time. We'll be talking to someone about technology in the construction space. So that should be an interesting conversation. um I'd like to thank her our listeners.
01:26:40
Speaker
ah Please subscribe, rate, and share the forward slash with your friends. They might not be friends after you do, but let's hope they are. Wow. If you'd like to reach us at the forward slash, you can do so by email at the forward slash at coliberty.com. I'd like to thank Tracy one more time. My beautiful co-host James.
01:27:07
Speaker
and I am Aaron Chesney. Thank you and stay curious.