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)

Hi there. Welcome back to this episode four of this special 2025 Christmas series. In episode three, we explored what's already working and some of the fundamental practices that enable software as a living capability, which is one of the ideas that we've established in episode one. And we saw how organizations like Spotify, Amazon and Etsy embodied the principles like iterative delivery, tight feedback loops and product thinking. We looked at real examples of software native development succeeding at scale so we know it works and we have proof we even understand the principles. Which raises the obvious question, well, if this works well, why isn't everyone doing it? That's not a rhetorical question. There are real powerful forces that prevent organizations from adopting what would actually help them. I call this the organizational immune system. The embedded structures, incentives and mental models that reject change even when it's beneficial. Today, we're going to expose four critical barriers that prevent organizations from becoming software native. These aren't separate problems. They're all symptoms of one root cause. And understanding this is essential to break out of the ancient technology we call project management. Everything starts here. Project management isn't just a set of tools. It's a fundamental mental model about how work happens, how it's defined and managed. It defines what success means and does that by setting the standard at on time, on budget and on benefits. Yet in practices PM the project management approach focuses very little on the benefits piece. It's a paradox that project management has never really been able to tackle, even if PMI has tried to move towards benefits and value. With PMBOK7 in the year 2021, when they published that version of the Project Management Body of Knowledge guide. Here's the key message. The project management mental model is incompatible with software development and will continue to be because project management as an art needs to support industries that are not software native and unlikely to be for the foreseeable future. PMI Project Management Institute serves a different audience. Let me be specific about why with four clear reasons. The first reason is that software requires discovering non trivial amounts of work. Project management assumes that you can know the scope up front. You gather the requirements, you estimate the work, you plan the schedule. And this is the critical part of their funding model. Even if project management tried half heartedly to adopt what they call hybrid approaches to project management, mixing Agile with waterfall, which is a huge paradox. But in software a significant portion of the work only becomes visible once you start building. Woody Zwill famously says it's in the doing the work that we find out what work must be done and you discover that the simple feature requires refactoring three other systems, for example. Or you learn that the database schema doesn't support some query patterns that you need. Or you find that users actually need something different than what they asked for. By the way, this is a very common problem. This isn't poor planning, it's the nature of software. You're creating novel solutions to complex problems. Discovery and is inherent to the work. Project management treats discovery as failure, like we missed some requirements. Software native thinking, however, treats discovery as progress, like we learn something critical in the no estimates book I refer to this phenomena. I argue that scope creep, which is a project management term, should be relabeled as value discovery in software because we discover more value to add. The second reason why project management is inadequate is that we need to probe and validate much faster than project management approaches would allow us to see. Project management optimizes for plan execution, gathering requirements, designing, building it, all, testing at the end deploy. This feedback loop can be months or even years long, including a clear distinction between different teams and people that to different parts of the work. But in software, hypotheses need to be tested in hours or days, not weeks, and certainly not months or years. Questions such as will users actually use this feature? Does the architecture handle the load? Is this the right abstraction? You can't wait until the end of a 12 month project to find out your core assumptions were wrong. And when we do find that the core assumptions are wrong, we very often need to fully replan, not just change the plan through a change request. Software native organizations optimize for learning speed, while project management optimizes for plan adherence. These are opposing and mutually exclusive definitions of success. Reason three is that software needs its own language and approach that is closer to investment and risk management than it is to project management. Project management talks about tasks, milestones, percent complete, resource allocation, critical path, you name it. Software needs to talk about user value, technical debt, architectural Runway, learning velocity, deployment, frequency, lead time, and so on. These aren't just different vocabularies. They represent fundamentally different ways of thinking about work and the world. When you force software into project management language, you lose the ability to manage what actually matters. And you end up tracking task completion while missing that you're building the wrong thing. And reason four is that the scholarship gap is hurting our entire industry. Here's something that most people don't realize. There's an extensive scholarship in it, but almost none of it is about delivery processes. Until recently, Agile software development represents the first worldwide trend in scholarship around software delivery. Specifically about software delivery. I mean, people are finally studying what actually works for building software, not just adapting manufacturing or construction thinking to the software industry. But here's the problem. Most organizational investment still goes into project management scholarship in training. We have PMI certifications, Prince two traditional MBA programs. There's plenty of programs out there that build on project management thinking. And that is a fundamental problem when applied to software. In fact, this affects everyone. For example, when your CFO or executives or your business partners all think in project management terms, they literally cannot understand why software needs to work differently. The mental model mismatch isn't just a team problem. In fact, it's an industry wide problem. When you add up these four reasons, they lead to one conclusion. Project management as a mindset is fundamentally incompatible with software as seen as a living business capability. And this root cause creates a cascade of organizational barriers downstream. Let me show you how. One of these barriers refers to the budget cycles and funding models. And of course, for our interest, the alternatives to those. Here's the problem. Project thinking drives project funding. This project funding sounds like we'll spend $2 million over nine months to deliver features A, B and C. We approve the budget and then we execute the plan. This all seems rational, very well structured and financially predictable. It creates accountability. But it's completely misaligned with how software creates value. Here's what actually happens. You commit to a scope at the start. When you know the least about what you need to build, then the budget runs out. Exactly. When you're just starting to understand what users actually need, when the project ends, the team disbands, taking all their accumulated knowledge from with them. Next year you start over with a new project, a new team, and back to zero context. Meanwhile, your software needs continuous evolution. But you've structured funding around temporary initiatives with hard stops. So what's the alternative? I call this incremental funding with real time signals software Native organizations fund teams working on products, not projects. Here's what that looks like for incremental funding, Instead of approving, for example 2 million for nine months, you approve smaller increments, maybe 200K for six weeks. And then based on what you delivered, you decide whether to continue based on what you learned, or to pivot or to switch focus to something else. I also advocate for the use of no estimates. I'll put the link to the book in the show. Notes for Early Signal Management Instead of detailed estimates that pretend to predict the future, we should use lightweight signals to detect problems early. Are we delivering value regularly? Are we learning? Are users responding positively? All of these signals tell you more than any Gantt chart could ever do. We also talk about portfolio managers as curators of investment, not the task police. The portfolio level stops asking are we on schedule? And starts asking are we seeing the value we expected? Should we invest more, pivot or stop? This is how venture capital works, and software is inherently more like VC money than construction. For example, Amazon's approach to product funding. Teams get continuous funding as long as they're delivering value and learning. There's no arbitrary end date to the investment. The funding continues as long as the product has strategic value. This aligns funding with software's nature as a living business capability. We've talked about the project management mindset and funding models being obstacles, but there's a third one that even software people are responsible for. This is barrier number three, the business and IT separation. And of course, the suggested alternative. Project thinking reinforces the separation of the business, who defined the requirements, and it, who execute the projects. Project managers coordinate and manage the handoff. This all seems logical. There's specialization, clear roles, defined responsibilities. But it actually creates a disaster. Here's the problem. The business doesn't understand software as a living business capability and often doesn't want to. I've worked with many clients where there's a clear separation, and the people on the business side, they really just look at it as a group that delivers tasks constantly, not a contributor to their business. These business people, they think in terms of features, so they determine solutions up front and deadlines. They don't think of capabilities like solving clear Problems and evolution. So they write these requirements documents, it receives them, estimates them, builds them. The requirements are usually wrong because quote, unquote, the business doesn't know what's actually technically possible or what users actually need when they're writing requirements for other people to use. By the time that IT delivers, the business needs have changed. Or maybe the software work but doesn't solve the real problem. Or worse, it works exactly as specified, but nobody wants it. This isn't a communication problem. It's a structural problem created by that project thinking that forces us to create handoffs between business and it. So what's the alternative? From my perspective, we should start thinking more like product people. So I suggest we consider product thinking with impact mapping as a very concrete alternative to this business and IT separation software native organizations don't separate business from it. They create product teams focused on outcomes that incorporate both the people from the business side as well as the people from the IT or software delivery side. We want to focus on behavior changes, not features. You use approaches like impact mapping. The link is in the show notes and define the goal as a change in the business behavior or performance, not a list of requirements. For example, instead of building a new reporting dashboard, the goal might be reduce the time that finance team spends preparing monthly reports from 40 hours to 4 hours. We then measure business outcomes, not task completion. We track whether the finance team actually spends less time creating those monthly reports. If the first version doesn't achieve that, we iterate. The requirement isn't sacred the outcome. The goal is collaborate on goals, not handoffs. Business and IT are on the same team. They are working towards the same measurable outcome. There's no throw it over the wall or handovers or handoffs. For example, we put together cross functional teams popularized in Spotify squad model. And each squad, like in the Spotify model, includes product managers, designers, engineers, all focused on the same part of the product with a clear goal to achieve. There's no separation. They all own the outcome together. When you organize around products and outcomes instead of projects and requirements, that business IT separation naturally disappears. The final big barrier to software native ways of working is risk management theater. And of course, we'll talk about the alternative. So what is this all about? Project thinking creates elaborate risk management processes and practices. Steering committees, gate review sign offs, documentation, risk registers, governance frameworks, you name it. All of these, when put together, create the appearance of managing risk. They make everyone feel professional and in control. However, the very practices to manage real risk end up increasing the risk of a blow up IT'S just like Chesterton's fence paradox. Check out the explanation in the show notes. But very shortly it's the idea that if there's a cliff and you don't put a fence there, people are very careful. But if you put a fence there, people are less careful. They kind of pile up and eventually cause a massive disaster. But here's the real risk in software. Delivering software that nobody wants and having to maintain it forever, where the real cost is. I mean, think about that. Every line of code you write becomes a maintenance burden. If it's not delivering value, you're paying that cost forever, or paying the additional cost to remove it later. Although many don't remove it, which means that you're paying the cost of maintaining that software forever. Traditional risk management theater doesn't protect against this at all. Gates and approvals just slow you down and focusing and focus you on the tasks that you're doing instead of allowing you to focus on the value that you're delivering. These gates and approvals don't tell you whether users will actually use what you're building. They don't validate whether the software creates business value. The agile alternative to all of this is that risk management is everywhere. Everything we do is risk management software. Native organizations recognize that agile and product thinking are, when you put those together, risk management. Here's how it works. First, you deliver quickly. The fastest way to reduce the risk is to get software in front of real users and see if it works. Not in a demo, not in staging, in production, with real data solving real problems. Now of course, if you can't go to production, you need to use other strategies like paper prototypes, clickable dummies and so on. Because you're already focusing from the beginning on the risk of the software not actually solving a real problem for the user. We don't trust what we write down. We validate everything. We validate the expected value. We don't ship and hope. We measure how software helps achieve the intended outcome. For example, in the example we used before, did the finance team really reduce their reporting time? Did the users really engage with the feature? And then we build into the learning and iterate cycle. We are constantly collecting information, changing what we do based on the information we collect. If it's working, we do more. If it's not working, of course we change directions and we try to apply Lean Startup as a business level practice. Lean Startup isn't just for startups, of course. Eric Ries famous Lean Startup methodology is fundamentally a software native management practice. I mean, it Came from software. So it should be clear. The build, measure, learn cycle in lean startup is the core aspect of adaptation and it is how you avoid the catastrophic risk of building the wrong thing. So which approach actually manages risk? Well, let's look at an example. The risk management theater looks like this. You have six months of requirements, gathering a design, we have multiple approval gates trying to prevent all the risks, but in reality only accumulating them. Then we have comprehensive test plans, a big bang launch after 12 months or more. And then we discover that users don't want what we produced. And now we need to maintain this software forever. I wrote an article which is in the show Notes that shows five examples of this software that was delivered but never used. The agile risk management approach, by contrast, is quite different. We do two weeks to get the minimal viable feature out. We ship potentially to a subset of users, maybe beta users. We measure the actual behavior, we learn that maybe it's not quite right, it doesn't deliver the value we expected. Then we iterate for another two weeks and we validate before scaling. We end up maintaining only the software that actually has value. This agile risk management approach focuses on validating assumptions quickly and cheaply, while the risk management theater from project management maximizes your exposure to the risk of building the wrong thing software. Native organizations don't look at governance and agility as a trade off. Agility is the best governance approach. It's the one that increases the learning loops, learns faster and reduces the most important risk faster, the risk of not delivering the right thing. So here's how all of this obstacles or barriers come together as the immune system in action. It starts with the project management mindset, the fundamental belief that software is like construction or something similar, that we can plan it all up front, that done is a meaningful state instead of the need to continuously maintain a living business capability. And this mindset brings with it its own funding models that allocate budgets to temporary projects instead of continuous products. It brings organizational structures that separate business from it and treat software as a cost center, a very common anti pattern. And of course it brings this risk management theater we just talked about that optimizes for appearing in control rather than actually learning. Each barrier reinforces the other. The funding model makes it hard to keep stable product teams, the business and it. Separation makes it hard to validate value quickly. And the risk theater slows down the learning loops. And the whole system, when you put it together, resists change. Not because it wants to, but because it's just a self reinforcing system. Even beneficial change is resisted because all of these parts depend on each and they reinforce each in order to maintain the system going. When you try to implement Agile without addressing these structural barriers, the organization's immune system rejects it. And by the way, this is entirely predictable. Teams might adopt Scrum or Kanban, the stand ups, the sprints, but nothing fundamentally changes. And this is why so many agile transformations fail and will continue to fail. They treat the symptoms, the team practices without addressing the real problem, the organizational structures built on project thinking. So now you understand what's blocking you. It's not that people are stupid, ignorant or resistant to change, is that the organizations have structural barriers built on fundamental mental models mismatch the immune system we've been talking about. But here's the empowering part. Once you see the system clearly, you can transform it. You now know the root cause, project management mindset, how it manifests, funding, separation, risk theater, and what the alternatives look like. In the examples that I shared in episode five, we're going to put all of this together into a complete blueprint for software native organizations. We'll explore the fundamental principles, the practices that embody them, and what it actually looks like and feels like to operate this way. And this is the transformation. Not just adopting Agile practices on teams, but becoming a truly software native organization from top to bottom. Because software is too important to society to keep managing it with the wrong mental models. So join me for the grand finale tomorrow. Episode five, Software Native Organizations. Oh, and of course, Merry Christmas and a Happy New Year.