← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS: Recovering the Essence of Agile - What's Already Working With Vasco Duarte
00:23:39
Loading summary
Transcript14 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.
- [00:12]
B
Could unlock over 700 hours of the.
- [00:14]
A
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
Hello everyone and welcome to this third episode on our Christmas 2025 special series. In the previous episode, episode two, we explored the project management trap, how treating software like a construction project with a fixed endpoint fundamentally conflicts with software as a living capability, a business amplifier. So if project management is the wrong framework, what is the right one? Well, the good news is that we've already discovered much of what works. Many of the discoveries that led to agile adoption becoming a global phenomena are still valid and they show us the way forward. The core insights were sound, deliver in small increments, get faster feedback and adapt based on the learning. But somewhere along the way, Agile became agile. Trademark certifications, frameworks, prescribed processes. The idea got commodified and in many cases the essence and the reason for its existence got lost. Now it's time to recover that essence and the critical goal of improving our software industry. As we discussed in episode one, in today's episode, we're not going to review branded frameworks, but fundamental practices and principles. And we'll look at real organizations that embody these principles successfully. Because the answer isn't to invent something new, it's to amplify what's already working. Let me be clear about what I mean by Agile as an idea and not a brand. Think about learning to have good conversations. The principles are somewhat, one would say, straightforward. You listen to what the other person says, you respond to their actual points, not the ones we've imagined they might have said. We adapt based on their reactions and we build on what's working. Now that's a high level idea of what A good conversation might be. Now imagine if someone created the certified conversation method trademark with five prescribed conversation frameworks, mandatory three day training, a checklist of approved responses, and certification levels from bronze to platinum, for example. You'd recognize immediately that this misses the point. The script, which is sold as the solution, will eventually kill the possibility of the conversation ever happening with any level of quality. And that to some extent is what happened to Agile. The core idea was simple and powerful. You build software in small increments, you get it in front of real users quickly, you learn from their actual behavior as you observe it, and then you adapt based on what you've learned and you repeat continuously. This wasn't revolutionary. It was finally us recognizing how software actually works. You can't know if your hypothesis about your user needs is correct until the users interact with it. So you optimize for learning speed, not planning precision. But then came the need to certify validate that you know how to do Agile right trademark. And that led to certification programs, Agile coaches trained in a hurry to meet some transformation targets, and you know the rest. The idea got packaged and often the package becomes more important than the principle. So when I talk about what's already working, I mean organizations that practice the ideas and principles regardless of whether they use some branded frameworks. So what do software native. And that's the term I like to use, software native. What do software native organizations actually do differently? Well, let me suggest that there are, for example, these four core practices. Iterative delivery. You ship small, you ship often, you have tight feedback loops, and I do mean tight, like really, really short. You have continuous improvement of the process itself, and you have product thinking over project thinking. Let's explore these four in turn. Practice one, the iterative delivery. You ship small, you ship often. So instead of building everything and launching once, we ship the smallest valuable increment can, and then we build on it. The example that I link to, if you want to read more in the show notes, is Etsy's transformation. In 2009, Etsy was releasing software every quarter, which was for 2009, not that bad. Every three months was actually a clear bar in some of the Agile literature in the early 2000s. But when releasing software quarterly, they have massive. They had, pardon me, massive coordinated releases that often broke things. And over time they shifted to continuous deployment. By 2012, as far as we know, perhaps even earlier, they were shipping 50 plus times per day. That's not 50 features or 50 projects. Those are 50 incremental changes, each small enough to understand and Revert if needed. For them, the benefit wasn't just speed, it was learning speed. Every deployment was a chance to see how users actually responded. And based on that, iterate. So that's practice one, iterative delivery. Practice two is the tight feedback loops. And I do mean tight. You get your software in front of real users as fast as possible. Not demo environments. No staging real users with real problems. Or better yet, don't even get software in front of users. Try to get feedback even earlier through the use of paper prototypes, clickable dummies and so on. The faster you get feedback, the faster you can adapt. Days matter. Hours are better than days when it comes to learning, and minutes are better than hours. Because the context is fresh, we can react, we can learn much faster. Practice 3 Continuous improvement of the process itself. We don't just improve the software, which of course we do, but we also need to be constantly improving how we build software. For example, Amazon created this through their CTO at the time. Werner Vogels this idea of you build it, you run it. This was introduced in around 2006. The link to this story is in the show notes for you to read if you're interested. And this you build it, you run it principle is about having development teams that are responsible for running their services in production. Not handing them off to another operations team, but actually running the services themselves. This wasn't just about the DevOps transformation quote unquote. It was a very important feedback loop on the development process itself. Because when you're paged at 3am because your code broke, you learn very quickly to write more resilient code, to add better monitoring, to have clear logs, and so on. The result is that the team processes improves because they feel the consequences of the bad processes directly. And Practice four these are just four we could talk about more. But Practice four Product thinking over project thinking we need to organize around long lived products and capabilities that we evolve over time instead of temporary projects. Mick Kirsten articulates this powerfully in his book Project to Product. The link is in the show notes if you're interested. In the book, he documents how organizations like tasktop, for example, and many others he studied transformed by shifting from organizations around temporary projects to organizing around long lived product value streams. And that's where the value stream idea comes from in many of the software contexts today, even though of course value stream is a much older concept. The key shift here is to keep teams stable and responsible for the evolution of their product as well as their process over time and let them develop this Deep expertise in both the technology that they are developing, the, the user problems, and of course, the process of how they go about it. Instead of assembling temporary project teams that disband when done, and of course leads to lost knowledge, you start having permanent product teams that continuously evolve their own capabilities, not just their software capabilities. And the key thing is that of course, when teams evolve, this aligns perfectly with software as a living capability itself, because the team becomes a living capability, accumulating knowledge and improving over time. Let's look at organizations that embody these principles. I'll start with Spotify. Many of you are probably familiar with the Spotify model, which introduced the squads, tribes, chapters, guilds. But there's a lot that most people miss. Spotify kept evolving their own model and eventually learned much more from its failures than people realize. The timeline goes a little bit like this. Before 2012, Spotify started with Scrum as the basic methodology and began adapting it to fit to their own structure and of course their product. Right? Like the idea that they're evolving their own capabilities at the same time as they're evolving the software that they're developing. And around 2012, Spotify adopted a squad model, autonomous teams aligned to specific product areas and organized into tribes. In 2012, Enrique Nieberg and Anders Ivarson published the white paper that eventually made the Spotify model so popular. The white paper link is in the show notes, so check it out if you are interested in reading that. But after 2016, internal staff and agile coaches noted that the Spotify model had become something of a myth. It wasn't really used inside the company anymore because the company had moved on. They continued to evolve. They didn't get stuck to one model. They evolved the software and they evolved the teams and how they developed the software. The keen sight is that there's no specific structure that you need to adopt. It's rather that you need to continuously evolve the organizational capability, just like you evolve software as a living capability. At Spotify, they didn't implement the model, quote, unquote, and declare victory. They just continuously adapted. In fact, Henrik Nyberi, one of the agile coaches who was working there at the time and helped document the model later in a LinkedIn post wrote, the Spotify model has nothing to do with Spotify, really. It was just a snapshot of how that one company worked at the time. And the model has taken on a life of its own since then, which is fine. Just like Lean has nothing to do with Toyota anymore, end quote. This was Enric's own words about how Spotify itself had moved on from the Spotify model. But one of the things that the Spotify model really illustrates is this idea of software native thinking applied to the organizational design itself. And then the final example I want to bring up is this mythical as well. Amazon's two pizza team the principle at Amazon was that teams should be enough, should be small enough, pardon me, so that they can be fed with two pizzas, roughly six to 10 people. But it wasn't just about the size. It was also about autonomy and ownership. Each team owned specific services or APIs. Each team made their own technical decisions. Each team were responsible for their services. In production, you build it, you run it, as we talked about before. And inter team dependencies are managed through APIs, not meetings. This approach enabled Amazon to scale massively while maintaining speed, because teams could iterate independently without spending a lot of time and effort coordinating with dozens of other teams. The result is that Amazon at the time deployed code every 11.7 seconds. This was 2021. So that's over 10,000 deployments per day across the organization. And that's only possible with a software native structure. For the company itself, it's not only about how you manage the delivery of software, it touches everything, even how you organize your teams. So what do these and many organizations share? Well, here's a suggestion. I would suggest that they optimize for learning speed, not adhering to a plan. They push decisions close to where the work is done, giving teams autonomy to adapt. They measure outcomes, that is the impact that the software delivers, not just output. It's not about tasks completed or story points delivered, but rather user value delivered and measured. And these companies also treat everything as evolvable, including their own processes and the structure of the organization. It's not about being a tech company. These principles apply to any organization that depends on software, which as we established in episode one, is essentially every organization in our society today. So why do these practices work? Well, let's connect this back to our core insight that software is a living capability that evolves with the business. Traditional project approaches assume that we can know the requirements upfront, we can estimate them accurately, and we can build everything right. The first time done in this context is a meaningful state, you are done at some point. But the software native approach that I advocate recognizes that requirements emerge through interaction with the users or between systems. Estimation is less important than rapid learning. In fact, we can drop estimation altogether. As I talk about in the no estimates book. And what is right is only discovered iteratively it's not designed up front and finally done. Only really happens when we stop evolving the software, which should be rare for successful software. So when Etsy ships more than 50 times per day, they're not being reckless, they're optimizing for the speed of learning. Each small change teaches them something. Each deployment is a test for an hypothesis of value. When Amazon's teams own their own services end to end, they're not creating silos, they're creating tight, very tight feedback loops. The team feels the pain of their own decisions directly, which then creates powerful incentives to improve continuously. And when Spotify continuously evolves their organizational model, even away from the Spotify model, so to speak, they're not being disorganized. They're treating their own structure as a company the same way they treat software, something that should adapt and change as needed. And these practices work because they align with what software actually is, a living, evolvable capability. Now, before I end, I don't want to paint a too rosy picture. These organizations aren't perfect. They struggle, they make mistakes, and they have their own dysfunctions. Spotify has a well documented challenges with their model. The link is in the show notes, so just check it out. I put it there. Amazon's culture has been often criticized as demanding and sometimes brutal. And Etsy has gone through multiple strategic shifts. But here's what matters. They're practicing. These companies are practicing software native development at scale. And it's working well enough that they can compete with their competitors and they can thrive. They're not following any playbook perfectly. In fact, they don't need one. They're embodying the principles and adapting continuously. And that raises an important question. If these approaches work for these companies and many others, why aren't they universal? Why do so many organizations still operate in project mode? And why do agile transformations often fail to deliver real change? So we know software native approaches work. We have real examples. We've reviewed some of these today and we understand the principles. Which raises the obvious question, how can we get everybody else to follow the same principles? These principles are real and they are powerful and they can have huge impact. But they are facing a strong opponent, which is the real powerful forces that prevent organizations from adopting what actually helps them. And I call this the organizational immune system. It's not my idea. Clayton Christensen talks about that in the Innovators Dilemma. But in episode four, we'll explore why so many companies still don't get don't understand software, even if not understanding it threatens their own existence. We'll look at the hidden incentives and embedded structures and the mental models that keep organizations trapped in project thinking even when they claim to be doing Agile, which is ironic. We'll talk more about that. Understanding the resistance in our organizations is essential to overcoming it. So join me next time for episode four, the Organizational Immune System why Companies Resist what Would Help Them and Merry Christmas once again. Alright, I hope you liked this episode.
- [21:25]
A
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.
- [22:23]
B
All of that AI slop you see everywhere.
- [22:25]
A
And of course without the flame wars. It's a community of practitioners that want to learn and thrive together.
- [22:34]
B
Together.
- [22:34]
A
It's the best place to connect with community and learn together.
- [22:39]
B
So if this podcast has helped you.
- [22:41]
A
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. I'll see you in the community.
- [23:13]
B
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 carrying.