BONUS: From Waterfall to Flow—Rethinking Mental Models in Software Delivery | Henrik Mårtensson

Summary

Scrum Master Toolbox Podcast: BONUS Episode Summary

Episode: BONUS: From Waterfall to Flow—Rethinking Mental Models in Software Delivery
Guest: Henrik Mårtensson
Release Date: May 7, 2025
Host: Vasco Duarte, Agile Coach, Certified Scrum Master, Certified Product Owner

---

1. Introduction

In this special bonus episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages in an insightful conversation with Henrik Mårtensson, a seasoned management consultant specializing in strategy, organizational development, and process improvement. The episode delves deep into the enduring presence of the Waterfall methodology in today's software development landscape and explores the mental models that perpetuate its usage despite the widespread adoption of Agile practices.

---

2. Background of Henrik Mårtensson

Henrik Mårtensson is recognized for his sharp systems thinking and a passion for storytelling. As a licensed Scrum Master and a published author, Henrik brings a wealth of knowledge from his extensive experience with methodologies like Lean, Six Sigma, and the Theory of Constraints. His critical examination of Waterfall versus Agile frameworks provides listeners with a historical and practical perspective on software delivery models.

---

3. The Origins of Waterfall Methodology

Henrik begins by tracing the roots of the Waterfall model to the 1950s, highlighting its inception during the SAGE Project, the first large-scale software development endeavor. He explains that the methodology was born out of economic analysis, emphasizing extensive upfront planning to minimize errors in punch card programming. Henrik notes:

Henrik Mårtensson [04:00]: "The reason why I believe it [Waterfall] still sticks around is because I see it."

He further elaborates on Herbert Bennington's 1950 paper, which advocated for a linear approach due to the perceived unreliability of compilers at the time. Interestingly, Bennington later acknowledged the flaws in this approach, advocating for more iterative methods.

---

4. Misconceptions and Persistence of Waterfall Today

Despite its problematic origins, Waterfall has persisted in various forms. Henrik discusses Dr. Winston Royce's 1970 paper, which actually criticized the linear model and proposed iterative improvements. However, subsequent misinterpretations by Bell and Tayer in 1976 solidified the Waterfall label, leading organizations like the Department of Defense to adopt gated processes that inadvertently enforced Waterfall-like structures.

Henrik Mårtensson [11:02]: "They named it Waterfall. And then later on, the Department of Defense described how the subcontractors should work. And that description...forced the subcontractors to use a waterfall process because it was a gated process."

---

5. The Impact of Organizational Structure (Conway's Law)

The conversation shifts to Conway's Law, which posits that an organization's structure influences the design of its systems. Henrik illustrates this with a real-world example where a seemingly simple task—a remote-controlled door unlock—became excessively complex due to organizational silos and rigid processes.

Interviewer [35:11]: "This reminds me of the ironic description of Conway's Law... that organization had probably a team for the transmitter, a team for the receiver, a team for the door unlocking computer, a team for the cloud services..."

This fragmentation leads to inefficiencies, highlighting how centralized decision-making and departmental silos can cripple Agile methodologies that rely on cross-functional, collaborative teams.

---

6. Mental Models Hindering Agile Adoption

Henrik identifies several outdated mental models that keep organizations tethered to Waterfall practices:

• Scientific Management: Rooted in Frederick Taylor's principles, this model equates busyness with productivity, often resulting in multiple concurrent projects that hinder completion.

  Henrik Mårtensson [19:37]: "He thought that in order to be as profitable as possible, everyone in the company needed to be as busy as possible."

• Herd Mentality: The tendency to adopt practices because "everyone else is doing it," rather than based on their efficacy.

• Limited Pattern Recognition: Relying on familiar patterns instead of critically evaluating the suitability of methodologies for current challenges.

• Redefining Terms without Substance: Organizations may rename workgroups as "teams" without fostering the collaborative, goal-oriented dynamics that true Agile teams embody.

These mental models obscure the complexities of software development and impede the effective implementation of Agile practices.

---

7. Practical Examples of Waterfall Problems

Henrik shares a poignant story illustrating the pitfalls of Waterfall in practice. In a project aiming to develop a remote-controlled door unlock system, what should have been a two-week task extended to over two years due to complex dependencies and organizational silos.

Henrik Mårtensson [33:44]: "The three-minute door unlock is actually not a metaphor. It actually took three minutes to unlock the door."

This example underscores how rigid, linear processes can lead to excessive complexity and inefficiency, even in relatively simple projects.

---

8. Conclusion and Resources

As the episode wraps up, Henrik emphasizes the importance of understanding fundamental principles like queuing theory and systems thinking to break free from Waterfall constraints. He encourages listeners to critically assess their organizational structures and mental models to embrace true Agile methodologies.

For those interested in diving deeper into these topics, Henrik recommends his blog post titled "Waterfall vs Agile Battle of Dunces, or Race to the Bottom" and suggests connecting with him on LinkedIn for further insights.

---

Notable Quotes

• Henrik Mårtensson [04:00]: "The reason why I believe it [Waterfall] still sticks around is because I see it."
• Henrik Mårtensson [11:02]: "They named it Waterfall...forced the subcontractors to use a waterfall process because it was a gated process."
• Henrik Mårtensson [19:37]: "He thought that in order to be as profitable as possible, everyone in the company needed to be as busy as possible."
• Henrik Mårtensson [33:44]: "The three-minute door unlock is actually not a metaphor. It actually took three minutes to unlock the door."

---

Final Thoughts

This episode provides a comprehensive exploration of why Waterfall methodology remains prevalent and the deep-seated mental models that reinforce its adoption. Henrik Mårtensson's expertise offers valuable lessons for Agile practitioners striving to cultivate more effective, adaptive, and collaborative software development environments.

For more detailed insights, listeners are encouraged to read Henrik's blog post and follow his professional updates on LinkedIn.

Transcript

[Host]

Have you ever wondered what it really takes to make Agile work well? At the Global Agile Summit, we're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action. Whether you're a leader, a product innovator, a developer, you'll hear practical insights from those who've done it. They'll be telling their own stories from the stage. I'll tell you more about this at the end of this episode. So stay back and listen to the full detailed description of what we have in store for you at the Global Agile Summit. But if you can't wait, you can go right now to globalagilesummit.com and check out our full schedule for now onto the episode. But I'll see you at the end of this episode with more details on the Global Agile Summit. Talk to you soon.

[Interviewer]

Hello, everybody. Welcome to a special bonus episode. Today we have with us Henrik Mortensen. Hey, Henrik. Welcome to the show.

[Henrik Mortensen]

Hi.

[Interviewer]

So, Henrik is an old friend and I met him many years ago in the. I guess we could call it the Agile community. But we've been talking on and off since then about software specifically. He's a management consultant. Pardon me, Specializing in strategy, organizational development and process improvement. We've talked a lot about theory of constraints, for example, but also lean Agile and six Sigma to solve complex challenges. Henrik is also a published author, a licensed Scrum master. I guess I meant certified when I wrote that.

[Henrik Mortensen]

Or certifiable, possibly including.

[Interviewer]

Yes. And he really brings a sharp, some would even call it razor sharp, systems thinking and love for storytelling, which you will all hear in the conversation we have today. But the reason why we have Henrik with us today is because he wrote a very important blog post quite a while back. It was 2023. Looking at the dates, the title is Waterfall vs Agile Battle of Dunces, or Race to the Bottom. The title notwithstanding, it's actually a great historical post about the history of. Of waterfall and where it came from. And that led me to reach out to Henrik and invite him on the show. Because there is this, I think, misconceived and perhaps misinformed idea that waterfall is a. What do they call it? A strawman. Right. Like waterfall doesn't really exist. It has never existed. But that's not really the case. So when we were preparing for this episode, we talked with Enrique and he said that some companies are still explicitly asking for waterfall projects. So to remove that myth, that waterfall is a strawman argument. Please, Henrik, explain what that looks like. And why do you think that the waterfall model still sticks around?

[Henrik Mortensen]

Okay, well, the reason why I believe it still sticks around is because I see it.

[Interviewer]

We need to break that down, though. Henrik, when you say you see waterfall, you don't mean it in the sense of seeing dead people, right?

[Henrik Mortensen]

Well, not usually.

[Interviewer]

No.

[Henrik Mortensen]

I mean, this year, so far, I've been asked at least 10 times if I'm interested in running a waterfall project.

[Interviewer]

Wait, but do they. Do the people that ask you really call it a waterfall project?

[Henrik Mortensen]

Yes, explicitly. Waterfall.

[Interviewer]

Oh, my God.

[Henrik Mortensen]

Yeah. And the thing is, I don't think everyone knows what waterfall is and why we dislike it so much.

[Interviewer]

And we do dislike it, just to be clear.

[Henrik Mortensen]

Yes. The thing is. Okay, should we do the history thing?

[Interviewer]

Let. Let's do that quickly.

[Henrik Mortensen]

Okay. So picture yourself back in 1950. You're working on a U.S. defense project, the SAGE Project. And this is the first large software development project in history. So they had to figure out how to do it. And they came up with a methodology that was based on an economic analysis. And then a few years later, one of the members of the team, Herbert Bennington, published a paper on it. Now, the economic analysis at the time said that it would be cheaper to use punch cards to write machine codes, ones and zeros, than it would be to use an assembler to write assembly language. And it was because they thought that assemblers. Sorry, a compiler to work to do assembly languages. And it was because compilers were considered unreliable at the time. And then when you did the analysis that way, then it made sense to have a model where you did a lot of upfront planning.

[Interviewer]

And the upfront planning was writing all of the code in the form of punch cards and then feeding it to the machine later.

[Henrik Mortensen]

Yeah. And you didn't want to make a mistake with the punch cards, so you did a lot of planning before you even touched a punch card. So that's the reason why they set up the model as they did now, in the paper. Bennington omitted some really, really important things. For example, he omitted that they used. They made prototypes. So they didn't do it all in one sweep. They made a prototype. They learned from that, and then they continued working. Now, if we jump forward to 1986, I think Bennington reissued the paper mainly for reasons of historical accuracy. He wanted to have a historical record of how they had worked, and he made commentaries in that new version of the paper. And he wrote that the economical analysis, in retrospect, it was all wrong. He wished they had gone with an iterative approach and the compiler instead.

[Interviewer]

Iterative and a compiler.

[Henrik Mortensen]

Right, Iterative and compiler. This is something they considered it in 56. Yes.

[Interviewer]

Yeah. So this is the thing that it's going to be very important as we discuss waterfalls still existing today. Right. Because they started from the idea of, okay, if we're going to write code in punch cards, we need to do all the planning up front, make sure that the cards are punched correctly, not with the pregnant dimples or whatever it was with the Al Gore presidential campaign. Those were punch cards, by the way. And then in 86, he said, actually, it would have been much better if we did iterative and compiled language.

[Henrik Mortensen]

Yes.

[Interviewer]

Okay. So this is important because it's going to inform the next part of the history.

[Henrik Mortensen]

Yeah. Fast forward to 1970, and Dr. Winston Royce wrote a paper on waterfall. It wasn't called waterfall then. We didn't get the name Waterfall until 1976, but Royce wrote a paper on waterfall. And Royce is often considered to be the father of waterfall. But if you actually read the paper, he hated waterfall.

[Interviewer]

Yeah. In fact, he said this is the worst possible way to do it. Right.

[Henrik Mortensen]

He said it's incredibly risky. So on I think it's the second page of the paper, there is an illustration of waterfall. And under it, he explains that this is the worst thing you can do. And then in the paper, it takes you through a sequence. Stage by stage, he fixes the model and arrives at something that he likes. So the last picture in the paper is the one where, where Royce shows the model that he is an advocate for, and that is actually an iterative model. It's not an agile model, but it has iterations and it has prototyping. And the reason why he wrote the paper is that he saw a lot of water fall around and he said, this is a bad idea. So what people did was that they, they read Bennington's paper, misinterpreted it a bit, started running waterfall projects, and Royce took notice about it in 1970 and wrote his paper. Now, in 1976, two other guys, Bell and Tayer, wrote a paper. And in that paper they say that, yeah, we have, we, we like this process that Royce has.

[Interviewer]

Which one were you referring to, by the way?

[Henrik Mortensen]

Yeah, that's the problem. They referred to the wrong process.

[Interviewer]

They referred to the first one, the one that is the crappy idea.

[Henrik Mortensen]

They didn't read further than page two and they just looked at the pictures.

[Interviewer]

If it were today, one might even say they probably summarized it with ChatGPT.

[Henrik Mortensen]

Today, they would have done that. And the thing is, they named it Waterfall. And then later on, I don't remember the year exactly, but the Department of Defense described how the subcontractors should work. And that description was. Well, it practically, it didn't, it wasn't intentional, but in practice it forced the subcontractors to use a waterfall process because it was a gate process.

[Interviewer]

Did the Department of Defense refer to Bell and Tayer's paper or to.

[Henrik Mortensen]

No, they never referred, they never referred to Bellante. They constructed something like the V model we see today.

[Interviewer]

Okay.

[Henrik Mortensen]

And it was a gated. Because they had one hardware leg and one software leg and it was a gated model. And while they weren't against iterative models, the mandatory gates forced people to implement a waterfall project.

[Interviewer]

And that's another thing that we very often don't talk about. And there are still many companies out there, even companies that claim to be doing Agile, that still use gated process models. And that's one of the things that we don't often talk about, is that when you gate a process model, you're implicitly pushing people towards waterfall. Now you're not explicitly saying that, right? Like you're not saying, hey, you can't iterate or you can't prototype before the gate, but because the gates are there, teams will be organized. We'll talk about Conway's law in a bit. Teams will be organized around the different gates. There will be skills for specific gates, there will be people responsible for specific gates and that will silo the steps in the process and they become hard coded steps in the end leading to what is in the end a waterfall thinking model about software delivery.

[Henrik Mortensen]

Yeah, and the thing was that this turned out to be a disaster after disaster. So in 1994, they, the Department of Defense issued new, new rooms where waterfall was expressly forbidden.

[Interviewer]

And this was 94. Took quite a while for them to figure that out though.

[Henrik Mortensen]

Yeah, but they, it's a slow administration. The thing is, they figured it out.

[Interviewer]

They did figure it out. Even before agile. Popular, right? 94 before agile.

[Henrik Mortensen]

Yeah, I said I didn't remember when they mandated waterfall. I think it was in, in 86, but don't hold me to it, I've got the exact year in, in, in the article. So they figured it out fairly quickly. And I mean, here we are more than 30 years later.

[Interviewer]

Yeah, we're still using waterfall, by the way. I mean, as, as Henrik just said, he, he's gotten 10 requests to lead a waterfall project just this year. Yeah, we're in, we're in the end. We're in the beginning of April, by the way, for anyone listening to this later.

[Henrik Mortensen]

Yeah. What people tend to forget is that there was a whole generation of methodologies between waterfall and agile. The rigorous methodologies, things like the rational unified process, for example. And we actually had better than waterfall in the 1960s when project managers started to use PERT and Critical path because that enabled them to parallelize some work. And waterfall doesn't do that at all. So we have a lot of different ideas that are in place concurrently. The problem is that we often tend to pick the worst ideas.

[Interviewer]

Okay, so the worst ideas I think, is retrospective coherence. I mean, if I look at it, waterfall makes perfect sense if you have no understanding of software development, but you're rather a project manager or an organizational leader who wants to see things organized in a linear, clear, hard delimitation. I mean, if you're fashion, like, if you're an organizer. Right, Like a person who takes care of an organization, it's much easier to think in silos because you can say, okay, these guys only do design, those guys only do coding, those other ones only do testing. And that's much easier to describe. Right?

[Henrik Mortensen]

Yes, but being not. Not understanding software development isn't enough. There are lots of other things you need to not understand.

[Interviewer]

Okay, let's go through some of those. That's going to be fun.

[Henrik Mortensen]

Well, for example, the Deming management system from the 1980s had, let's see now, systems thinking, which you definitely need to not understand in order to implement Waterford variation and statistics. And you need to not understand that also.

[Interviewer]

Although to be fair, many people still don't understand those today.

[Henrik Mortensen]

Yes. And psychology.

[Interviewer]

Okay, many people still don't understand that today either.

[Henrik Mortensen]

Yes, yes. And epistemology, which for the purposes, for the purposes of our discussion, we can simplify it a little bit. It's bullshit detection.

[Interviewer]

Bullshit detection. Yeah, but okay, so this is an interesting. And I think we can go very far with this, but let's not get lost in the forest yet. So we're still talking about the origin of waterfall. Now we need to link this to what is happening today. And I think that beyond talking what we need to not understand to still use waterfall, we also need to talk about what are the mental models that keep us in that prison of thinking that waterfall is even a feasible, let alone a good metaphor or framework, process for. Or process framework for software development. So what are some of those mental models that people bring to software development?

[Henrik Mortensen]

Yeah, very old industrial models. For example, if you're stuck In Taylor's model of how processes work, he didn't really have the concept of processes. And also Taylor was a management expert who wrote a book in 1912, the Principles of Scientific Management and there are actually good things in it. And Taylor is often accused of being really evil and not caring about people. And that's not true. He, he, he thought that his model would enable people to get higher wages, for example, and, and to some extent better working conditions.

[Interviewer]

And, and we can actually argue that that actually happened not because of Taylor alone, but Taylor's models actually contributed to that.

[Henrik Mortensen]

Yes. His model also was the basis for sweatshops. And when he found out about that, he was horrified. So he was by no means an evil person. He had good intentions. But the thing is, he didn't have the concept of a system. So he thought that in order to be as profitable as possible, everyone in the company needed to be as busy as possible.

[Interviewer]

Yeah. So that's another model. Right? Like the model that says that busyness equals productivity.

[Henrik Mortensen]

Yes. And if you do waterfall, then you can keep, you keep people busy, incredibly busy at each stage in the process. But when you're busy in one stage, all the other stages work at zero productivity. So what happens then is that you start running lots of concurrent projects to keep everyone busy. And in a sense you succeed because everyone is working all the time and flip flopping between different projects. The only drawback is that you never finish anything.

[Interviewer]

That's the busyness perspective leads to concurrent projects. Reminds me of a conversation I just had this weekend where an organization had around 50 plus projects ongoing with around 70 people.

[Henrik Mortensen]

Yes. As one project manager told me that in his organization at one time, each project manager had eight different projects at the same time. And he was fully aware of how crazy that was, but he wasn't in a position to do anything about it.

[Interviewer]

So we, we talked about the Frederick Taylor scientific management models. The idea that utilization equals productivity. That's the whole idea of busyness. The problem that comes from trying to optimize for business, which is basically concurrent projects creating chaos. A friend of mine calls this coordination chaos in the organization. What are, what are some of the other mental models that keep people stuck in this idea that software development can be done using a waterfall model.

[Henrik Mortensen]

I think that, I think we have, we have two things and they are really mental models. One thing is, well, everyone else is doing it, so it has to be good. So you get these waves of fads. So it doesn't matter if something works or not, we adopt it because other People do it. And I mean, that's a mental shortcut. And it has an evolutionary basis. We have evolved that way. We are social animals, which is a nice way of saying we are herd animals. So we tend to stay in the herd for protection. And that's as a general strategy. That's not a bad strategy, but survival strategy, but it kind of. It doesn't always work. And another problem we have is that when we are thinking about things, we are not the logically reasoning beings that we like to believe we are. Our intelligence is based on pattern recognition to a large extent. Not exclusively, but to a large extent. And it's also lazy evaluation, pattern recognition. So we. So we stop at the first pattern we recognize. And when you do that, it's difficult to evaluate the consequences of implementing something like waterfall. You just look at, yeah, I want things to be simple, and it looks simple on paper. It's not until you start using it in practice that the chaos ensues.

[Interviewer]

So I remember reading a book actually quite recently, although it's, I think from the 70s, it's James C. Scott's, seeing like a State, where he describes what from today's perspective could be called catastrophes of organizing society. And there's one example which I love. He talks about how in the 1800s, 1700s and 1800s, Germany and France specifically looked at the forests as an economic advantage. And they tried to kind of productize, or more like manufacturize, the growth and exploitation of forests, leading to, after just one exploitation cycle, leading to a depleted ground, lack of biodiversity, which led to much bigger problems like lower yield and so on. And in the book, James Scott describes how this rationalist view of nature and what we call systems, right, complex systems is what he calls nature because he's talking about all of nature, not just organizations or cities. For example, he also talks about cities and he talks about how our rationalist view on purpose removes the complexity, which is what waterfall does, right? Waterfall on purpose removes the complexity to make it easy to understand how the work flows. But in my mind, when I think about this and the work that I've done and continue to do with software organizations, I think that this is also available in things that are not necessarily waterfall. So one of the things, the very common pushbacks I get when I say we're still using waterfall for many things is that, no, no, but, you know, project management is much more complex. It has many more angles. And that is true. The body of knowledge of project management is far more complex than what waterfall could be. But the project management mindset brings with it the model. And the model that the project management mindset brings is, is that you need to know what you're going to do before you get the approval to start doing it. And in software development that is often translated to you need to have all the requirements, you need to have some understanding of the architecture, not in detail, but some understanding of the architecture and you need to know how long it takes or how much it costs. That's the estimation problem. Now in order to do how long it takes or how much it costs, you need to do quite a lot of decision making up front because estimates are the result of decisions when it comes to software development. So we are also pushing everyone just with the word project closer and closer towards waterfall, not literal waterfall. In many cases we actually have water scrum fall, right? You have the waterfall beginning of the project, you have people scrumming in the middle and then you have the waterfall end of the project. And we call that waterfall fall Scrum fall. What do you think about that? That project management is unwittingly perhaps, but clearly driving us towards a waterfall mindset of linear, linear flow, clear sequentialization of work, separation of skills, etc.

[Henrik Mortensen]

Yeah, well first of all it's a huge mistake. But the thing is that what I often find is a lack in fundamentals understanding of the fundamental principles. So for example, say something like queuing theory, for example, queuing theory is the mathematical study of qs and if you know just a little bit of queuing theory you quickly realize how, for example, why many SCRUM teams get into trouble because SCRUM focuses on the team and most SCRUM teams have some sort of work in process limits on the work that a team is working with. And in general they manage that pretty okay. But they also have, and they have a sprint backlog and that sprint backlog is also limited in size, so they manage that pretty well. Now unfortunately they also have a product.

[Interviewer]

Backlog which is unlimited inside, which is unlimited.

[Henrik Mortensen]

So they can have a process that works fairly well and WIP limits that works fairly well. But because they don't understand the underlying theory, they have one to maybe four years of work in the product backlog because no one has told them that. Yeah, well you need to limit that too and then the whole idea falls apart. And of course if you want to limit the product backlog, well then you need to get the rest of the organization to agree to not just push things in there willy nilly. They need to accept the limit the limits.

[Interviewer]

Yeah, so you're saying if we would understand even a little bit of queuing theory. And that, that actually leads me to another question, which is another one of those basic concepts. You have a story that you shared with me, this three minute door unlock story that, that shows how some perhaps logical decisions can lead to catastrophic results when it comes to software development. Before we dive into that, tell us that story, Henrik.

[Henrik Mortensen]

Okay. Well, several years ago now, I worked in a large project and I had recently become the scrum master for, for a team, and a very, very good team, one of the best I've ever worked with. And I was acquainting me with, with the situation. So I asked them a lot of questions about things and I looked at one thing they were, they were working on, and the idea was to use a remote control to unlock a door. And I asked them, okay, how long, how long, how long would it take? How long have you been working on this? Well, they said a little bit more than two years.

[Interviewer]

For a remote control to unlock a door?

[Henrik Mortensen]

Yes. Okay. But I can see here, because I had looked at the system architecture. Well, I can see here that you have dependencies to other teams because the structure is pretty complicated. Now, if you had been given permission to design this and do everything yourself, how long would it take them? Well, they said about two weeks.

[Interviewer]

Wow. They were working on a project for two years that even themselves recognized that if done differently, it could take one sprint two weeks.

[Henrik Mortensen]

Yeah, I mean, that was one job in a large project, but all the jobs in the project suffered from the same thing, of course.

[Interviewer]

And what was the reason for that? Like what, what, how come that large disparity between the reality of what they were doing that took two years, and the expectation, when they look at it from the perspective of what they could do themselves on their own, which is two weeks. Like, how did we get to this disparity?

[Henrik Mortensen]

I'm guessing a little bit, because I wasn't in the project from the start. But I would say it was a combination of things. You had, you had a system architecture that was overly complex, complicated, so very simple. Things got incredibly complicated because of the architecture. And then you had an organizational structure that followed the architecture.

[Interviewer]

Which is one of the other critical basics that everyone should know about, which is that when you have a complex system architecture, you will develop an equally complex organizational structure and vice versa.

[Henrik Mortensen]

Yes. And you had no one who looked at this critically and said that, yeah, well, this is a bit nuts.

[Interviewer]

Which it was, to be clear, which it was. So the, the three minute door unlock is Actually, not. Not a metaphor. It actually took three minutes to unlock the door, correct?

[Henrik Mortensen]

Yeah, yes. When they got it going, it took three minutes to unlock the door. That. That's also.

[Interviewer]

So walk us through that. Okay. What was going on for a button to take three minutes lead a signal to a door?

[Henrik Mortensen]

Okay, so you had a transmitter handheld, you had the door, and next to the door you had a receiver for transit transmitter signals and a computer. So you press a button on the transmitter, the receiver receives, it sends the signal to the computer, but the computer doesn't unlock the door. No, instead it sends the signal to a central cloud service. The cloud service has to spin up something called a lambda, which involves, among other things, starting a Java virtual machine. And you have further dependencies, you have to spin up other lambdas with other Java virtual machines. Once they have done that, that takes a lot of time.

[Interviewer]

And then after all of that, the signal needs to be sent back to the computer next to the door.

[Henrik Mortensen]

Yes, yes.

[Interviewer]

This reminds me, and we kind of alluded to that already, this reminds me of the, I guess we could call it the ironic description of Conway's law. Conway's Law is that concept we were just talking about, which is this idea that if you have a four team compiler project, you will have a four PASS compiler. Right. And this is exactly the same. Right. Like that organization had probably a team for the transmitter, a team for the receiver, a team for the door unlocking computer, a team for the cloud services, a team for authentication, a team for, I don't know, whatever other aspects that were running in the cloud. And eventually all of those were working, I bet, very efficiently when looked at independently, but completely inefficiently when looked at as a whole system.

[Henrik Mortensen]

Yeah. So you could basically get a 2020, a compiler that had. God, I lost the word suddenly.

[Host]

No worries.

[Henrik Mortensen]

Not, not a four pass. Not a four. Thank you. Not a four pass compiler. You've got a 20 pass compiler or.

[Interviewer]

30 or 40, depending how many teams you have.

[Henrik Mortensen]

Yeah, so. So, and the thing is that, I mean, you could have looked at this from an architectural point of view and said that this, this is a bit nuts. But you could also have looked at it from an organizational point of view and said that this is a bit nuts.

[Interviewer]

But there's a corollary to what you said. You could have looked at it from an organizational point of view and recognized that this was a bad idea. However, there were a lot of people whose careers and status were invested in that organization and they had no motivation to think that the Organization was wrong in any way. Therefore they had all the motivation to uphold the architecture which follows the organization, which is totally not. But this is also a very important concept. Conway's law is that is because this shows how most organizations which rely on the idea of centralized decision making are actually crippling the option, the possibility of having agile businesses. Because one of the core things about agility is that you need to inspect and adapt. Now if you inspect locally, you only see your little part of the system. You can't adapt in a way that benefits the whole system. So you need to work together. But when you have centralized decision making, you have implicit motivators and promoters of the principle of delegating decisions upwards. Right. So you give the question the problem to your manager, who then gives it to their manager, and so on, eventually coming to a decision point. And one of the things that I wanted to come back to in our waterfall versus Agile perspective is that the way we design our organizations has a direct impact on even the possibility of applying agile methodologies in that organization.

[Henrik Mortensen]

Yes. The thing is that, I mean one thing that happens often is that organizations redefined words. So you have terms that mean something and the, the idea is introduced into the company and one of the first things they do is to redefine the terms so they now mean something that the company is already doing. And I've actually got a great example of this Black in the 90s 93, I think Microsoft released Windows for work groups. And why did they release something called Windows for work groups? Yeah, because people didn't work in teams back then. They worked in work groups. There are important differences between teams and work groups. A work group that's people who have, well, pretty much the same skills, but I work on different things so they don't work towards a common goal the way a team does. Now some organizations had great success with teams, so what happens? Other companies want to be successful too. So they, in order to get the same success as the, the companies that use teams, they immediately rename their work groups to teams.

[Interviewer]

But they were still work groups.

[Henrik Mortensen]

They were still work groups.

[Interviewer]

Yeah. And in project management we do that a lot as well. We call them virtual teams.

[Henrik Mortensen]

Yeah. And now something interesting. Then much later the company decides to implement SCRUM or Safe or any kind of Agile, which explicitly as a has. Well, it's an implicit prerequisite that the teams really are teams.

[Interviewer]

Yeah, cross functional, goal oriented, etc.

[Henrik Mortensen]

But now you try to implement SCRUM in what is actually a work group and well, as a developer told Me. Well, Hendrik, we've got five different sprint goals. This, this sprint.

[Interviewer]

Because they were a work group working for five different virtual teams. Yeah, and I've definitely seen that too, where, where you have developers that are participating in multiple sprints and they need to attend multiple sprint plannings, multiple daily standups, multiple Sprint reviews because they're working. They are a skill rather than a person. They are a skill that is being used in multiple different deliveries.

[Henrik Mortensen]

Yeah. I would like to add that in that particular case, the team and their manager, and exceptionally good manager were fully aware of the problem. So when we discovered things like that, the general approach was to start by laughing till we had tears in our eyes and then start to try to.

[Interviewer]

Fix things one small step at a time. Okay, so we've talked about quite a lot of concepts. The history of waterfall, how that started still affects us today. Some of the basic concepts we need to know about, like queuing theory, Conway's law, before we can really start taking advantage of the Agile way of thinking and looking at software development. There's a lot to dive into here. Now, I'll put the link to your blog post in the show notes, but Henrik, do you have a book or a reference, a video, something that you think people should look at if they're interested in the topics we've been discussing today?

[Henrik Mortensen]

Yeah, well, that article is a good start. Nowadays I am really slow writer, so I still post things on the blog, but not nearly as frequently as. As I used to, so. But the article is a good start. I have a YouTube channel where I haven't posted anything for years. I'm working on a presentation right now that I intend to post there, but I won't promise when it's about change projects and why so many fail and a slightly different way of doing things.

[Interviewer]

Absolutely. We'll put the link to those resources in the show notes for sure. And how about you, Henrik? If people want to know more about you and the work that you're doing, how can they connect with you?

[Henrik Mortensen]

Oh, well, LinkedIn is a given. I don't advertise myself much. I kind of, yeah, I'm working at a company. I've got a manager who is a very good salesperson and I'm a horrible salesperson.

[Interviewer]

Which also means that there's a lot of insightful posts on LinkedIn by Henrik. So check his page out and why not connect with him and ask a few follow up questions. Hendrik, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

[Henrik Mortensen]

It's been really nice talking to you.

[Host]

Hey friend, thank you for staying here. Is all you need to know about the Global Agile Summit if you've ever suffered or know people who are suffering from Agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel. We get discouraged, especially when conversations revolve around the same old frameworks, the same old buzzword. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action and transform the way you work. The Global Agile Summit will happen in Tallinn, Estonia May 18th. That's the workshop day in the then 19th and 20th the conference day and Talinestone is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which is kind of a citywide celebration of software startups and groundbreaking ideas. And we'll have a shared ticket for you to attend those events as well. So, so who will be speaking? Well, we've got an incredible lineup of thought leaders in software and agile. For example, Clinton Keith, the person who wrote, literally wrote the book on game development with Scrum and is busy bringing Agile to the world of game development. You must check his session. The very famous and well known Jurgen Apelo, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking an unconventional look at product growth with his Lizard Optimization keynote. Other speakers include, for example Sven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with the contract negotiation?

[Interviewer]

How Agile is that?

[Host]

But there's more. We'll cover engineering practices in our developer track with talks on for example AI assisted test driven development, developing products in minutes with a different approach to how we develop, configure, deploy platforms, and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile business track where we will talk about for example open strategy, a very agile approach to managing organizations and deliver delivering software faster to clients faster than you can.

[Interviewer]

Even write a contract. Literally.

[Host]

I mean, I already told you about Svendit's story is amazing. It definitely is a must see. I'm sure you'll be inspired and get a lot of ideas for your own software projects and software delivery. Now whether you're a business leader, a product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations Agile Product for product managers, product owners and innovators and Agile Developer for the builders making Agile work in practice. The coders, the testers, the designers, the producers, the scrum masters, you name it. If you join, you will meet over 200 agile professionals from all over the world. People who just like you, want to grow, want to share and want to learn. By challenging the ideas that don't work anymore at the Global Agile Summit, you'll get new connections, fresh ideas and the energy to take your own Agile to the next level. And who knows, maybe even find find your next career opportunity. So don't miss out. Check out the full program and grab your ticket [e-mail] I'm really looking forward to seeing you all in Tallinn, Estonia in May. I'll see you there.