Podcast appearances and mentions of jason tanner

Proft Streams BookTranscript:Agile FM radio for the agile community. Today I'm thrilled to have Luke Holman 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.

Bio Luke Hohmann is Chief Innovation Officer of Applied Frameworks. Applied Frameworks helps companies create more profitable software-enabled solutions. A serial entrepreneur, Luke founded, bootstrapped, and sold the SaaS B2B collaboration software company Conteneo to Scaled Agile, Inc. Conteneo's Weave platform is now part of SAFe Studio. A SAFe® Fellow, prolific author, and trailblazing innovator, Luke's contributions to the global agile community include contributing to SAFe, five books, Profit Streams™, Innovation Games®, Participatory Budgeting at enterprise scale, and a pattern language for market-driven roadmapping. Luke is also co-founder of Every Voice Engaged Foundation, where he partnered with The Kettering Foundation to create Common Ground for Action, the world's first scalable platform for deliberative decision-making. Luke is a former National Junior Pairs Figure Skating Champion and has an M.S.E. in Computer Science and Engineering from the University of Michigan. Luke loves his wife and four kids, his wife's cooking, and long runs in the California sunshine and Santa Cruz mountains.    Interview Highlights 01:30 Organisational Behaviour & Cognitive Psychology 06:10 Serendipity 09:30 Entrepreneurship 16:15 Applied Frameworks 20:00 Sustainability 20:45 Software Profit Streams 23:00 Business Model Canvas 24:00 Value Proposition Canvas 24:45 Setting the Price 28:45 Customer Benefit Analysis 34:00 Participatory Budgeting 36:00 Value Stream Funding 37:30 The Color of Money 42:00 Private v Public Sector 49:00 ROI Analysis 51:00 Innovation Accounting    Connecting   LinkedIn: Luke Hohmann on LinkedIn Company Website: Applied Frameworks    Books & Resources   ·         Software Profit Streams(TM): A Guide to Designing a Sustainably Profitable Business: Jason Tanner, Luke Hohmann, Federico González ·         Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers (The Strategyzer series): Alexander Osterwalder, Yves Pigneur ·         Value Proposition Design: How to Create Products and Services Customers Want (The Strategyzer Series): Alexander Osterwalder, Yves Pigneur, Gregory Bernarda, Alan Smith, Trish Papadakos ·         Innovation Games: Creating Breakthrough Products Through Collaborative Play: Luke Hohmann ·         The ‘Color of Money' Problem: Additional Guidance on Participatory Budgeting - Scaled Agile Framework ·         The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Eric Ries ·         Extreme Programming Explained: Embrace Change 2, Kent Beck, Cynthia Andres ·         The Mythical Man-Month: Essays on Software Engineering: Brooks, Frederick Phillips ·         Understanding Comics: The Invisible Art, Scott McCloud ·         Ponyboy: A Novel, Eliot Duncan ·         Lessons in Chemistry: A Novel, Bonnie Garmus, Miranda Raison, Bonnie Garmus, Pandora Sykes ·         What Happened to You?: Conversations on Trauma, Resilience, and Healing, Oprah Winfrey, Bruce D. Perry ·         Training | Applied Frameworks   Episode Transcript Intro: Hello and welcome to the Agile Innovation Leaders podcast. I'm Ula Ojiaku. On this podcast I speak with world-class leaders and doers about themselves and a variety of topics spanning Agile, Lean Innovation, Business, Leadership and much more – with actionable takeaways for you the listener.  Ula Ojiaku   So I have with me Luke Hohmann, who is a four time author, three time founder, serial entrepreneur if I say, a SAFe fellow, so that's a Skilled Agile Framework fellow, keynote speaker and an internationally recognised expert in Agile software development. He is also a proud husband and a father of four. So, Luke, I am very honoured to have you on the Agile Innovation Leaders podcast. Thank you for making the time. Luke Hohmann Thank you so much for having me, I'm very happy to be here, and hi everyone who's listening. Ula Ojiaku Yes, I'm sure they're waving back at you as well. I always start my conversations with my guests to find out about them as individuals, you know, so who is Luke? You have a BSc in Computer Science and an MSc in Computer Science and Engineering, but you also studied Cognitive Psychology and Organisational Behaviour in addition to Data Structures and Artificial Intelligence. AI is now making waves and is kind of at the forefront, which is interesting, you had the foresight to also look into these. So my question is, what took you down this path? Luke Hohmann Sure. I had a humble beginning in the world of technology. I worked for a large company, Electronic Data Systems, and it was founded in the mid 60s by a gentleman named Ross Perot, and it became a very, very large company. So my first job at Electronic Data Systems was working in a data centre, and we know what data centres are, but back then, data centres were different because they were predominantly mainframe-based data centres, and I would crawl underneath the floor, cabling the computers and cabling networking equipment. Now, when we think networking, we're really thinking one of two kinds of networking. We think of wireless networking or we think of some form of internet networking, but back in those days, there were varieties of network protocols, literally the standards that we use now weren't invented yet. So it was mainframe networking protocols and dial ups and other forms of networking protocols. From there, I worked my way from beneath the ground up. I had some great managers who saw someone who was worthy of opportunity and they gave me opportunity and it was great. And then eventually I started working in electronic data systems and there was, the first wave of AI came in the mid 80s and that's when we were doing things like building expert systems, and I managed to create with a colleague of mine, who's emerged as my best friend, a very successful implementation of an expert system, an AI-based expert system at EDS, and that motivated me to finish off my college degree, I didn't have my college degree at the time. So EDS supported me in going to the University of Michigan, where as you said, I picked up my Bachelor's and Master's degree, and my advisor at the time was Elliot Soloway, and he was doing research in how programmers program, what are the knowledge structures, what are the ways in which we think when we're programming, and I picked up that research and built programming environments, along with educational material, trying to understand how programmers program and trying to build educational material to teach programming more effectively. That's important because it ignited a lifelong passion for developing education materials, etc. Now the cognitive psychology part was handled through that vein of work, the organisational behaviour work came as I was a student at Michigan. As many of us are when we're in college, we don't make a lot of money, or at university we're not wealthy and I needed a job and so the School of Organisational Behaviour had published some job postings and they needed programmers to program software for their organisational behaviour research, and I answered those ads and I became friends and did the research for many ground-breaking aspects of organisational behaviour and I programmed, and in the process of programming for the professors who were in the School of Organisational Behaviour they would teach me about organisational behaviour and I learned many things that at the time were not entirely clear to me, but then when I graduated from university and I became a manager and I also became more involved in the Agile movement, I had a very deep foundation that has served me very well in terms of what do we mean when we say culture, or what do we mean when we talk about organisational structures, both in the small and in the large, how do we organise effectively, when should we scale, when should we not scale, etc. So that's a bit about my history that I think in terms of the early days helped inform who I am today. Ula Ojiaku Wow, who would have thought, it just reminds me of the word serendipity, you know, I guess a happy coincidence, quote unquote, and would there be examples of where the cognitive psychology part of it also helped you work-wise? Luke Hohmann Yeah, a way to think about cognitive psychology and the branch that, I mean there's, psychology is a huge branch of study, right? So cognitive psychology tends to relate to how do we solve problems, and it tends to focus on problem solving where n = 1 and what I mean by n is the number of participants, and where n is just me as an individual, how do I solve the problems that I'm facing? How do I engage in de-compositional activities or refinement or sense making? Organisational behaviour deals with n > 1. So it can deal with a team of, a para-bond, two people solving problems. It can deal with a small team, and we know through many, many, many decades of research that optimal team structures are eight people or less. I mean, we've known this for, when I say decades I mean millennia. When you look at military structure and military strategy, we know that people need to be organised into much smaller groups to be effective in problem solving and to move quickly. And then in any organisational structure, there's some notion of a team of teams or team engagement. So cognitive psychology, I think, helps leaders understand individuals and their place within the team. And now we talk about, you know, in the Agile community, we talk about things like, I want T-shaped people, I want people with common skills and their area of expertise and by organising enough of the T's, I can create a whole and complete team. I often say I don't want my database designer designing my user interface and I don't want my user interface designer optimising my back end database queries, they're different skills. They're very educated people, they're very sophisticated, but there's also the natural feeling that you and I have about how do I gain a sense of self, how do I gain a sense of accomplishment, a sense of mastery? Part of gaining a sense of mastery is understanding who you are as a person, what you're good at. In Japanese, they would call that Ikigai, right, what are the intersections of, you know, what do I love, what am I good at, what can I make a living at and what do people need, right? All of these intersections occur on an individual level, and then by understanding that we can create more effective teams. Ula Ojiaku Thank you. I've really learned something key here, the relationship between cognitive psychology and organisational behaviour, so thanks for breaking it down. Now, can we go quickly to your entrepreneurship? So there must be three times you started three times a company and you've been successful in that area. What exactly drives you when it comes to establishing businesses and then knowing when to move on? Luke Hohmann Sure. I think it's a combination of reflecting on my childhood and then looking at how that informs someone when they're older, and then opportunities, like you said, serendipity, I think that's a really powerful word that you introduced and it's a really powerful concept because sometimes the serendipity is associated with just allowing yourself to pursue something that presents itself. But when I was young, my father died and my mum had to raise six kids on her own, so my dad died when I was four, my mum raised six kids on her own. We were not a wealthy family, and she was a school teacher and one of the things that happened was, even though she was a very skilled school teacher, there were budget cuts and it was a unionised structure, and even though she was ranked very highly, she lost her job because she was low on the hiring totem pole in terms of how the union worked. It was very hard and of course, it's always hard to make budget cuts and firing but I remember when I was very young making one of those choices saying, I want to work in a field where we are more oriented towards someone's performance and not oriented on when they were hired, or the colour of their skin, or their gender or other things that to me didn't make sense that people were making decisions against. And while it's not a perfect field for sure, and we've got lots of improvement, engineering in general, and of course software engineering and software development spoke to me because I could meet people who were diverse or more diverse than in other fields and I thought that was really good. In terms of being an entrepreneur, that happened serendipitously. I was at the time, before I became an entrepreneur in my last job, was working for an Israeli security firm, and years and years ago, I used to do software anti-piracy and software security through physical dongles. This was made by a company called Aladdin Knowledge Systems in Israel, and I was the head of Engineering and Product Management for the dongle group and then I moved into a role of Business Development for the company. I had a couple of great bosses, but I also learned how to do international management because I had development teams in Israel, I had development teams in Munich, I had development teams in Portland, Oregon, and in the Bay Area, and this was in the 2000s. This is kind of pre-Agile, pre-Salt Lake City, pre-Agile Manifesto, but we were figuring things out and blending and working together. I thought things were going pretty well and I enjoyed working for the Israelis and what we were doing, but then we had the first Gulf War and my wife and I felt that maybe traveling as I was, we weren't sure what was going to happen in the war, I should choose something different. Unfortunately, by that time, we had been through the dot-bomb crisis in Silicon Valley. So it's about 2002 at the time that this was going on, and there really weren't jobs, it was a very weird time in Silicon Valley. So in late 2002, I sent an email to a bunch of friends and I said, hey, I'm going to be a consultant, who wants to hire me, that was my marketing plan, not very clever, and someone called me and said, hey, I've got a problem and this is the kind of thing that you can fix, come consult with us. And I said, great. So I did that, and that started the cleverly named Luke Hohmann Consulting, but then one thing led to another and consulting led to opportunities and growth and I've never looked back. So I think that there is a myth about people who start companies where sometimes you have a plan and you go execute your plan. Sometimes you find the problem and you're solving a problem. Sometimes the problem is your own problem, as in my case I had two small kids and a mortgage and I needed to provide for my family, and so the best way to do that at the time was to become a consultant. Since then I have engaged in building companies, sometimes some with more planning, some with more business tools and of course as you grow as an entrepreneur you learn skills that they didn't teach you in school, like marketing and pricing and business planning etc. And so that's kind of how I got started, and now I have kind of come full circle. The last company, the second last company I started was Conteneo and we ended up selling that to Scaled Agile, and that's how I joined the Scaled Agile team and that was lovely, moving from a position of being a CEO and being responsible for certain things, to being able to be part of a team again, joining the framework team, working with Dean Leffingwell and other members of the framework team to evolve the SAFe framework, that was really lovely. And then of course you get this entrepreneurial itch and you want to do something else, and so I think it comes and goes and you kind of allow yourself those opportunities. Ula Ojiaku Wow, yours is an inspiring story. And so what are you now, so you've talked about your first two Startups which you sold, what are you doing now? Luke Hohmann Yeah, so where I'm at right now is I am the Chief Innovation Officer for a company, Applied Frameworks. Applied Frameworks is a boutique consulting firm that's in a transition to a product company. So if this arm represents our product revenue and this arm represents our services revenue, we're expanding our product and eventually we'll become a product company. And so then the question is, well, what is the product that we're working on? Well, if you look at the Agile community, we've spent a lot of time creating and delivering value, and that's really great. We have had, if you look at the Agile community, we've had amazing support from our business counterparts. They've shovelled literally millions and millions of dollars into Agile training and Agile tooling and Agile transformations, and we've seen a lot of benefit from the Agile community. And when I say Agile, I don't mean SAFe or Scrum or some particular flavour of Agile, I just mean Agile in general. There's been hundreds of millions of dollars to billions of dollars shoved into Agile and we've created a lot of value for that investment. We've got fewer bugs in our software because we've got so many teams doing XP driven practices like Test Driven Development, we've got faster response times because we've learned that we can create smaller releases and we've created infrastructure that lets us do deployments automatically, even if you're doing embedded systems, we figured out how to do over the air updates, we've figured out how to create infrastructure where the cars we're driving are now getting software updates. So we've created for our business leaders lots of value, but there's a problem in that value. Our business leaders now need us to create a profit, and creating value and creating a profit are two different things. And so in the pursuit of value, we have allowed our Agile community to avoid and or atrophy on skills that are vital to product management, and I'm a classically trained Product Manager, so I've done market segmentation and market valuation and market sizing, I've done pricing, I've done licensing, I've done acquisitions, I've done compliance. But when you look at the traditional definition of a Product Owner, it's a very small subset of that, especially in certain Agile methods where Product Owners are team centric, they're internal centric. That's okay, I'm not criticising that structure, but what's happened is we've got people who no longer know how to price, how to package, how to license products, and we're seeing companies fail, investor money wasted, too much time trying to figure things out when if we had simply approached the problem with an analysis of not just what am I providing to you in terms of value, but what is that value worth, and how do I structure an exchange where I give you value and you give me money? And that's how businesses survive, and I think what's really interesting about this in terms of Agile is Agile is very intimately tied to sustainability. One of the drivers of the Agile Movement was way back in the 2000s, we were having very unsustainable practices. People would be working 60, 80, death march weeks of grinding out programmers and grinding out people, and part of the Agile Movement was saying, wait a minute, this isn't sustainable, and even the notion of what is a sustainable pace is really vital, but a company cannot sustain itself without a profit, and if we don't actually evolve the Agile community from value streams into profit streams, we can't help our businesses survive. I sometimes ask developers, I say, raise your hand if you're really embracing the idea that your job is to make more money for your company than they pay you, that's called a profit, and if that's not happening, your company's going to fail. Ula Ojiaku They'll be out of a job. Luke Hohmann You'll be out of a job. So if you want to be self-interested about your future, help your company be successful, help them make a profit, and so where I'm at right now is Applied Frameworks has, with my co-author, Jason Tanner, we have published a bold and breakthrough new book called Software Profit Streams, and it's a book that describes how to do pricing and packaging for software enabled solutions. When we say software enabled solution, we mean a solution that has software in it somehow, could be embedded software in your microwave oven, it could be a hosted solution, it could be an API for a payment processor, it could be the software in your car that I talked about earlier. So software enabled solutions are the foundation, the fabric of our modern lives. As Mark Andreessen says software is eating the world, software is going to be in everything, and we need to know how to take the value that we are creating as engineers, as developers, and convert that into pricing and licensing choices that create sustainable profits. Ula Ojiaku Wow. It's as if you read my mind because I was going to ask you about your book, Software Profit Streams, A Guide to Designing a Sustainably Profitable Business. I also noticed that, you know, there is the Profit Stream Canvas that you and your co-author created. So let's assume I am a Product Manager and I've used this, let's assume I went down the path of using the Business Model Canvas and there is the Customer Value Proposition. So how do they complement? Luke Hohmann How do they all work together? I'm glad you asked that, I think that's a very insightful question and the reason it's so helpful is because, well partly because I'm also friends with Alex Osterwalder, I think he's a dear, he's a wonderful human, he's a dear friend. So let's look at the different elements of the different canvases, if you will, and why we think that this is needed. The Business Model Canvas is kind of how am I structuring my business itself, like what are my partners, my suppliers, my relationships, my channel strategy, my brand strategy with respect to my customer segments, and it includes elements of cost, which we're pretty good at. We're pretty good at knowing our costs and elements of revenue, but the key assumption of revenue, of course, is the selling price and the number of units sold. So, but if you look at the book, Business Model Generation, where the Business Model Canvas comes from, it doesn't actually talk about how to set the price. Is the video game going to be $49? Is it going to be $59, or £49 or £59? Well, there's a lot of thought that goes into that. Then we have the Value Proposition Canvas, which highlights what are the pains the customer is facing? What are the gains that the customer is facing? What are the jobs to be done of the customer? How does my solution relate to the jobs? How does it help solve the pain the customer is feeling? How does it create gain for the customer? But if you read those books, and both of those books are on my shelf because they're fantastic books, it doesn't talk about pricing. So let's say I create a gain for you. Well, how much can I charge you for the gain that I've created? How do I structure that relationship? And how do I know, going back to my Business Model Canvas, that I've got the right market segment, I've got the right investment strategy, I might need to make an investment in the first one or two releases of my software or my product before I start to make a per unit profit because I'm evolving, it's called the J curve and the J curve is how much money am I investing before I well, I have to be able to forecast that, I have to be able to model that, but the key input to that is what is the price, what is the mechanism of packaging that you're using, is it, for example, is it per user in a SAS environment or is it per company in a SAS environment? Is it a meter? Is it like an API transaction using Stripe or a payment processor, Adyen or Stripe or Paypal or any of the others that are out there? Or is it an API call where I'm charging a fraction of a penny for any API call? All of those elements have to be put into an economic model and a forecast has to be created. Now, what's missing about this is that the Business Model Canvas and the Value Proposition Canvas don't give you the insight on how to set the price, they just say there is a price and we're going to use it in our equations. So what we've done is we've said, look, setting the price is itself a complex system, and what I mean by a complex system is that, let's say that I wanted to do an annual license for a new SAS offering, but I offer that in Europe and now my solution is influenced or governed by GDPR compliance, where I have data retention and data privacy laws. So my technical architecture that has to enforce the license, also has to comply with something in terms of the market in which I'm selling. This complex system needs to be organised, and so what canvases do is in all of these cases, they let us take a complex system and put some structure behind the choices that we're making in that complex system so that we can make better choices in terms of system design. I know how I want this to work, I know how I want this to be structured, and therefore I can make system choices so the system is working in a way that benefits the stakeholders. Not just me, right, I'm not the only stakeholder, my customers are in this system, my suppliers are in this system, society itself might be in the system, depending on the system I'm building or the solution I'm building. So the canvases enable us to make system level choices that are hopefully more effective in achieving our goals. And like I said, the Business Model Canvas, the Value Proposition Canvas are fantastic, highly recommended, but they don't cover pricing. So we needed something to cover the actual pricing and packaging and licensing. Ula Ojiaku Well, that's awesome. So it's really more about going, taking a deeper dive into thoughtfully and structurally, if I may use that word, assessing the pricing. Luke Hohmann Yeah, absolutely. Ula Ojiaku Would you say that in doing this there would be some elements of, you know, testing and getting feedback from actual customers to know what price point makes sense? Luke Hohmann Absolutely. There's a number of ways in which customer engagement or customer testing is involved. The very first step that we advocate is a Customer Benefit Analysis, which is what are the actual benefits you're creating and how are your customers experiencing those benefits. Those experiences are both tangible and intangible and that's another one of the challenges that we face in the Agile community. In general, the Agile community spends a little bit more time on tangible or functional value than intangible value. So we, in terms of if I were to look at it in terms of a computer, we used to say speeds and feeds. How fast is the processor? How fast is the network? How much storage is on my disk space? Those are all functional elements. Over time as our computers have become plenty fast or plenty storage wise for most of our personal computing needs, we see elements of design come into play, elements of usability, elements of brand, and we see this in other areas. Cars have improved in quality so much that many of us, the durability of the car is no longer a significant attribute because all cars are pretty durable, they're pretty good, they're pretty well made. So now we look at brand, we look at style, we look at aesthetics, we look at even paying more for a car that aligns with our values in terms of the environment. I want to get an EV, why, because I want to be more environmentally conscious. That's a value driven, that's an intangible factor. And so our first step starts with Customer Benefit Analysis looking at both functional or tangible value and intangible value, and you can't do that, as you can imagine, you can't do that without having customer interaction and awareness with your stakeholders and your customers, and that also feeds throughout the whole pricing process. Eventually, you're going to put your product in a market, and that's a form itself of market research. Did customers buy, and if they didn't buy, why did they not buy? Is it poorly packaged or is it poorly priced? These are all elements that involve customers throughout the process. Ula Ojiaku If I may, I know we've been on the topic of your latest book Software Profit Streams. I'm just wondering, because I can't help but try to connect the dots and I'm wondering if there might be a connection to one of your books, Innovation Games: Creating Breakthrough Products Through Collaborative Play, something like buy a feature in your book, that kind of came to mind, could there be a way of using that as part of the engagement with customers in setting a pricing strategy? I may be wrong, I'm just asking a question. Luke Hohmann I think you're making a great connection. There's two forms of relationship that Innovation Games and the Innovation Games book have with Software Profit Streams. One is, as you correctly noted, just the basics of market research, where do key people have pains or gains and what it might be worth. That work is also included in Alex Osterwalder's books, Value Proposition Design for example, when I've been doing Value Proposition Design and I'm trying to figure out the customer pains, you can use the Innovation Games Speed Boat. And when I want to figure out the gains, I can use the Innovation Game Product Box. Similarly, when I'm figuring out pricing and licensing, a way, and it's a very astute idea, a way to understand price points of individual features is to do certain kinds of market research. One form of market research you can do is Buy-a-Feature, which gives a gauge of what people are willing or might be willing to pay for a feature. It can be a little tricky because the normal construction of Buy-a-Feature is based on cost. However, your insight is correct, you can extend Buy-a-Feature such that you're testing value as opposed to cost, and seeing what, if you take a feature that costs X, but inflate that cost by Y and a Buy-a-Feature game, if people still buy it, it's a strong signal strength that first they want it, and second it may be a feature that you can, when delivered, would motivate you to raise the price of your offering and create a better profit for your company. Ula Ojiaku Okay, well, thank you. I wasn't sure if I was on the right lines. Luke Hohmann It's a great connection. Ula Ojiaku Thanks again. I mean, it's not original. I'm just piggybacking on your ideas. So with respect to, if we, if you don't mind, let's shift gears a bit because I know that, or I'm aware that whilst you were with Scaled Agile Incorporated, you know, you played a key part in developing some of their courses, like the Product POPM, and I think the Portfolio Management, and there was the concept about Participatory Budgeting. Can we talk about that, please? Luke Hohmann I'd love to talk about that, I mean it's a huge passion of mine, absolutely. So in February of 2018, I started working with the framework team and in December of 2018, we talked about the possibility of what an acquisition might look like and the benefits it would create, which would be many. That closed in May of 2019, and in that timeframe, we were working on SAFe 5.0 and so there were a couple of areas in which I was able to make some contributions. One was in Agile product delivery competency, the other was in lean portfolio management. I had a significant hand in restructuring or adding the POPM, APM, and LPM courses, adding things like solutions by horizons to SAFe, taking the existing content on guardrails, expanding it a little bit, and of course, adding Participatory Budgeting, which is just a huge passion of mine. I've done Participatory Budgeting now for 20 years, I've helped organisations make more than five billions of dollars of investment spending choices at all levels of companies, myself and my colleagues at Applied Frameworks, and it just is a better way to make a shared decision. If you think about one of the examples they use about Participatory Budgeting, is my preferred form of fitness is I'm a runner and so, and my wife is also a fit person. So if she goes and buys a new pair of shoes or trainers and I go and buy a new pair of trainers, we don't care, because it's a small purchase. It's frequently made and it's within the pattern of our normal behaviour. However, if I were to go out and buy a new car without involving her, that feels different, right, it's a significant purchase, it requires budgeting and care, and is this car going to meet our needs? Our kids are older than your kids, so we have different needs and different requirements, and so I would be losing trust in my pair bond with my wife if I made a substantial purchase without her involvement. Well, corporations work the same way, because we're still people. So if I'm funding a value stream, I'm funding the consistent and reliable flow of valuable items, that's what value stream funding is supposed to do. However, if there is a significant investment to be made, even if the value stream can afford it, it should be introduced to the portfolio for no other reason than the social structure of healthy organisations says that we do better when we're talking about these things, that we don't go off on our own and make significant decisions without the input of others. That lowers transparency, that lowers trust. So I am a huge advocate of Participatory Budgeting, I'm very happy that it's included in SAFe as a recommended practice, both for market research and Buy-a-Feature in APM, but also more significantly, if you will, at the portfolio level for making investment decisions. And I'm really excited to share that we've just published an article a few weeks ago about Participatory Budgeting and what's called The Color of Money, and The Color of Money is sometimes when you have constraints on how you can spend money, and an example of a constraint is let's say that a government raised taxes to improve transportation infrastructure. Well, the money that they took in is constrained in a certain way. You can't spend it, for example, on education, and so we have to show how Participatory Budgeting can be adapted to have relationships between items like this item requires this item as a precedent or The Color of Money, constraints of funding items, but I'm a big believer, we just published that article and you can get that at the Scaled Agile website, I'm a big believer in the social power of making these financial decisions and the benefits that accrue to people and organisations when they collaborate in this manner. Ula Ojiaku Thanks for going into that, Luke. So, would there be, in your experience, any type of organisation that's participatory? It's not a leading question, it's just genuine, there are typically outliers and I'm wondering in your experience, and in your opinion, if there would be organisations that it might not work for? Luke Hohmann Surprisingly, no, but I want to add a few qualifications to the effective design of a Participatory Budgeting session. When people hear Participatory Budgeting, there's different ways that you would apply Participatory Budgeting in the public and private sector. So I've done citywide Participatory Budgeting in cities and if you're a citizen of a city and you meet the qualifications for voting within that jurisdiction, in the United States, it's typically that you're 18 years old, in some places you have to be a little older, in some places you might have other qualifications, but if you're qualified to participate as a citizen in democratic processes, then you should be able to participate in Participatory Budgeting sessions that are associated with things like how do we spend taxes or how do we make certain investments. In corporations it's not quite the same way. Just because you work at a company doesn't mean you should be included in portfolio management decisions that affect the entire company. You may not have the background, you may not have the training, you may be what my friends sometimes call a fresher. So I do a lot of work overseas, so freshers, they just may not have the experience to participate. So one thing that we look at in Participatory Budgeting and SAFe is who should be involved in the sessions, and that doesn't mean that every single employee should always be included, because their background, I mean, they may be a technical topic and maybe they don't have the right technical background. So we work a little bit harder in corporations to make sure the right people are there. Now, of course, if we're going to make a mistake, we tend to make the mistake of including more people than excluding, partly because in SAFe Participatory Budgeting, it's a group of people who are making a decision, not a one person, one vote, and that's really profoundly important because in a corporation, just like in a para-bond, your opinion matters to me, I want to know what you're thinking. If I'm looking in, I'll use SAFe terminology, if I'm looking at three epics that could advance our portfolio, and I'm a little unsure about two of those epics, like one of those epics, I'm like, yeah, this is a really good thing, I know a little bit about it, this matters, I'm going to fund this, but the other two I'm not so sure about, well, there's no way I can learn through reading alone what the opinions of other people are, because, again, there's these intangible factors. There's these elements that may not be included in an ROI analysis, it's kind of hard to talk about brand and an ROI analysis - we can, but it's hard, so I want to listen to how other people are talking about things, and through that, I can go, yeah, I can see the value, I didn't see it before, I'm going to join you in funding this. So that's among the ways in which Participatory Budgeting is a little different within the private sector and the public sector and within a company. The only other element that I would add is that Participatory Budgeting gives people the permission to stop funding items that are no longer likely to meet the investment or objectives of the company, or to change minds, and so one of the, again, this is a bit of an overhang in the Agile community, Agile teams are optimised for doing things that are small, things that can fit within a two or three week Sprint. That's great, no criticism there, but our customers and our stakeholders want big things that move the market needle, and the big things that move the market needle don't get done in two or three weeks, in general, and they rarely, like they require multiple teams working multiple weeks to create a really profoundly new important thing. And so what happens though, is that we need to make in a sense funding commitments for these big things, but we also have to have a way to change our mind, and so traditional funding processes, they let us make this big commitment, but they're not good at letting us change our mind, meaning they're not Agile. Participatory Budgeting gives us the best of both worlds. I can sit at the table with you and with our colleagues, we can commit to funding something that's big, but six months later, which is the recommended cadence from SAFe, I can come back to that table and reassess and we can all look at each other, because you know those moments, right, you've had that experience in visiting, because you're like looking around the table and you're like, yeah, this isn't working. And then in traditional funding, we keep funding what's not working because there's no built-in mechanism to easily change it, but in SAFe Participatory Budgeting, you and I can sit at the table and we can look at each other with our colleagues and say, yeah, you know, that initiative just, it's not working, well, let's change our mind, okay, what is the new thing that we can fund? What is the new epic? And that permission is so powerful within a corporation. Ula Ojiaku Thanks for sharing that, and whilst you were speaking, because again, me trying to connect the dots and thinking, for an organisation that has adopted SAFe or it's trying to scale Agility, because like you mentioned, Agile teams are optimised to iteratively develop or deliver, you know, small chunks over time, usually two to three weeks, but, like you said, there is a longer time horizon spanning months, even years into the future, sometimes for those worthwhile, meaty things to be delivered that moves the strategic needle if I may use that buzzword. So, let's say we at that lean portfolio level, we're looking at epics, right, and Participatory Budgeting, we are looking at initiatives on an epic to epic basis per se, where would the Lean Startup Cycle come in here? So is it that Participatory Budgeting could be a mechanism that is used for assessing, okay, this is the MVP features that have been developed and all that, the leading indicators we've gotten, that's presented to the group, and on that basis, we make that pivot or persevere or stop decision, would that fit in? Luke Hohmann Yeah, so let's, I mean, you're close, but let me make a few turns and then it'll click better. First, let's acknowledge that the SAFe approach to the Lean Startup Cycle is not the Eric Ries approach, there are some differences, but let's separate how I fund something from how I evaluate something. So if I'm going to engage in the SAFe Lean Startup Cycle, part of that engagement is to fund an MVP, which is going to prove or disprove a given hypothesis. So that's an expenditure of money. Now there's, if you think about the expenditure of money, there's minimally two steps in this process - there's spending enough money to conduct the experiments, and if those experiments are true, making another commitment to spend money again, that I want to spend it. The reason this is important is, let's say I had three experiments running in parallel and I'm going to use easy round numbers for a large corporation. Let's say I want to run three experiments in parallel, and each experiment costs me a million pounds. Okay. So now let's say that the commercialisation of each of those is an additional amount of money. So the portfolio team sits around the table and says, we have the money, we're going to fund all three. Okay, great. Well, it's an unlikely circumstance, but let's say all three are successful. Well, this is like a venture capitalist, and I have a talk that I give that relates the funding cycle of a venture capitalist to the funding cycle of an LPM team. While it's unlikely, you could have all three become successful, and this is what I call an oversubscribed portfolio. I've got three great initiatives, but I can still only fund one or two of them, I still have to make the choice. Now, of course, I'm going to look at my economics and let's say out of the three initiatives that were successfully proven through their hypothesis, let's say one of them is just clearly not as economically attractive, for whatever reason. Okay, we get rid of that one, now, I've got two, and if I can only fund one of them, and the ROI, the hard ROI is roughly the same, that's when Participatory Budgeting really shines, because we can have those leaders come back into the room, and they can say, which choice do we want to make now? So the evaluative aspect of the MVP is the leading indicators and the results of the proving or disproving of the hypotheses. We separate that from the funding choices, which is where Participatory Budgeting and LPM kick in. Ula Ojiaku Okay. So you've separated the proving or disproving the hypothesis of the feature, some of the features that will probably make up an epic. And you're saying the funding, the decision to fund the epic in the first place is a different conversation. And you've likened it to Venture Capital funding rounds. Where do they connect? Because if they're separate, what's the connecting thread between the two? Luke Hohmann The connected thread is the portfolio process, right? The actual process is the mechanism where we're connecting these things. Ula Ojiaku OK, no, thanks for the portfolio process. But there is something you mentioned, ROI - Return On Investment. And sometimes when you're developing new products, you don't know, you have assumptions. And any ROI, sorry to put it this way, but you're really plucking figures from the air, you know, you're modelling, but there is no certainty because you could hit the mark or you could go way off the mark. So where does that innovation accounting coming into place, especially if it's a product that's yet to make contact with, you know, real life users, the customers. Luke Hohmann Well, let's go back to something you said earlier, and what you talked earlier about was the relationship that you have in market researching customer interaction. In making a forecast, let's go ahead and look at the notion of building a new product within a company, and this is again where the Agile community sometimes doesn't want to look at numbers or quote, unquote get dirty, but we have to, because if I'm going to look at building a new idea, or taking a new idea into a product, I have to have a forecast of its viability. Is it economically viable? Is it a good choice? So innovation accounting is a way to look at certain data, but before, I'm going to steal a page, a quote, from one of my friends, Jeff Patton. The most expensive way to figure this out is to actually build the product. So what can I do that's less expensive than building the product itself? I can still do market research, but maybe I wouldn't do an innovation game, maybe I'd do a formal survey and I use a price point testing mechanism like Van Westendorp Price Point Analysis, which is a series of questions that you ask to triangulate on acceptable price ranges. I can do competitive benchmarking for similar products and services. What are people offering right now in the market? Now that again, if the product is completely novel, doing competitive benchmarking can be really hard. Right now, there's so many people doing streaming that we look at the competitive market, but when Netflix first offered streaming and it was the first one, their best approach was what we call reference pricing, which is, I have a reference price for how much I pay for my DVDs that I'm getting in the mail, I'm going to base my streaming service kind of on the reference pricing of entertainment, although that's not entirely clear that that was the best way to go, because you could also base the reference price on what you're paying for a movie ticket and how many, but then you look at consumption, right, because movie tickets are expensive, so I only go to a movie maybe once every other month, whereas streaming is cheap and so I can change my demand curve by lowering my price. But this is why it's such a hard science is because we have this notion of these swirling factors. Getting specifically back to your question about the price point, I do have to do some market research before I go into the market to get some forecasting and some confidence, and research gives me more confidence, and of course, once I'm in the market, I'll know how effective my research matched the market reality. Maybe my research was misleading, and of course, there's some skill in designing research, as you know, to get answers that have high quality signal strength. Ula Ojiaku Thanks for clarifying. That makes perfect sense to me. Luke Hohmann It's kind of like a forecast saying, like there's a group of Agile people who will say, like, you shouldn't make forecasts. Well, I don't understand that because that's like saying, and people will say, well, I can't predict the future. Well, okay, I can't predict when I'm going to retire, but I'm planning to retire. I don't know the date of my exact retirement, but my wife and I are planning our retirement, and we're saving, we're making certain investment choices for our future, because we expect to have a future together. Now our kids are older than yours. My kids are now in university, and so we're closer to retirement. So what I dislike about the Agile community is people will sometimes say, well, I don't know the certainty of the event, therefore, I can't plan for it. But that's really daft, because there are many places in like, you may not for the listeners, her daughter is a little younger than my kids, but they will be going to university one day, and depending on where they go, that's a financial choice. So you could say, well, I don't know when she's going to university, and I can't predict what university she's going to go to, therefore I'm not going to save any money. Really? That doesn't make no sense. So I really get very upset when you have people in the agile community will say things like road mapping or forecasting is not Agile. It's entirely Agile. How you treat it is Agile or not Agile. Like when my child comes up to me and says, hey, you know about that going to university thing, I was thinking of taking a gap year. Okay, wait a minute, that's a change. That doesn't mean no, it means you're laughing, right? But that's a change. And so we respond to change, but we still have a plan. Ula Ojiaku It makes sense. So the reason, and I completely resonate with everything you said, the reason I raised that ROI and it not being known is that in some situations, people might be tempted to use it to game the budget allocation decision making process. That's why I said you would pluck the ROI. Luke Hohmann Okay, let's talk about that. We actually address this in our recent paper, but I'll give you my personal experience. You are vastly more likely to get bad behaviour on ROI analysis when you do not do Participatory Budgeting, because there's no social construct to prevent bad behaviour. If I'm sitting down at a table and that's virtual or physical, it doesn't matter, but let's take a perfect optimum size for a Participatory Budgeting group. Six people, let's say I'm a Director or a Senior Director in a company, and I'm sitting at a table and there's another Senior Director who's a peer, maybe there's a VP, maybe there's a person from engineering, maybe there's a person from sales and we've got this mix of people and I'm sitting at that table. I am not incented to come in with an inflated ROI because those people are really intelligent and given enough time, they're not going to support my initiative because I'm fibbing, I'm lying. And I have a phrase for this, it's when ROI becomes RO-lie that it's dangerous. And so when I'm sitting at that table, what we find consistently, and one of the clients that we did a fair amount of Participatory Budgeting for years ago with Cisco, what we found was the leaders at Cisco were creating tighter, more believable, and more defensible economic projections, precisely because they knew that they were going to be sitting with their peers, and it didn't matter. It can go both ways. Sometimes people will overestimate the ROI or they underestimate the cost. Same outcome, right? I'm going to overestimate the benefit, and people would be like, yeah, I don't think you can build that product with three teams. You're going to need five or six teams and people go, oh, I can get it done with, you know, 20 people. Yeah, I don't think so, because two years ago, we built this product. It's very similar, and, you know, we thought we could get it done with 20 people and we couldn't. We really needed, you know, a bigger group. So you see the social construct creating a more believable set of results because people come to the Participatory Budgeting session knowing that their peers are in the room. And of course, we think we're smart, so our peers are as smart as we are, we're all smart people, and therefore, the social construct of Participatory Budgeting quite literally creates a better input, which creates a better output. Ula Ojiaku That makes sense, definitely. Thanks for sharing that. I've found that very, very insightful and something I can easily apply. The reasoning behind it, the social pressure, quote unquote, knowing that you're not just going to put the paper forward but you'd have to defend it in a credible, believable way make sense. So just to wrap up now, what books have you found yourself recommending to people the most, and why? Luke Hohmann It's so funny, I get yelled at by my wife for how many books I buy. She'll go like “It's Amazon again. Another book. You know, there's this thing called the library.” Ula Ojiaku You should do Participatory Budgeting for your books then sounds like, sorry. Luke Hohmann No, no, I don't, I'd lose. Gosh, I love so many books. So there's a few books that I consider to be my go-to references and my go-to classics, but I also recommend that people re-read books and sometimes I recommend re-reading books is because you're a different person, and as you age and as you grow and you see things differently and in fact, I'm right now re-reading and of course it goes faster, but I'm re-reading the original Extreme Programming Explained by Kent Beck, a fantastic book. I just finished reading a few new books, but let me let me give you a couple of classics that I think everyone in our field should read and why they should read them. I think everyone should read The Mythical Man-Month by Fred Brooks because he really covers some very profound truths that haven't changed, things like Brooks Law, which is adding programmers to a late project, makes it later. He talks about the structure of teams and how to scale before scaling was big and important and cool. He talks about communication and conceptual integrity and the role of the architect. The other book that I'm going to give, which I hope is different than any book that anyone has ever given you, because it's one of my absolute favourite books and I give them away, is a book called Understanding Comics by Scott McCloud. Comics or graphic novels are an important medium for communication, and when we talk about storytelling and we talk about how to frame information and how to present information, understanding comics is profoundly insightful in terms of how to present, share, show information. A lot of times I think we make things harder than they should be. So when I'm working with executives and some of the clients that I work with personally, when we talk about our epics, we actually will tell stories about the hero's journey and we actually hire comic book artists to help the executives tell their story in a comic form or in a graphic novel form. So I absolutely love understanding comics. I think that that's really a profound book. Of course you mentioned Alex Osterwalder's books, Business Model Generation, Business Model Canvas. Those are fantastic books for Product Managers. I also, just looking at my own bookshelves, of course, Innovation Games for PMs, of course Software Profit Streams because we have to figure out how to create sustainability, but in reality there's so many books that we love and that we share and that we grow together when we're sharing books and I'll add one thing. Please don't only limit your books to technical books. We're humans too. I recently, this week and what I mean recent I mean literally this weekend I was visiting one of my kids in Vermont all the way across the country, and so on the plane ride I finished two books, one was a very profound and deeply written book called Ponyboy. And then another one was a very famous book on a woman protagonist who's successful in the 60s, Lessons in Chemistry, which is a new book that's out, and it was a super fun light read, some interesting lessons of course, because there's always lessons in books, and now if it's okay if I'm not overstepping my boundaries, what would be a book that you'd like me to read? I love to add books to my list. Ula Ojiaku Oh my gosh, I didn't know. You are the first guest ever who's twisted this on me, but I tend to read multiple books at a time. Luke Hohmann Only two. Ula Ojiaku Yeah, so, and I kind of switch, maybe put some on my bedside and you know there's some on my Kindle and in the car, just depending. So I'm reading multiple books at a time, but based on what you've said the one that comes to mind is the new book by Oprah Winfrey and it's titled What Happened to You? Understanding Trauma, because like you said, it's not just about reading technical books and we're human beings and we find out that people behave probably sometimes in ways that are different to us, and it's not about saying what's wrong with you, because there is a story that we might not have been privy to, you know, in terms of their childhood, how they grew up, which affected their worldview and how they are acting, so things don't just suddenly happen. And the question that we have been asked and we sometimes ask of people, and for me, I'm reading it from a parent's perspective because I understand that even more so that my actions, my choices, they play a huge, you know, part in shaping my children. So it's not saying what's wrong with you? You say, you know, what happened to you? And it traces back to, based on research, because she wrote it with a renowned psychologist, I don't know his field but a renowned psychologist, so neuroscience-based psychological research on human beings, attachment theory and all that, just showing how early childhood experiences, even as early as maybe a few months old, tend to affect people well into adulthood. So that would be my recommendation. Luke Hohmann Thank you so much. That's a gift. Ula Ojiaku Thank you. You're the first person to ask me. So, my pleasure. So, before we go to the final words, where can the audience find you, because you have a wealth of knowledge, a wealth of experience, and I am sure that people would want to get in touch with you, so how can they do this please? Luke Hohmann Yeah, well, they can get me on LinkedIn and they can find me at Applied Frameworks. I tell you, I teach classes that are known to be very profound because we always reserve, myself and the instructors at Applied Frameworks, we have very strong commitments to reserving class time for what we call the parking lot or the ask me anything question, which are many times after I've covered the core material in the class, having the opportunity to really frame how to apply something is really important. So I would definitely encourage people to take one of my classes because you'll not get the material, you'll get the reasons behind the material, which means you can apply it, but you'll also be able to ask us questions and our commitment as a company is you can ask us anything and if we don't know the answer, we'll help you find it. We'll help you find the expert or the person that you need talk to, to help you out and be successful. And then, and I think in terms of final words, I will simply ask people to remember that we get to work in the most amazing field building things for other people and it's joyful work, and we, one of my phrases is you're not doing Agile, if you're not having fun at work, there's something really wrong, there's something missing, yeah we need to retrospect and we need to improve and we need to reflect and all those important things, absolutely, but we should allow ourselves to experience the joy of serving others and being of service and building things that matter. Ula Ojiaku I love the concept of joyful Agile and getting joy in building things that matter, serving people and may I add also working together with amazing people, and for me it's been a joyful conversation with you, Luke, I really appreciate you making the time, I am definitely richer and more enlightened as a result of this conversation, so thank you so much once more. Luke Hohmann Thank you so much for having me here, thank you everyone for listening with us. Ula Ojiaku  My pleasure. That's all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com or your favourite podcast provider. Also share with friends and do leave a review on iTunes. This would help others find this show. I'd also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com Take care and God bless!   

We have a full show for you people. First we talk to Jason Tanner about his 7th place finish at Rocky Raccoon 100 miler in Texas, then Grayce tells us all the deets on her weekend run at the DUC 100K. What a great show for our 50th episode! Join us!

In this episode of OzCast, Jason Tanner dives beneath the surface of South Australian waters to unveil how he is working to “green the blue” by dropping sandbags in strategic areas to bring back the lost seagrass meadows of yesteryear. After spending over 25 years developing this technique from the ground up, he explains how his work went from an idea to a now industrial-level program that sees tens of thousands of bags being deployed every year.   Jason has 30 years' experience overall in marine ecology, working in tropical and temperate systems. He has published over 80 papers, most in high-profile international journals, and numerous reports. He undertakes field and laboratory studies of marine ecosystems and also has a strong grounding in statistics and mathematical modelling.  His first exposure to seagrass was as a teenager snorkelling in the coastal lakes of southern NSW, although it would be many years before he would return to them, taking a detour via the coral reefs of the Great Barrier Reef in between.    This detour involved a PhD and postdoctoral studies on corals at Heron Island, before moving to the South Australian Research and Development Institute to study the impacts of prawn trawling on the seafloor.  From here he became interested in the way fragmentation of seagrass habitats influenced the fauna that lived in them, which then progressed to an interest in the seagrasses themselves and how to reverse the extensive habitat loss seen along the Adelaide coast (and elsewhere).   Throughout the episode, Jason explains that this interest led him to develop novel low-cost techniques for seagrass restoration tailored to the main species found in South Australia.  His hessian sandbag technique can be deployed for 5-10% of the cost of traditional transplantation involving divers and doesn't require the removal of seagrass from a donor meadow.    Instead, it relies on providing a firm substrate for naturally present seedlings to attach to (for wireweed - Amphibolis) or collecting beachcast fruits that would otherwise dehydrate and be lost (for strapweed – Posidonia australis).  He is now in the process of establishing a 20-hectare restoration plot just north of Adelaide, funded by the Commonwealth Government, which will be the largest single seagrass restoration in Australia.   Jason offers a wealth of information on how programs like this develop and transform, to the point where he is now dropping over 25,000 bags in a single deployment.   Having spent countless hours researching seagrass, Jason highlights the impacts that seagrass has faced on the South Australia metropolitan coastline. Over the last half-century or so, more than 6,000 hectares of seagrass has been lost off the Adelaide coast due to anthropogenic nutrient and sediment inputs.  This loss has led to coastal erosion, decreased habitat, loss of carbon storage and decreased fish abundance.  Recent improvements to wastewater treatment and stormwater runoff have led to some natural recovery, but changes in sand movement resulting from the loss now prevent the recolonization of many areas.  While the hessian bag method has resulted in the successful establishment of small patches of seagrasses that have persisted for around a decade, and which are now functioning like natural patches due to colonisation by other marine plants and animals, the development of the technique has not been straightforward.  Throughout the episode, Jason unveils how he has had to refine the technique over the years when it comes to developing of a good understanding of the timing of recruitment, and methods to ensure the maximum number of bags are dropped in a given season.   Jason explains that the sandbags provide a stable environment that overcomes sand movement and allows the seedlings to establish, before the bags rot away. Without the bags, seedlings don't have much to attach to, and any that do settle get washed away in storms. This approach avoids the need to use divers, costs less than 10 per cent of what traditional restoration techniques that involve the direct planting of seagrass cost, and avoids disturbing remaining seagrass beds to obtain planting material.    Seedlings of tape weed can also be pre-planted into the bags following their summer fruiting period before they are dropped to the seafloor. This area has experienced extensive seagrass loss over the last 60 to 80 years due to decreased water quality. While water quality has improved, there are only limited signs of natural seagrass recovery. 

Time for a Check Up Suicide Prevention with Jason Tanner from Alta Pointe

On this week's Time For a Check Up Sean talked to Jason Tanner from Altapointe about job stress.  Successful business owners recognize that everyday life stresses can impact on-the-job performance. Studies show that employees trying to cope with distressing personal issues are more likely to be involved in accidents, make imprudent decisions, or abuse sick leave. Jason offers tips to help manage employee mental health.   

Luke Hohmann I am a four time author, three time founder, a keynote speaker and internationally recognized expert in Agile Software Development. Coming from Silicon Valley, I know how often founders focus on building companies to flip. My passion is building companies that make the world better. At FirstRoot, Inc. our mission is to create the next generation of impact investors. We want to get $1K into 1M schools globally and watch what happens when youth control $1B in capital. The Every Voice Engaged Foundation is a 501c3 nonprofit that helps citizens, governments and nonprofit organizations collaboratively solve problems that are unsolvable without civic engagement. EVEF has been a leader in the Participatory Budgeting movement, helping citizens prioritize hundreds of millions of dollars through Budget Games. Conteneo, Inc. was acquired by Scaled Agile, Inc. With our extraordinary development team, we created the Weave, Strategy Engine and Knowsy® decision agility platforms. In partnership with The Kettering Foundation (www.kettering.org), Conteneo created Common Ground for Action, the first scalable platform for deliberative decision-making. At Applied Frameworks, we make the world better by helping our customers create sustainably profitable businesses. My most recent book, Software Profit Solutions, is co-authored with Jason Tanner and shares key insights from our experience to help transform businesses through profitable, sustainable software solutions. Join our newsletter linked in my profile above for periodic Profit Streams updates and to be notified when the book is available! https://profit-streams.com/book We talk about:   What is system thinking and how is it used? What are some of the tools one would use to navigate the “Fog of uncertainty”? When should one think about raising prices? When does software eat Hardware? What is Solution Life-cycle management?   Connect with Luke https://www.linkedin.com/in/lukehohmann/ Website https://appliedframeworks.com/

In this episode David and Gary talk with CEO and CO-Author Jason Tanner about all things Agility, SaaS and not getting hung up on perfection…Links:Jason LinkedInProfit Streams BookApplied Frameworks___________________________________ Submit Your Questions to: hello@thebigpixel.net OR comment on our YouTube videos! - Big Pixel, LLC - YouTube Our Hosts David Baxter - CEO of Big Pixel Gary Voigt - Creative Director at Big Pixel The Podcast David Baxter has been designing, building, and advising startups and businesses for over ten years. His passion, knowledge, and brutal honesty have helped dozens of companies get their start. In Biz/Dev, David and award-winning Creative Director Gary Voigt talk about current events and how they affect the world of startups, entrepreneurship, software development, and culture. Contact Us hello@thebigpixel.net 919-275-0646 www.thebigpixel.net FB | IG | LI | TW | TT : @bigpixelNC Big Pixel 1772 Heritage Center Dr Suite 201 Wake Forest, NC 27587 Music by: BLXRR

Luke Hohmann discusses his book, co-authored Jason Tanner, “Software Profit Streams.” Luke is Chief Innovation Officer of Applied Frameworks and an expert in the art and practice of Agile and Scrum. In fact, Luke is one of six people in the world recognized as a principal contributor to the Scaled Agile Framework. Listen for advice and action items for designing a sustainably profitable software development business. Host, Kevin Craine Do you want to be a guest?

Profit is your key to surviving. Without profit, you cannot maintain or grow your business. Without profit, you cannot serve your customers or provide benefits to your employees. Welcome to the Author Hour ... The post Software Profit Streams: Jason Tanner & Luke Hohmann appeared first on Author Hour.

Luke Hohmann is a startup founder, consultant, SAFe framework contributor and co-author of the upcoming book "Software Value Streams". Luke wants to help agile teams connect their own value delivery with profit, the value that the leadership team really cares about, and set up whole organisations for success. We chatted about some themes from the book, with a gentle detour into Scaled Agile territory for good measure. A message from this episode's sponsor - Skiplevel This episode is sponsored by Skiplevel. Do you struggle with communicating with dev teams and understanding technical terminology and concepts? On episode 98, I hosted Irene Yu, founder of Skiplevel, an on-demand training program that helps professionals and teams become more technical in just 5 weeks... All without learning to code. Learn the knowledge and skills you need to better communicate with devs and become more confident in your day-to-day role with the Skiplevel program. You can use referral code OKIP to support this podcast! Episode highlights: 1. A software profit stream is the necessary evolution of a value stream Agile folk talk about value all the time but how does that map to company priorities? There are structures & systems we need to use to turn "value" into profit & meet the company's financial goals. 2. Most books about pricing & licensing are old school and written for boomers - few of them cover software Pricing is not a number, it's a system, and it's a team sport. Your software solution's pricing & packaging should evolve over the product lifecycle. 3. Value is a set of relationships between nodes that impact each other Value doesn't occur in isolation; consider the system. if you're building a solution to improve thing A in a positive way, but it negatively impacts thing B then the solution is intrinsically less valuable 4. Customers don't care about your profits... ... but they do care about your ability to sustainably serve them a solution they need. But, beware! It's possible to build too much quality and provide more than your customers are prepared to pay for. 5. Product management is an infinite game We play games for leisure until they're boring. At work, we serve our customers until it's boring to the business. If we play the game well we don't win the game, we simply win the right to play again. Coming soon! Buy "Software Profit Streams" "Profit is your key to survival. Without profit, you cannot maintain or grow your business. Without profit, you cannot serve your customers or provide benefits to your employees. Without profit, investors have no reason to invest. Without profit, the goals of the business are unattainable. In Software Profit Streams, serial entrepreneurs Jason Tanner and Luke Hohmann unveil the essential tools and processes for creating profitable software-enabled solutions that have long-term impact." Book link coming soon! Check out Luke's article on startup SAFe Not convinced by SAFe in startups? Luke wants you to think again. Check the article out here. Contact Luke You can catch up with Luke on his website. You can also connect with him on LinkedIn.

This episode is a departure from the typical FOAMcast clinical content, we will be back with strictly clinical content soon. In May 2022, I came across a fellow passenger and stranger in cardiac arrest in the airport. A small team of strangers, including an emergency medicine resident, Dr. Jason Tanner, and an emergency department technician, Angel, assembled to treat this passenger. Billy Frolick, a writer and our patient that day, shares his perspective on his case with us.  In addition, we highlight important clinical pearls, notably the importance of continuous chest compressions and early defibrillation. For more on not doing pulse checks, see this podcast: https://foamcast.org/2022/09/04/pulse-checks-during-cardiopulmonary-resuscitation/ .  

Searching and then rescuing someone starts with knowing how different people of different ages will behave when they get lost.  In this podcast  Dr. Jason Tanner outlines the behavior of lost individuals. 

Today’s guest is Jason Tanner. Jason is the CEO and Co-Founder of Applied Frameworks, a consulting firm based in North Carolina. When the world shut down, Jason had 10 employees whose livelihoods and families’ security depended on his ability to pivot. Luckily, Jason served nine years in the Marine Corp, and knew that open, consistent, and efficient communication would be the key moving forward.As you’re about to find out, Jason has a direct, linear method of communicating. It actually caught me off-guard, as I’m used to having free-flowing conversations on this podcast, full of diversions and tangents. Instead, Jason is laser-focused.And as far as I can tell, that’s why he still has 10 employees today.Pay close attention not only to Jason’s content, but his method of delivery.Connect with Jasonhttps://appliedframeworks.com/

Vice President of Academic Affairs and Economic Development at Chattahoochee Technical College, Jason Tanner, is in studio for today's episode of Atlanta Real Estate Forum Radio. Joined by co-hosts Carol Morgan and Todd Schnick, Tanner discusses the several different options available at Chattahoochee Tech, new programs, his role in the college and so much more on today's Around Atlanta segment of Radio. Starting his career in higher education as an English professor, Tanner knew he was teaching a required course for most incoming students. While several students were passionate about the class, it was only a stepping stone to more desired classes for students embarking on other majors. This was one of the factors that helped Tanner discover his passion for teaching at a two-year college. Tanner began working at a community college in the area and had the opportunity to teach a myriad of different types of students. Not only were there regular college students following a traditional path, but the classroom also contained high school students looking to get a jumpstart on higher education and older adults seeking to return to school. After teaching English for several years, Tanner eventually eased into a more administrative role. Before landing his current role, Tanner was the Dean of the College of Arts and Sciences at Chattahoochee Tech. Now, Tanner is in charge of overseeing and supervising all academic instruction at the college. Chattahoochee Tech is the largest of Georgia's 22 technical colleges. Chattahoochee Tech educates almost 10,000 students a semester and services six different Georgia counties. The college is also composed of 15 to 20% dual-enrollment students. While several traditional four-year colleges in the state of Georgia are a part of the University System of Georgia, a separate system oversees most of the two-year technical colleges in the state. The Technical College System of Georgia encompasses these schools. In addition to traditional diplomas that require two years of instruction, Chattahoochee Tech also offers several certificates. These programs are specialized and can be completed in as little as eight weeks. One example is a certificate of truck driving. The associate degrees offer a wide range of courses from accounting to welding, in addition to all the normal core classes like English and math. “We prepare students for what we call middle-skill careers and jobs,” said Tanner. “Those are the things that don't require a full four-year degree like engineering, but do require more than just a high school diploma or the equivalency.” To learn more about Chattahoochee Technical College, be sure to listen to the full interview above. You can also visit www.chattahoocheetech.edu. Never miss an episode of Atlanta Real Estate Forum Radio! Subscribe to the podcast here. You can also get a recap of any past episodes on our Radio page. Georgia Residential Mortgage Licensee, License #22564. NMLS ID #6606. Subject to borrower and property qualifications. Not all applicants will qualify. New American Funding and Chattahoochee Technical College are not associated. Click here to view the terms and conditions of products mentioned during the show. Corporate office 14511 Myford Rd., Suite 100, Tustin, CA 92780. Phone: (800) 450-2010. (May/2020) New American Funding is a family-owned mortgage lender with a servicing portfolio of over 123,000 loans for $30.4 billion, 198 branches, and about 3,100 employees. The company offers several niche loan products and has made Inc. 5000's list of Fastest-Growing Companies in America six times. It has a state-of-the-art career training facility and develops innovative technology, including the GoGo LO mobile application. For more information, visit www.branch.newamericanfunding.com/Atlanta. The Atlanta Real Estate Forum Radio “All About Real Estate” segment, presented by Denim Marketing,

Vice President of Academic Affairs and Economic Development at Chattahoochee Technical College, Jason Tanner, is in studio for today’s episode of Atlanta Real Estate Forum Radio. Joined by co-hosts Carol Morgan and Todd Schnick, Tanner discusses the several different options available at Chattahoochee Tech, new programs, his role in the college and so much more […] The post Chattahoochee Tech on Around Atlanta Radio appeared first on Atlanta Real Estate Forum.

Segment with Spartan Competitor

Allen Holub on Deliver It, Jason Tanner on Drunken PM, Mary and Tom Poppendieck on Unlearn, Saron Yitbarek on Greater Than Code, and Dave Karow and Trevor Stuart on Deliver It. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting July 8, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. ALLEN HOLUB ON DELIVER IT The Deliver It podcast featured Allen Holub with host Cory Bryan. Cory started out by reviewing an article by Ron Jeffries called “Story Points Revisited.” Allen’s take is that the negatives around story points are more than just the potential for misuse; he believes story points have no value at all. He says the most important thing is to narrow your stories, not estimate them. He says estimates exist because of fear. The software development process is opaque to certain managers and, as a result, they want estimates to alleviate their fear, but when you are delivering every day, you can eliminate the fear without resorting to estimates. Cory asked Allen what product owners need to know about Agile architecture. Allen said that one of the mistakes that he sees product owners make a lot is they try to do a miniature up-front design and expect that to be implemented. When this happens, he says there is too much information captured up-front of what is going to be built during the sprint and not enough information captured during the sprint as a side effect of releasing code to users and getting their feedback. This leads to inappropriate architectures because when you do anything up-front, you start doing everything up-front. Your sprint planning starts involving architecture decisions, UI decisions, and UX decisions that may be wrong and you will not know if you are wrong until you release. In Allen’s view, the most important thing a product owner does is answer questions that come up during the course of development. He uses a “two-minute rule”: if a question comes up during development, the product owner needs to be able to answer within two minutes. Allen talked about how the constraints of a bad architecture can prevent you from ever being Agile. He says, “Agile has nothing to do with standup meetings and backlog grooming and all of those. The important thing is to get stuff into your user’s hands quickly.” Allen says that the architecture has to be focused on the domain. Where systems that are wrong go wrong is that they don’t map to the domain but to the technology. A change at the story level, which is where the majority of changes come from, ends up touching all the modules or layers of your system when your architecture is mapped to your technology instead of your domain. Allen says that when he does a workshop on Agile architecture, people raise their hands about halfway through and say, “All we’re doing is domain analysis!” The fact is, if the domain and code are matched to each other, domain analysis is architecture. One of the questions Allen asks when he gets a bunch of product owners in a class is, “How many of you talk to multiple customers multiple times a day?” Maybe 5% raise their hands. So he says, “Who in the organization does talk to multiple customers multiple times a day?” This is often met with silence. He asks, “What about Sales? What about Tech Support?” He says that if you can’t respond to customer kinds of issues as well as a salesperson or a tech support person could, you don‘t know the domain well enough to be helpful to the engineering team. Cory asked Allen what he thought of the distinction between regular stories and “technical” stories. Allen says that there is no such thing as technical stories. A story describes the users of your system performing some kind of domain level work to achieve a useful outcome. Fixing some technical thing like changing the color of a button in no way makes your end users’ lives easier; it does not help them do their work. Allen says that the role of the architect in an Agile environment is very different from what we traditionally think of, just like the role of a manager in an Agile environment. In Agile environments, the job of people who are in a leadership position is to make sure that you can do your job, not to tell you what to do. They communicate a strategic requirement, provide support, and remove the obstacles. The same, he says, applies to Agile architects. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep90-agile-architecture-with-allen-holub/id966084649?i=1000441313352 Website link: http://deliveritcast.com/ep90-agile-architecture-with-allen-holub JASON TANNER ON DRUNKEN PM The Drunken PM podcast featured Jason Tanner with host Dave Prior. Dave started out by asking Jason why he believes the daily scrum is broken. Jason said that the daily scrum is broken because, first, most developers hate the daily scrum because most daily scrums take the traditional weekly project status review meeting and do it five times a week with the Scrum Master filling the role of the project manager. Second, he says, is that it is being done backwards. The center of attention should not be the Scrum Master, but the team and the sprint backlog. He says that the purpose of the daily scrum is misunderstood. The three questions don’t result in a plan but result in just an exchange of information. For what real daily planning looks like, he uses an analogy of driving down the road and seeing a bunch of plumbers’ trucks from the same company parked outside of a McDonald’s. Inside, they’re planning things like, “We’re going to the Johnson’s house at noon. Can you come over and meet me because it’s going to be a two-man job.” Jason says he hates the three questions. He says the subject of the sentence is not helping us in collective ownership of the sprint backlog. “I have my user story. I have my Jira ticket. I have five team members and we each have a ticket.” Shifting the subject of the sentence to “we”, he says, changes the behavior dramatically. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jason-tanner-is-on-a-mission-to-fix-your-daily-scrum/id1121124593?i=1000441958371 Website link: https://soundcloud.com/drunkenpmradio/jason-tanner-is-on-a-mission-to-fix-your-daily-scrum MARY AND TOM POPPENDIECK ON UNLEARN The Unlearn podcast featured Mary and Tom Poppendieck with host Barry O’Reilly. Barry asked Mary and Tom what we may need to unlearn since the Agile movement began. Mary says that Agile started as a reaction to what was going on at the time. The vast majority of people doing software engineering today weren’t around back then. One of the things Agile has to do is grow up to be not a reaction to bad things that happened in the past, but to be something that talks about, “What does it take to do good software engineering?” She contrasted the software engineers she speaks to today that expect to be handed a spec with the engineers she worked with early in her career who treated engineering as problem-solving. Tom talked about how many who are working to make organizations more agile attempt to solve problems with process. This assumes that the organization’s problems are process problems but they are actually architectural problems. This includes problems with the architecture of the applications they are evolving, problems with the structure of the organization, and problems with the structure of the relationships between the supporting groups and those who are benefitting from said groups. Mary talked about how Amazon AWS was one of the early organizations to understand that you need to give teams of smart, creative people problems to solve. As a result of having this insight, they organized the company in such a way as to optimize for this, such as by eliminating a central database which was heresy back in 2005. She called out AWS Lambda in particular because this product did not optimize for short-term shareholder value and would never have been approved at most companies because it reduced what Amazon was charging customers by five times. She attributes this ability to self-disrupt as being essential to Amazon AWS’s success. Tom talked about the fact that when you attempt to scale things up, you reach a point where complexity dominates any future gains and wipes them out. He says you instead need to de-scale: figure out how to do things in little chunks that are independent and don’t require coordination. He says that this is how cities have been organized for thousands of years. Mary said that she has been doing software since 1967 and has never seen anything last two decades and still be current. Agile is two decades old and cannot be current unless it is constantly adapting to what is current today. She brought up continuous delivery as a fundamental change in agile thinking. It changed the way we thought about how we structure organizations and teams and what kinds of responsibilities we should give to them. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/solving-problems-safely-with-mary-and-tom-poppendieck/id1460270044?i=1000442018979 SARON YITBAREK ON GREATER THAN CODE The Greater Than Code podcast featured Saron Yitbarek with hosts Arty Starr, Rein Henrichs, and Chanté Thurmond. They talked about the annual Codeland conference Saron is running and how it offers free on-site childcare this year. Saron says free on-site childcare at conferences today is where codes of conduct were a few years ago. She says that if her conference wasn’t making it easier for parents to attend, it wouldn’t be living up to their promise for inclusion. Chanté asked Saron what she learned in her transition from being a code newbie herself to the present day where she is running two podcasts, a software job, and a conference. Saron said she learned that it is important to be consistent in all your efforts, whether it is community work, your personal projects, or a project at work. Nothing gets built overnight and, for a while, nobody will care what you’re doing. If you want to do something great, it takes persistence and it takes you believing in yourself especially when you’re not getting external validation. Arty asked about what expertise in “newbie-ism” might look like. Saron says that it is about being comfortable in a state of frustration. She pointed to a study on the difference between those who finish a computer science degree and those who quit. The study said that those who finished the degree were comfortable being in a state of confusion: they knew that things were not going to make sense for a while and they were ok with that. A second thing, she says, that helps you become an expert newbie is realizing that almost all problems in coding are solvable. By contrast, in writing, there is no perfect essay. In journalism, there is a search for truth, but is truth attainable? In life sciences, we study nature all around us that we may never fully understand. She also says to keep your frustration external, avoid internalizing your failures, and she says to distance who you are from your work and the things you produce. Saron’s comment on being comfortable in a state of confusion triggered a Virginia Satir quote from Rein: “Do you know what makes it possible for me to trust the unknown? Because I've got eyes, ears, skin. I can talk, I can move, I can feel, and I can think. And that's not going to change when I go into a new context; I've got that. And then I give myself permission to say all my real yeses and noes, because I've got all those other possibilities, and then I can move anywhere. Why not?” Rein asked what Saron learned about teaching. Saron says that teaching is storytelling in disguise. She says that if we frame teaching opportunities as storytelling opportunities we can be better teachers. This reminded me of Josh Anderson’s comment on the Meta-Cast podcast that I referenced way back in episode 3, “Taking The Blue Pill Back To Sesame Street.” Rein brought up a theory of learning called conversation theory. In conversation theory, teaching happens as a conversation between two cognitive entities. You have to come to agreement and build a bridge with that other cognitive entity. It deconstructs the teacher-learner binary. The teacher themselves has to be a learner too. Chanté asked about the ethos at Code Newbie for being a learner and a teacher. Saron says they look to the community to pitch in. When someone asks a question, they encourage the community to answer. She contrasted Code Newbie with Stack Overflow. Code Newbie attempts to teach the learner from where they are and avoid the condescension that is common on Stack Overflow. She said that to create an environment where people are not afraid to ask questions, we have to be unafraid of being vulnerable ourselves. Go first, share your vulnerability, and share what you’re struggling with. The moment you start doing that, other people will be much more likely to raise their hands as well. Chanté asked Saron what resources she recommends for code newbies to learn to code. Saron said that the hard part isn’t finding resources but sticking with them when things get tough or boring. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/135-intentional-learning-with-saron-yitbarek/id1163023878?i=1000442022293 Website link: https://www.greaterthancode.com/intentional-learning DAVE KAROW AND TREVOR STUART ON DELIVER IT The Deliver It podcast featuring Dave Karow and Trevor Stuart with host Cory Bryan. They talked about running experiments to learn about your customer. Cory asked how people can run such experiments at scale. David pointed out that having a way to run the experiment is one thing, but you also need to be able to rapidly make sense of the results in a repeatable, authoritative way. Trevor says it is all about assumptions, hypotheses, and documentation. Before you even start your experiment, you need to understand why you are running it in the first place. In other words, you need to establish what is going to change as a result of the experiment. Trevor says that much of the market is already doing experiments and they don’t know it. They just call it “using feature flags” and rolling things out incrementally. They just need to move one step further to slice and dice their user populations, roll things out for longer time periods to those users, and bring the resulting data into a form that facilitates decision-making. David talked about dog-fooding by starting your rollout of new features with your employee population, giving examples from Microsoft, where it takes a few weeks to go from the employee population to the full customer population, and Facebook, where it takes about four hours for the same kind of rollout. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep91-product-experiments-with-trevor-and-dave-from-split/id966084649?i=1000442844631 Website link: http://deliveritcast.com/ep91-product-experiments-with-trevor-and-dave-from-split FEEDBACK Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

The Daily Scrum is one of the simplest and most critical elements of Scrum. Unfortunately, for many, this event becomes a traditional status meeting that delivers little value. If your Development Team has lost its way with their Daily Scrum, this podcast is for you. Jason Tanner is the CEO and Co-Founder of Applied Frameworks, as well as a Certified Scrum Trainer and a Path to CSP Educator. During the 2019 North America Global Scrum Gathering in Austin, he was kind enough to block out some time to talk through the different reasons he sees teams lose their way with the Daily Scrum and what can be done about it. If you’d like to get in touch with Jason: Applied Frameworks: https://appliedframeworks.com CSP Fast Pass: https://appliedframeworks.com Email: jtanner@appliedframeworks.com

Jason Tanner is the CEO of Applied Frameworks. He has a widely ranging background that includes Project Management, Product Management, and professional IT training. He’s also a Certified Scrum Trainer who spends time working with individuals who are in the process of trying to become CSTs and he’s on a personal mission to save the Daily Scrum. During this episode of the podcast, Jason and I talk through how his background (which includes serving in the military) led him on the journey to becoming a CST and leading Applied Frameworks. We also dig into his process for helping CST candidates prepare for co-training, the CST submission process itself, and being on a TAC panel. If you’d like to reach Jason you can find him here: Applied Frameworks: http://appliedframeworks.com LinkedIn: https://www.linkedin.com/in/jasontanner/ Twitter: https://twitter.com/jasonbtanner And if you'd like to learn more about becoming a Certified Scrum Trainer, you can find that here: https://www.scrumalliance.org/get-certified/trainers/cst-certification

We can't always be Agile. By understanding the linkage betweenbusiness models, architecture and agility, we can make faster pivot decisions

Presenter: Matthew Clarke. Featuring reports from: Jason Tanner, Jon Royle, Martin Bridges, Ian Abrahams