A (0:04)

Hey there Agile Adventurer. Just a quick question.

B (0:07)

What if, for the price of a.

A (0:09)

Fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

B (1:11)

Welcome back to this fifth and last episode of this special Christmas 2025 series. If you've been following the news from Ukraine over the past few years, you've witnessed something remarkable and tragic happening in real time. The evolution of drone warfare. What we're observing, and I frame this as an observer that clearly supports Ukraine's defense of their freedom and territorial integrity. What we're observing is adaptation, happening at the speed that would have been unthinkable in traditional military contexts in the past. A new drone capability emerges within days, not months. Countermeasures to that drone capability start to show up. Those countermeasures get countered themselves within weeks. New tactics, new technologies, new approaches, all iterating in compressed time frames. Because the stakes are existential, there's no time for lengthy procurement processes or multi year development cycles. This is adaptation under the ultimate pressure. Now, our businesses aren't facing literal warfare, at least not most of us. But they are facing existential threats. And the data is stark. The average lifespan of companies is shrinking dramatically. In the 60s, companies stayed in the S&P 500 for an average of 33 years. By 2016, that had dropped to 24 years, and current projections suggest that we will be at 12 years by 2027. Clayton Christensen documented as much in the Innovator's Dilemma book. Entire industries disrupted by new entrants who operate differently. What he observed in the 70s and 80s is happening only faster now. And software is the accelerant. Here's the if we can improve our business's chances of survival by even 10 to 15%, we're talking about massive impact. Thousands of companies that would otherwise fail could thrive. Millions of jobs preserved, enormous value created. So the question is, how do you build an organization that can adapt at this speed? Think of what we're about to cover in this episode as the operating system for software. Native organizations, just like a computer's operating system, manages resources with real time feedback, like allocating memory, scheduling processes, responding to inputs. These five principles form the foundation that everything else that I propose runs on. And Here are the five core principles. Number 1 Constant experimentation with very tight feedback loops 2. Clear connection to business value, not just task management 3. Software seen as a value amplifier, not just something we do for whatever reason 4. Software has a strategic advantage providing differentiation, not optimization. 5. Real time observability and adaptive systems. Let's explore each one of these in this last episode of our special 2025 reflection on software native businesses. Let's start with principle one constant experimentation with very tight feedback loops. Here's the principle. Software developers have known this for decades through test driven development. You write a test, you write the code, pass it, you see if it works. You iterate. Red green Refactor what is happening now is that this TDD mindset is becoming the ruling metaphor for how we want to manage products and even entire businesses. Everything becomes an experiment, not in the sense of being reckless or uncommitted, but in being clear about what what we're testing and what we expect to learn. I call this working like a scientist, where learning is the goal. And here's how this works in practice, and I'll use my own work as an example here in my company and the companies that I consult for, everything we do is framed as an experiment. We're always crystal clear on three things. What's the goal, what we are trying to achieve? What's the concrete action, the task or set of tasks, the specific things we will do. And third, what's the learning? What will we measure to know if it worked? This is the opposite of theory. We start from practical action right out of the gate. When you framework as an experiment, you naturally focus on learning rather than just completing tasks. In my consulting practice, when a client says we need to improve our retrospectives, we don't just implement a new retrospective format. Instead we connect it to the business value. For example, let's say that the goal is to improve NPS score for users of a specific feature that's been underperforming. The action might be to run focus retrospectives with, for example, three teams using techniques that explicitly target the user pain points and asking what user friction did we observe this week? And then the learning would be, for example, tracking two things. How many user focused improvements get implemented in the next two weeks and measuring the actual impact of those improvements in the features NNPS score. After two weeks we know whether something that we tried worked. Maybe the NPS moved from 20 to 35 and that's a signal to expand the approach. Maybe it didn't budge and that tells us that retrospectives aren't the bottleneck for this particular problem and we try something else. The experiment mindset means we're always learning, we're never stuck. And this is how we apply TDD test driven development to organizational change. And it's powerful because we're not just improving our processes, although we are. We're connecting everything we do, even process steps, to the customer outcomes. Which brings us to Principle 2. Principle 2 is a clear connection to business value. Here's the main idea. Software native organizations don't measure success but by tasks completed, story points delivered, features shipped, or even cycle time or throughput. They measure success by business outcomes achieved. Now this seems obvious if I phrase it like this, but most organizations still are today optimizing for output, I.e. tasks completed, not outcomes. So here's a concrete practice you can start applying today. We use impact mapping or similar outcome focused frameworks. And every initiative should answer what business behavior are we trying to change? The core of the impact map. How will we measure that change? The core of running experiments, and what's the minimum software needed to create that change? Because we want to get feedback quickly, just like we talked about in Principle 1. For example, a financial services client wanted to modernize a reporting system. In project terms, that's like a 12 month initiative with dozens of features. But we reframed it on business outcomes, reduced time analysts spent preparing monthly reports from 80 to 20 hours we measured. We tracked the actual time spent by analysts and instrumented the software so that we could get task based data. And we ran a first experiment where we automated the three most time consuming report components. With the first delivery, analysts were spending 50 hours instead of 80. Not perfect, but 30 hours saved with the first delivery. And that's a huge improvement. And the team iterated from there, always with that 20 hour target in mind, clear metrics and clear tooling to measure the impact on that metric. In this context, we're not trying to fulfill the requirements. Rather we are laser focused on the business value that actually matters. When you connect to business value, you can adapt when you're committed to A feature list or a task list, you're stuck. And this leads us to Principle 3. Principle 3 is software as a value amplifier. And this is what it boils down to. Software isn't just something we do or a support function. Software is an amplifier for your business model. If your business model generates x amount of money of value per customer through, for example, manual processes, writing software to automate those processes should help you generate at least 10x or more. If it's not creating that kind of amplification, you might be using the wrong tool. See, software is a tool to amplify value creation. And and it is also probably the most expensive and slower way to check if an idea delivers value. So you must have a very high return in mind. Otherwise, if you use software, you're much more likely to lose money. Here's how it looks like in practice. Before investing in software, you can ask, will this amplify our business model by 10x or more? That's 10 times, not 10%. That's the threshold where software's unique properties, zero marginal cost, infinite scale, instant distribution actually matter and where the cost value curve starts to invert. Remember, software is probably the slowest and most expensive way to check if a feature delivers value. So you better have a 10x or higher expectation of return. Here's a concrete example. Stripe didn't just make payment processing a bit easier. They made it so simple that entirely new business models became possible. I know because Stripe made my business model possible. Before Stripe, if you wanted to accept payments online, you'd need a merchant account, which would take weeks to set up. Integration with payment gateways, months of development, PCI compliance, expensive and complex, and so on. Stripe reduced that to add seven lines of code. And these days it's even simpler than that. That's not just 10% easier to accept payments online, that's hundred times easier to accept payments online. And it enabled an entire generation of Internet businesses that could not have existed otherwise. Subscription services, marketplaces on demand platforms, and even my own business. That's what I would call software as an amplifier. It didn't try to optimize the old model, it made new models possible. If your software initiatives are about improving something by 5 or 10%, ask yourself, is software really the right medium for this problem? Or should you focus on something where software can create genuine value amplification? And this leads us to Principle 4. Principle 4 is software as a strategic advantage. Here's what it is at the high level. Software. Native organizations use software to create strategic advantage and competitive differentiation. Not optimization, not automation, not cost reduction. Those are all side effects. This means that treating software development as part of your very strategy, not a way to implement a strategy that is separate from software. I've discussed this idea with Tom Gilb and Simon Holzapfel on the podcast. They called it continuous strategy. The link is in the show notes. Check it out. What they meant is instead of creating a strategy every few months or years and deploying it like a project, strategy and execution are continuously linked when it comes to software delivery. So check out those episodes to figure out what they meant and how to apply this idea of continuous strategy. The link is in the show notes. In practice, what this means is that we organize around competitive capabilities that software enables. For example, we ask how can software 10x the value we generate right now? What can we do with software that competitors can't easily replicate? Where does software create a defensible advantage? And how does our software create compounding value over time? Here's a concrete example. Amazon Web Services didn't start as a product strategy. It emerged from Amazon building internal business capabilities to run their own e commerce platform at their large, very large scale. And through this they realized that they've built an infrastructure that it's extremely hard to replicate and thought about offering it to others. AWS became Amazon's most profitable business not because they optimized their existing retail business, but because they turned an internal business capability into a strategic value platform. That is software as a strategic advantage. It wasn't just supporting their strategy. Software became the strategy. Let me repeat that. The software became the strategy. Compare that to companies that use software just for cost reduction, process optimization. They're all just playing defense software native companies use software to play offense, creating capabilities that change the competitive landscape with scale. This idea that Tom and Simon referred to in the podcast of continuous strategy means your software capabilities and your business strategy evolve together in real time, not in these old school annual planning cycles. And this leads us to the last and in my view, most important principle of this software native operating system for businesses and this Last Principle, Principle 5 I titled Real Time Observability and Adaptive Systems. The principle connects back to principle one, but takes it to an organizational level. So this is not just about feedback loops, it's about feedback loops at scale. For business value creation software native organizations use telemetry and real time analytics not just to understand their software, but to understand their entire business and adapt dynamically. Here's what's fascinating. Observability come from DevOps. It's a practice from DevOps where we have monitoring, logging, tracing, metrics, whatever. These are actually ways of managing software delivery itself in DevOps. But for us, we're bootstrapping our own operating system for the software business using the same approach. And this is just the beginning. Here's what it could look like in practice for your company. We build systems that constantly sense what's happening and can adapt in real time. For example, we deploy features with feature flags so that we can turn capabilities on or off instantly. Then we use something like AB testing, not just for UI tweaks, but to understand how those features land and what kind of consequences they have. And then we turn them on and off as we need. We instrument everything so that we can measure what's happening happening. We know how users act and take that as input to assess the result of concrete experiments. And this helps us build feedback loops that let the system respond automatically. And here automatically is in quotation marks, because it's the people who are taking in this information, making decisions and putting this into practice. This is about building real time observability at the high business level, at the top business level, and creating adaptive systems, which of course can be automated to some extent, but depend on people making decisions as well. Here's what the future state at your company could look like, and it's already here, just in some other companies. Look, for example, to social media companies and algorithmic trading companies that trade stocks in the markets very, very quickly through computerized algorithms. Of course, they're already operating this way. For example, Instagram doesn't deploy a new feed algorithm and wait six months to see if it works. They're constantly testing variations, measuring engagement in real time, adapting the algorithm continuously and making changes as they go. The system itself is sensing and responding all the time. These algorithmic trading firms, also known as high frequency trading firms, they make thousands of micro adjustments per day based on market signals and other intelligence. Now imagine applying this to your whole business. For example, a retail company that adjusts pricing, inventory and promotions in real time based on demand signals. A healthcare system that dynamically reallocates resources based on patient flow patterns detected as they emerged. For example, another one could be a logistics company that uses routing algorithms to adapt to traffic, weather and delivery success rates. This is the future of software native organizations. Not just fast decision making, but systems that sense and adapt at software speed, with humans setting the goals and constraints and with the help of software executing the continuous strategy for that business. We're moving from the idea of make a decision, deploy, wait to see the results, to deploy variants, measure continuously and adapt as you learn more. And this brings us back to principle one, where everything is an experiment. But now the experiments run automatically at scale, with near real time signal collection and decision making. We're getting close to the end, so let's come back to where we started. In episode one, we established that software has become societal infrastructure. Software is different. It's not a construction project with a fixed endpoint. It's a living business capability that evolves with the evolution of the business itself. In episode two, we diagnose the problem project management thinking that treats software like building a bridge. And it represents a fundamental mismatch that cascades failures throughout organizations. In episode three, we showed that the solution already exists. Organizations like Spotify, Amazon and Etsy are practicing software native development successfully. The knowledge is already out there. In the last episode, episode four, we exposed the organizational immune system, the four barriers that prevent the project management mindset, the funding models, business and IT separation, and finally, the risk management theater. And today, in this episode, I've given you the blueprint. A blueprint that took me decades to observe and understand. And you get it. In five carefully curated episodes that establish the future for software industry in the 21st century. The five principles I shared with you form the operating system for software native organizations. Let me repeat those. Number one, constant experimentation with tight feedback loops. Number two, clear connection to business value. Number three, software as a value amplifier. Number four, software as a strategic advantage. And number five, business level real time observability and adaptive systems. This isn't theory. This is how software native organizations already operate. I know. I've been working with these companies for nearly three decades now. So the question isn't whether this works. We know it does. The question is, how do you get started? Here's what I suggest you do when you go back to work after this well deserved Christmas and New Year's pause. First, start the conversation. Pick one of these five principles. For example, whichever resonates with your current challenges, share it with your team or your leadership. Don't present it as here's the solution, here's what we should do. Present it rather as here's an interesting idea. What do you think this means for us? That conversation will reveal where you are, where your organization is, what's blocking you, and of course, also what might be possible. Second step, run a small experiment. Take something you're currently doing and frame it as an experiment. Ask what's the goal? Then define the actions and then write down what is the data you will collect to be able to learn if you're closer to the goal or not. When running experiments, it's better to make them small and run them fast. One week, maximum 24 hours. If you can, then stop and learn. And this is how the transformation starts. Not with grand speeches or massive reorganizations, but with conversations and small experiments that start accumulating and compound over time. Software is too important to society to keep managing it wrong. Now you have the blueprint. You understand some of the barriers and you've learned some of the alternatives, so you know the transformation is possible. But here's the important part. It starts with you, not with the others. It's not about convincing others. It's about us applying these ideas ourselves. If you want support from someone who's been there, get in touch. My contact information is in the show Notes. Now you've got the blueprint. It's time for action. Oh, and of course I would like to end this series with a wish of a Merry Christmas and a Happy New Year to you and all of the people around you and looking forward to one more year with you, sharing what I and the rest of our community have been learning. Happy New Year.