← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Xmas Special: Why project management tools fail software development - and what works instead!
00:21:07
Loading summary
Transcript6 lines
- [00:04]
A
Hey there Agile Adventurer. Just a quick question.
- [00:07]
B
What if, for the price of a.
- [00:09]
A
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.
- [01:12]
B
Hey everyone. Welcome back to this special Christmas 2025 week of episodes where we explore how software needs to mature. In episode one, we established that software has become societal infrastructure and we're managing it, or at least trying, with tools designed for building railways. In the 1800s, we talked about how software is different. It's not a construction project with a fixed endpoint. It's a living capability that evolves with the business that it's designed to support. And in my own words, to power. I talk about software powered businesses these days. But here's an uncomfortable question. If we know this, if we know that society has become societal infrastructure and powers many businesses today, why do we keep falling into the same trap? Why do we keep thinking in terms of projects with start dates, end dates and definable done, when we know that software is actually never done? I've heard many of my colleagues, including in the Agile community, talking about software as if there was no other way to develop it, if not as a project. When I inquire as to what a project means, I sometimes get very clear definitions that don't really fit software. For example, a very common definition is that it is a temporary endeavor with a clear start and end time. Well, most software is never actually done. In fact, successful software is never actually done. It's continuously being developed. So today we're going to explore the project management trap. Why these tools feel so right and at the same time being so wrong for software. And what happens when we treat these living business capabilities that software provides as construction projects. So let's get started. Project management did not emerge from Software. It came from industries that preceded software that had hard physical constraints. For example, in the 1860s in the US they were building the transcontinental railroad. They had physical materials like rails, ties, locomotives, all finite and expensive. They had known physics, grades, curves, structural loads, all calculable. And they had irreversible decisions. Once you lay a track through a mountain pass, you can't easily move it to another mountain pass. And of course, everything that goes around it, the whole infrastructure, like railway stations and villages and all of that. And they had a clear way to define when they were done, the rails met and the trains could circulate. You're done. The Gantt chart was invented later in the 1910s for factory scheduling. Came from the same world. Managing physical resources, coordinating machinery, optimizing for efficiency in constrained systems. And it all worked brilliantly. For building ships, bridges, factories, highways, project management gave us the ability to coordinate what we now know are massive undertakings. Pardon me, with remarkable precision. But the problem isn't that project management is bad. It's not. In fact, we can learn a lot from project management. The problem is that software isn't like building a railroad or a building or a house, which is a metaphor I hear all the time, or setting up a process that will run forever like a factory. Here's why project management is so tempting for software leaders today. It offers comforting certainty. The Gantt charts. They show every task laid out and how they depend on each other and sequence over time. Milestones mark clear progress. They provide accountability points in the schedule. Percent complete graphs, giving us a number give us the illusion that we actually have progress when we don't. And an idea of we know exactly what to do. Requirements and project plan gives us the impression that we can just all go home at the end of the day and it will all be clear tomorrow when we need to come back and pick up work again. It feels professional, it feels controllable. It feels like we know what we're doing. But does it? Here's the example. Software project kickoff. We talk about requirements gathering. We talk about time we need for design. We schedule that over time, knowing perhaps not perhaps yes, who will be developing that software at what point in time. We talk about the testing that is needed, the deployment, training, the users. We put it all together and we say this will will take 32 weeks and it will be done by Q3. We say it confidently, leadership loves it, finance can budget it, and everyone can plan around it. But here's the problem. It's completely false precision. I mean, I've written a lot about this and you can just check out the no Estimates book for reference. There's plenty of reasons not to trust estimates, especially when they are done at the start, when we have the least amount of information of what actually needs to be done. See, the software isn't like pouring concrete where you measure twice and pour once. Every line of code is almost like an hypothesis about what users need and how the system should behave or will interact with other systems around it. You don't know if you're right until users interact with it until you go to production. That's why in Agile for example, we talk about running software being the only measure of progress. This initial waterfall project management 32 week plan we just talked about as an example assumes we know exactly what to build and and exactly how long each piece will take. But in software, we almost never know either of these things with certainty. The moment we present software to stakeholders or users, we get feedback that changes our understanding of the requirements. Even if the requirements text hasn't changed, our understanding of the requirements evolves over time. And that leads us to this major anti pattern. You thought I was going to say project management, but it's not. The major anti pattern is this idea that we are quote unquote done. You see, done is the wrong goal for successful leaving software. Remember the example of Slack, the application Slack from episode one? Let me extend that story to illustrate this point. Imagine if Slack team had thought when they started in 2013 oh, we'll build a team's communication tool. It needs to have channels, direct messages, file sharing, search, etc. We'll have a 16 week development cycle. We'll launch in Q2 of 2014 and project complete, ship it and move on. Of course they would have launched something maybe even functional and maybe even on time and on budget. But here's what actually happened. They did launch in 2014, but that wasn't done. It was just the beginning. They discovered through user feedback that people needed threaded conversations. They added that in 2017. The link to all of this timeline is in the show notes if you're interested. Then they understood that remote teams needed audio and video calls. They added that in 2016. They also figured out that power users needed automation. Think about it. Slack has a workflow automation builder. They launched that in 2019. And eventually they also figured out that people were using Slack to manage projects. And they built a knowledge management feature called Canvas and shipped it in 2023. Each of this wasn't just a maintenance or a bug fix. These were fundamental Enhancements, which, according to Robert Glass in his book, constitute around 60% of maintenance costs. So enhancements are about 60% of maintenance costs. By 2021, when Salesforce acquired Slack for 27.7 billion, it was very little of what it had started as in 2014. The value wasn't in the initial project or delivery. It was in the continuous evolution over the years. And if they thought in project terms, you know, build it, ship it, done, Slack would probably have died competing with their direct competitors at the time, like Hipchat and Campfire. Here's the thing. Software products evolve because they are successful, and they are successful because they keep on evolving. Projects, on the other hand, they end while products adapt. Now let's look at what happens when we apply project thinking to software and succeed on project terms, but fail on software terms. I wrote about five distinct cases in detail in an article I called the New Software Crisis is Real. These projects, there are five projects from five different countries, represent what is wrong with the project thinking when it comes to software and product development. These projects are not a case study because of their failures, although they were, but exactly because the people in those projects tried hard, by project management standards, to do everything right. They had detailed requirements, thousands of pages. They had milestone tracking, they had contractor coordination, they had a fixed deadline, which some hit, others didn't, and they had proper auditing and supervision. What they didn't have was iterative delivery to test with real users, early feedback loops to discover problems incrementally, and adaptability to change based on what they learned. A living capability mindset was completely missing because they were set up to just launch the full software when it was done. Project thinking demanded to get all of those requirements right up front. Otherwise, no funding. Then build it all in one go, test it at the end, and launch on the deadline, which some succeeded, others not so much. Software thinking would have demanded a completely different approach. It would have demanded launch something early, get real user feedback, iterate rapidly, and evolve the capability. These five disastrous software projects. They tried to succeed at project management, but they ended up failing at both software delivery and in some cases, project management. Check out the article, the link is in the show notes. So if not projects, then what? And this brings us to a topic that I've been exploring in writing for several years, since I published the no Estimates book. First, we must learn to think in products and capabilities, not projects. Products have ongoing evolution. They don't just start and end at a specific timeline. Capabilities are cultivated and improved over time. They are not delivered as Projects require and done. And of course very important value is measured in outcomes impact, not in completion of tasks, which is what project management asks us to focus on. So instead of comprehensive planning, we need an approach for software that focuses on iteration constant decision making based on validated hypothesis. Which is where we start with hypothesis. When we say we believe that users need X because we've observed something else. Then we run experiments, we build small and test with real users. We learn and adapt. We let reality inform our next move instead of fiction like project plans. And finally, instead of fixed scope, we need to define problems to solve, not specify the detailed solutions, which of course we don't know if they really work as we expect them to. We need to allow the solution to evolve as we learn from real user feedback. And we need to optimize for learning speed, not task completion. See, in project thinking we say things like we will build features A, B, C, D and E and we'll complete them by quarter three of 2026 and then we're done. While software native thinking sounds more we're solving problem X for users, we'll start with the riskiest hypothesis. For example, does feature A actually help to solve problem X? And then we'll build a minimal version. We'll ship it to a small number of users next week and learn whether we're on the right track. Then we'll iterate. As you can hear from this description, it sounds completely different from what a project approach would sound like. Project tries to optimize for predictability, while in this software native thinking, we try to optimize for value and for learning. Software is unpredictable. Not because we're bad at planning. No, we're really good at planning, and we've proven that in other industries, just not software. Software is unpredictable because we're creating novel solutions to complex problems and in a completely different economic system. The raw materials today are now time and brain power. Instead of minerals or hardware like iron, steel, rocks, etc. The transformation of those raw materials, which are time and brain power, is operated in unique creative moments, not repeated mechanical movements that can be optimized. Optimized to the nth degree and only require the machine to be delivered once, and it will work forever. The appropriate response to the uniqueness of software isn't better planning, it's faster learning. We're all collectively still learning how to develop software at the scale of societies. So learning is a critical process that we must engage in. So if project management is the wrong framework for software, what's the right one? Well, here's the good news, We've already discovered much of what works. The Agile movement wasn't wrong about the problems or some of the solutions. Agile was just the start of a society wide realization that we both need software and need to change how it's created. Some organizations have figured out how to actually do this quite well, not just talk about it. In episode three, we'll explore what's already working, the patterns, the practices, the principles that actually deliver software as a living capability. We'll look at real companies as examples doing this successfully and what we can learn from them. To learn fast, we must amplify what's already working and then continue to learn and continue to iterate. You know, being agile about it, right? So join me the next time for episode three, which is titled what's Already Working that We need to Amplify. Oh, and Merry Christmas again.
- [18:51]
A
All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile Gold, CTO level Strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no Estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating Product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great, it's important. But doing it together, that's next level.
- [20:39]
B
I'll see you in the community Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.