153: Luke Hohmann

Listen to full episode:

Joe Krebs speaks with Luke Hohmann about profit streams, value and the agile community. Luke is a serial entrepreneur from the Silicon Valley who is known through his community work, innovation games and now profit streams. His new book is truly a piece of art -> check it out here.

Transcript:

Agile FM radio for the agile community.

Today I'm thrilled to have Luke Hohmann with me in the podcast here of Agile FM and I can't believe After all these episodes I had so far I haven't had you on the show, which is a big miss. You are a renowned expert in agile methodologies an author. And I think a lot of people know you from the innovation games which is a framework for collaborative decision making problem solving.

You have experience that dates back way, way back into the 1990s, pre Agile, but also I heard recently that you were involved in the 2003 Agile conference. So yeah, a while back. Welcome to the show, Luke.

[00:00:46] Luke Hohmann: Joe, I am so happy to be here. I've known you through the community. We've seen each other at conferences.

And so it's a, it's quite an honor to be here. Thank you so much for inviting me to participate. Thanks

[00:00:58] Joe Krebs: Yeah, no, absolutely. We could talk about the innovation games and fill an entire show, but today we could, but today we want to talk a little bit about value profit stream, the agile community as often. This is the recordings taking place on the 25th of June, 2024 is a little bit in a turmoil. The Agile community as a whole, there seems to be some different kind of directions people are going, looking at the roles. It's maybe a good time to talk about what value is, how we can present value because at the end of the day is, it's like, how do we sell agility within an organization or for organizations?

[00:01:44] Luke Hohmann: I think it'd be a good thing to talk about. There, there's so many aspects of this that are interesting, but let's try a few. And I'll also talk about the rule of self interest in the Agile community. When we talk about value we think about it in terms of our Profit Streams book and our Profit Streams work as What are the set of tangible and intangible benefits that a product or service we use solution as the single term for product and service or any blend thereof.

So it's just a little easier because we're here to solve problems for our customers. So we think of both the tangible and intangible benefits. And for the tangible benefits, we help companies create mathematical equations that capture the benefits. And we often work with our clients because technical people are good at being efficient in terms of doing things like saving time.

But the reality is most companies don't need to save time. They need to have the time converted into a metric that they can understand for their business purposes. One of the examples we use in our book, and it's been proven in many of our client engagements, Is we were working with a trucking company, and they were going to be buying software that saved their drivers time.

So drivers in the trucking industry have to keep detailed logs of their hours of service to make sure they're taking breaks, etc. And this solution enabled the data to be acquired automatically by connecting into the engine bus. And they knew if the truck was on and if it was moving and all that kind of technological internet of things capability that we love.

And there's so many things that we can do. So the company that we were working for, and this was Qualcomm had the solution. They went to the trucking organizations and said, Hey, we can save you 20 to 30 minutes a day in driver time. And Joe, we were able to prove this. Absolutely through, the data, like the data was very clear.

And the trucking company's executive said we don't really care about that. Because our drivers are union and they are paid for eight hours. So saving me 30 minutes of a driver's time doesn't actually save me money. It doesn't do anything for me. So we had to go back to the drawing board with Qualcomm and find out how to reroute drivers using the new systems so the trucking companies could deliver another package or two in a day because that's how they made money through package delivery.

Or the other part of this would be the intangible side and intangible benefits can be quantified on the intangible side for challenging deliveries. We were able to allocate more time in the driver's schedule so that customer satisfaction improved. And as customer satisfaction improved, we would see less churn among customers.

Oh, my package was delivered well. I want to use this company again. My, my package was delivered without any breakage. I want to use this company again. So the first step of value is to actually take a step back and try to quantify the tangible and intangible aspects of value. And then I'll just real quickly, I'll finish that off.

The second of the determination of value is what we call direct and indirect benefits. A direct benefit is something that you will recognize as a benefit and it materially affects your purchase or use decision. An indirect benefit is something that you recognize, you'll say, yes, the benefit exists, but it doesn't influence you.

And I'll give you a kind of a standard example. My wife and I were out shopping for a new car. I cared a lot more about the styling and color. She just doesn't care about that. And and she would readily agree yeah, that's a good looking car, but it doesn't affect my purchase decision.

Whereas I was, hey, that's a really good looking car. I think I bought it. And so now let's take it into the business context. The solutions that we're creating, which are often very sophisticated, there's a collection of benefit. It's not a single benefit. And collection of benefits, you create a network of how the customer perceives those benefits.

So let's go back to a trucking company that is focused on customer satisfaction is not going to really care about the not care as much. I shouldn't say they care. They don't care at all, but they're not going to care as much about like driver satisfaction. But let's say you're a trucking company and a part of.

The world where it's hard to attract drivers. Now your network of benefits might emphasize driver satisfaction. So understanding not just what benefits are, but how a given market segment is going to perceive the collection of benefits is really the foundation of our approach, and then from there, what we do is from the benefits, We can derive the customer return on investment model.

We can derive your pricing and packaging model. We can help you develop your solution so that you know that you're building a sustainable offering. And I'll close with this Joe. The foundation of profit streams is sustainability. If you're running a business, Or frankly, if you're running a household, you have to have a positive flow of cash coming into your business or your house, right?

We can't, other than the government who prints money, right? Like a business has to have a profit to survive, to sustain itself. Now, in some cases, profits can be misused or we can have unsustainable business practices. But if you look at true sustainability involves.

Three related areas. One is your solution itself has to be sustainable over time as your customers evolve as their needs evolve Your solution has to evolve to be relevant and to meet their needs So with the first part of this is solution sustainability The second part of this is economic sustainability Are you charging a price that will keep your company in business?

But are you also factoring in your customers total cost of ownership? So that your customer perceives what you're selling to them as a good value something they want to keep The relation going right? We want to have economic sustainability and then the third kind of sustainability is relationship sustainability when we Sell software.

We're not actually selling software. We're selling a license to use the software So the distinction is that i'm holding in my hand a pen You If I sell you my pen, I've transferred rights to you. You now own the pen. You can do what you want with it. I don't sell you software. I license software for you to use.

So there's a license agreement and that license agreement determines our relationship as the provider to the customer. There's other relationships that matter. Every software package that is created has technology and licenses associated with it. So the provider is in licensing work, and there's relationships that they need to maintain.

And of course, the kind of the capstone of all of these things is our relationship to society and to other parts of the world. Of the global infrastructure in which we live. And what I mean by that is if you're in Europe, you need to honor GDPR. If you're in the United States, you have to honor California CCPA.

If you're selling certain kinds of fintech software, you might have to be PCI or SOX two compliant. If you're in the healthcare industry, you'll have to be HIPAA compliant. If you're in the education industry, you have to be. FERPA and COPA compliant. So the idea of compliance to us is part of that relationship.

What is the relationship your company wants to have with various regulatory agencies? Are you going to try and be an organization that honors those relationships and fulfills your compliance requirements? Or are you going to be an organization that's going to try and skirt those requirements? And perhaps engage in questionable or provably unethical behavior, and so all of that is what comprises profit streams.

[00:10:42] Joe Krebs: Yeah, this is it's very interesting. And as you were elaborating on this, especially on the economics, sustainability It's interesting, right? Because I think we all have seen situations as a consumer before where we felt like I need a certain service or a product, but I felt like this was too, too expensive.

I've felt abused based on a very specific situation I'm in and I'm requiring a service or a product. I feel like everybody can relate to that. So finding that kind of fair spot, yeah. In terms of sustainability, I can totally see that as well as the other ones as well. So I think that's a great example.

Now, if somebody hears the word profit stream, at least the first thing that came to mind for me said, what's the difference to value stream, right?

[00:11:24] Luke Hohmann: That's a great question. And we should know the distinction between a profit stream and as a value stream. I credit this to my friend Avi Schneider who is well known in the scrum community.

Avi, after reading the book, he said, Luke, I've come to learn and realize that all profit streams are value streams, like all squares are rectangles. But not all rectangles are squares. So the distinction that I like to talk about Joe is that typically a profit stream is going to be more aligned to what SAFe calls an operational value stream and the development value stream of SAFe would be a cost center.

So now let's look at value streams and let's look at specifically operational value streams. We think of profit streams as those operational value streams that are generating revenue for a company. And so not all value streams generate revenue. For example, there are value streams provided by. Government entities that don't provide revenue, but provide services that maintain our society, which we need, and those are fantastic.

But not all not all value streams are profit streams. And that's a good distinction. When the other thing that's interesting, and I give a talk on this. Is when we look at value streams, especially the operational value stream, you start to find that. We have a starting condition and we go through a sequence of steps and we get an ending benefit.

Actually map in your operational value stream. When revenue occurs, you'll find that many things are costs until the very end. It's like value streams are rainbows, right? The pot of gold is at the end. And so you really have to make sure that you're understanding the steps in that operational value stream.

And what we work on with our clients is that we try to help them understand the economic sustainability of looking at that sequence of flow to make sure that you are generating enough revenue at the end to support the whole flow and looking at ways you might be able to pull revenue sooner so that you can sustain yourself.

[00:13:45] Joe Krebs: All right. How do you respond to somebody who is like possibly interested? Here's the word profit stream. Obviously I see dollar signs and signals and cha-ching and all of those kinds of things. For an agile audience out there who might say, Hey, but what about the team spirit? And what about sustainability of a team's, fun and learning environment?

Aren't they contradictory to this? I guess the answer to that is no, right? But it's the,

[00:14:14] Luke Hohmann: of course, all of those, Joe and for the listeners, Joe and I were chatting before the podcast we often do. And one of the things that I really find disappointing in the agile community is a lot of agile people seem to have this kind of disdain for management or this disdain for leadership.

[00:14:32] Joe Krebs: And I think of it exactly the opposite. Business leaders over the last 20, 25 years have shoveled hundreds of millions of dollars into agile practices and transformations between the training and the tooling and the infrastructure. And they've gotten benefit from agile. I'm very proud of all the things that software people do.

Earlier today I was getting a blood test. And I walked in and there was a kiosk and you just typed in your phone number scanned your driver's license and you were checked in. Software people did that. And I think what we do as software people is really cool. Yeah. Hardware and software. We designed a solution that was amazing.

And of course, Joe, we want to have sustainable practices, not just in our business relationships with our customers, but true sustainability means sustainability with our employees, with our practices. With what Kent Beck wrote about very early in the community with XP, like XP is about sustainability.

So to say that profit is antagonistic to sustainability is to have a very flawed understanding of what sustainability is and or what profit is. I've been a serial entrepreneur. I've started and run and sold a couple of companies. And it's really a lot of fun when you're an entrepreneur and you can give out bonus checks because you had a great year Yeah, it's not so fun when you had a bad year and you're cutting salaries or you're doing other You know doing a layoff or whatever.

And so for the people in the agile community who talk about humanness of our developers my response is Yes, heck yes, we, those are things that promote sustainability. Those practices, the training the better tooling, the better computers, they require money, they require a profit.

And most of us work for a for profit company. It is, I think it's pretty above average that people would be working for profit rather than for the non profit sector. Should we go a little concrete about some data points, metrics, because I don't want to I'm just going to say the word.

We really don't have to go down that path at all in this kind of conversation. I think we have debunked the word velocity as a metric or something like that. I don't think we have to talk about that. But what are. Measurements, like if somebody would say, Hey, this sounds very interesting. Definitely trucking sounds good, but I'm in a totally different domain.

In terms of this, I would what's a good starting point for people to say, like, how do I measure these profit streams from an IT perspective or, Yeah.

[00:17:18] Luke Hohmann: And Joe if I'm not answering the question in the way that you're intending the question that's okay.

I started as an engineer and for everyone listening, Joe and I had a really, a geeky out moment when I, when we started, but I started as an engineer. And then I became a manager of engineer and then I became, vice president and all that kind of stuff. And I was always trying to create the best solution for my customers.

And along and in that journey, I found product management. I thought, Oh, wait a minute. Product managers are the people who are designing the solution and working with designers on the user experience side. And they're in the center of the world of this thing called creating a great solution for customers.

And through that. conversation, I started to realize, Hey, I'm responsible for creating a return on the investment of the company I'm working for. And from there, I started to learn the basics of finance. And I started to, understand how to read a balance sheet, how to read what is EBITDA what's the difference between CapEx and OpEx.

What is the terms of the license agreement? What is, what can go wrong in a license agreement? If it's not crafted correctly for a company, how do I know if I'm making enough money, has my economic, let's go back to the engineers has my economic model factored in a pay raise for my team next year, because there's inflation and if there's inflation and I want to pay my developers more money, How do I manage that with my margins?

Either my costs are going down, which might happen. And, maybe my software part of the solution is the same price, but my hardware margins are improving because I have cost of scale manufacturing. Maybe I don't, I'm a pure SAAS company and I'm picking up some lower costs because of hosting costs are dropping.

How do I economically think about these elements? So the, what I would say is this is one of those areas where Agile has to do nothing more than embrace what has been existing for a long time, which is economic models Don Reinerson's work on flow. Looking at possibly throughput accounting, but educating ourselves, educate product managers, educate themselves on what's in our book, which is not just how do I economically model, but how do I actually. Set the price point. How do I determine the packaging of what features go in? What edition of my offering and do I charge? So those kinds of things are to me they're not taught as much as they should be in the agile community, but that's why we wrote the book.

[00:20:10] Joe Krebs: Oh, absolutely. I agree with you.

And I think indirectly you are answering the question, at least for me, right? Because I do see certain data points being captured within agile teams that are contradictory to what you're saying right now. These are like the velocity discussions and that are happening within teams. And then all of a sudden they happen on the leadership level, whereas you're saying, actually, some of those conversations are still existent as they were before agile, but they're still applying it.

Just they have to be maps. I feel like you're having a much more adult mature kind of conversation about this. And I think we're actually experiencing within teams on the ground.

[00:20:48] Luke Hohmann: Yeah I think the Agile community has gotten a little wrapped up around the Axel about, I helped form the first conference in the Agile Alliance series in 2003 with Alistair Coburn and Ken Schwaber and Rebecca Wirfs Brock and a few other people.

And Todd Little, and let me tell you, no one at that conference was walking around arguing about the fine distinctions between output and outcome metrics and things like that. We both have a friend, Kenny Rubin, and he's written very beautifully about this. But trust me, in the very early days, we weren't arguing about those.

It's like people drink fine wine and argue, Oh, are you getting black current or dark cherry flavors in the wine? No, just have a glass of wine and enjoy it. Um, and what's happening is we're forgetting that sometimes you do need to track certain basic metrics just as a mechanism Of I think consistency and let's say you're an athlete.

Let's say you wanted to run a marathon. The number of miles you run in a week or the total miles that you've run in training for American a marathon could be a vanity metric. Oh, but at the end of the day, it's also the truth that you're not going to go run 26 miles if you didn't train And a training program is going to tell you how many miles you need to run Per week and if you're not tracking how many your miles you're running per week You're not going to hit your end goal of running the actual marathon So I think that so many other aspects of what we do, there's a very healthy way to look at velocity and velocity metrics and looking at flow metrics and unhealthy ways of looking at it and rather than throwing everything into a bucket of healthy and unhealthy, we should use the agile principles of retrospection.

This metric and the way that we're using us, helping us advance towards our goals. Yeah. And it is, we should probably keep doing it. And if it's not, we should look at what we need to change.

[00:22:52] Joe Krebs: Yeah. It's very interesting. I also, while we were talking about the marathon, I was also thinking yes, there's definitely mileage.

This is an important piece, if part of your training program, but it's sometimes, and I don't know if that makes sense, I think sometimes we're measuring how many minutes we also have used for stretching, and yes, it is. a great technique to become a marathon runner, but I don't think from purely stretching, you're becoming a good marathon runner.

I think it's together. And I think it's also for metrics like these things have to balance each other out. If you're having 90 percent stretching and 10 percent running, maybe that's the wrong

[00:23:25] Luke Hohmann: that's where wisdom comes in. And that's where not always trying to invent everything from scratch, right?

If you were, if you really were going to go run a marathon, you'd probably go talk with other runners. You'd probably go to some running websites that like runner's world that has reputable training plans. You'd get a sense of the balance of the metrics. So it's. It's very rare that one metric on a development organization is going to be the only metric that you needed.

And again, this is where people start to it's good to have these discussions to calibrate. But it's like the definition of done, right? At the definition of done, you might say our definition of done is no stop ship bugs where stop ship is defined as P one and sev zero, like separate priority severity.

Then you get into people who are like if I have no stop ship bugs, but I have a bunch of small bugs, can I still ship? And I'm like, I don't know like maybe no, maybe yes. What's the, we should have a conversation about that. And the metrics are designed to use to guide us into the conversations that are most beneficial, just like.

So if I looked at a team that had velocity metrics, and they were reasonably consistent. And I saw an anomaly, like a dip. I, as a manager, if I didn't already know, I would go to the team and say, Hey, I noticed that your velocity dip, everything. Okay. And if the team says actually, no Joe went on a ski trip and broke his arm and our velocity dip, cause he was in the hospital.

And we're all really worried about Joe. Wow, that stinks. Maybe we should send Joe some flowers or some get well, but now I know why velocity dipped. Yeah, and it was a special cause and it'll resolve itself. Um, now the other element could be our velocity dipped because we completely misunderstood the requirement and I'd be like, okay maybe we should toss that into a retrospective.

There's so many good retrospective techniques. Maybe we should toss that into one of our retrospective techniques and see if that's a special cause or if there's some other potential issue that the team might be facing. And then the team goes, Oh yeah, no, we think we're okay. It was just this one time.

We didn't really understand the requirements are no, we're actually in a new area of our solution and all of us are experiencing this new thing and we need more training or we need X to really get ahead of the issue. So metrics are important, right? We keep score, right? We keep track of things.

[00:26:03] Joe Krebs: Yeah. So it's interesting, right? Because we, you mentioned before that there is this general amount of metrics. Don't want to repeat them necessarily, but these are like the business metrics. And these are the things that our businesses are already using on an enterprise level with or without agile.

Why are we having such a hard time in the agile community to translate that? Obviously, your book will help in the translation of all of those things. But what do you think of the pitfalls?

[00:26:29] Luke Hohmann: I actually think one of the pitfalls is how some of the agile methods have defined what a product owner is.

You'll see agile methods say a product owner is responsible for value. Which is great, but then they don't define it. And so we've got a generation and I spent most of my formative business careers here in silicon valley, not all of it, but a lot of it So i'm used to a silicon valley style of a product manager Knowing how to run a spreadsheet knowing how to do pricing and being trained And what we're finding, I think, Joe, is that there's this tremendously large number of people who are associated with products, but don't have this training and pricing.

They don't have this training and licensing. I'll, one of the things I do with my clients is I'll walk into a situation where they're, they need to, make an improvement economically. And I'll just go to the product managers and I'll say, when was the last time you read your own license agreement, your own terms of service on your website?

And they'll be like, Oh yeah. never! Like, okay we should read it. And I'll give you an example of kind of the weird things that can happen in license agreements. We were working with a smaller company. And their license agreement with, so they served larger companies and it was a conversion company.

I don't want to go much further than that. Yeah. They had a contract with a larger company that said every time the larger company made a request to the smaller company and the smaller company agreed to that request, their maintenance agreement would automatically extend for one more year. So every nine months, the big company would make a request to the small company.

On a very small change, the small company would make a very small change. And then now they're saddled with a responsibility for another year of support. And I said, okay this two sentence clause in your license agreement is now costing you almost 300, 000 a year. Now for a big company, you may not notice it, but this was a company with less than 8 million in revenue.

That's a noticeable number for a company with eight million right now. It's still a nice company. Don't it's not it's a very good business but i'm like this two line sentence in your license and the product manager was like wow I didn't know how to interpret that. I think we're seeing this challenge in the agile community because too many Organizations have allowed this skills of pricing and economic sustainability modeling to activity.

Yeah, let's say you're, let's say you're agile. I don't care what flavor of agile you're using, pick one. I don't, there's so many, it's like going to the ice cream store. So you pick one and you're putting out more value at what point. Should you raise your prices because you've added so much value?

At what point should you adjust your packaging? We work with a client who they kept on shoving features into their solution Which sounds great, right? But then their sales started to slow down and that the head of Product contacted me and said it's really weird luke Every time we're adding more features our sales team is telling us it's harder to sell that's a packaging problem because what's happening is people are saying Your solution now includes Features that are not relevant to me Therefore I want a lower price because i'm not using them.

That's right And the right solution is to say okay now that our product has grown in sophistication We're gonna go take this market that wasn't segmented And we're going to make it a finer grain segmentation, and we're going to really understand the needs of these customers and take this wonderful platform we've built and offered these solutions or these features to this market segment, these features to this market segment.

And after we did that work with that client. Their sales returned to a healthy growing number because people bought what was relevant for them.

[00:30:49] Joe Krebs: This is awesome. Luke, we started off with also with a side comment or I might have started with this agile community being in some form of transition.

Yes. And I want to end with this for our podcast as well. Now we talked a little bit more from the company's perspective, from the leadership level what I have noticed, and I don't know if you would share that thought is there's a lot of agile coaches in the transformation space and organizations, and they don't really know for sure if their work actually had an economic impact for the organization.

Like they say like it feels better or it feels, we feel more profitable, but do we have evidence of what we had before to what we have now? How could profit streams help future coaching and coaches out there on, not from a product perspective, but more from a transformations perspective, how can profit streams help them to make a case for themselves to actually say, Hey, the agile community is alive and kicking.

Why? Why? Because we are. Increasing the economic side of organizations by X, Y, Z, what kind of parameters would, what coaches need to tweak to say okay, these are like the parts of our puzzle where we can actually make a case for ourselves and say Hey, agile coaching is important. Agile teams are important.

You call them the ice cream flavors. The agile processes out there are important for you to be successful for whatever is hitting your organization in the future. How would they use that kind of profit stream?

[00:32:20] Luke Hohmann: I'm inspired by there's a gentleman that if you haven't had him on your podcast, you really need to get him.

His name is Peter Green and he runs a company called Humanizing Work. He's a known in the Scrum community and he used to be one of the leaders at Adobe and Adobe's transition to more agile practices. And I remember that one of the metrics that Peter really tracked was just one thing, defects found in production.

And remember I said that there was only, development teams need multiple metrics, but in this case, he was using the one metric that really resonated with his leaders and he showed his leaders how when defects in productions were reduced, customer satisfaction increased when customer satisfaction increased, renewals increased.

The cost of customer care went down because there's fewer defects. And fewer upset customers, developer satisfaction went up because instead of fixing bugs, you're building new features. And so what he did was. He took the time to translate something that was just a number of defects found in production into how it expressed itself in a relevant profit oriented way.

So my advice to the agile coaches out there is if you believe that you're creating a more effective, more efficient, more effective, doing the right things, more efficient, doing them effective, doing them well. If you think you're creating and contributing to this organization and, for example, I'm an agile coach and my team is quote unquote happier.

What does that actually mean? What, we know that stable teams, like we have data on stable teams, that stable teams produce fewer bugs. That's an argument for stable teams. So what is the data that shows that coach is creating an economic impact that is relevant to the organization? And I am said this for decades.

I am always concerned that people focus on trying to achieve the happiness of developers. When I think that the happiness of developers is an outcome of other elements, meaning if I'm a developer and I have Dan Pink, if I have reasonable autonomy, I have reasonable mastery, I, I have a purpose, right?

Then I'm happy. But focusing on happiness doesn't mean I'm getting autonomy. Giving me autonomy, making sure I'm trained, making sure I have a purpose. Those and I definitely think that the many of the coaches I've seen, um, they don't always understand what the deeper opportunities might be.

[00:35:08] Joe Krebs: Yeah. This is some awesome advice here. And I did not have Peter on the podcast and Peter, if you're listening to this, expect a call from me. Thank you, Luke. This was really insightful. And obviously I will share the book information for all the material on the show page of Agile FM, I just want to say thank you for sharing a very different view on things from what I had in the past in terms of guests and just chat a little bit about profit streams and make this really tangible for people of what they need to, establish within the organization to be successful and ready for the future.

[00:35:42] Luke Hohmann: Yeah. And Joe, thank you. I'm going to leave just two more things for the listeners. I think they're important right now. We do think the agile community, many of us who've been there a while. And many of the leaders, we think the agile community is in some form of transition or some form of change, which means.

It's up to you as a listener to decide what you think that future is and then work towards that future. A few years ago, my colleague Jason Tanner and I, we sat down and we were at an offsite and we said to ourselves, where do we really believe a future or part of the future of Agile has to be? And we decided that a part of the future of Agile has to be a return to the economics. of understanding profit and sustainability, and we acted accordingly, right? We wrote a book. We've got a partner program. We're doing consulting work. We're seeing our consulting business and profit streams is skyrocketing in terms of growth because we're finding that companies are going, wait a minute, You guys are right.

You're We've invested in agile. How do we measure the return and how do we make sure that we're creating a profit? So and i'm not arguing that people have to buy into our perspective What I am saying is if you assert that the agile community is changing You can't just sit there and complain about it You have to decide what part of that future you want to create And what part of that future you want to be a part of and from there?

You Your life will have purpose. Your life will have direction. And I think that's part of what's happening in the agile community right now. We're seeing this kind of Oh, what are what is our future? And where are we going to be? And how is it going to work as people are trying to decide? And I would invite people to reflect on their own and make a decision on their own about what they think that future is going to be, right?

[00:37:40] Joe Krebs: Look, there's something very similar to what my kids are hearing in school every day. Make it a great day or not, the choice is yours.

[00:37:47] Luke Hohmann: Oh, I love it. That's a great way to close. Luke, thank you so much.