The Universal Challenge of Product Development
Have you ever wondered why product development activities don't seem to go as planned just about every time? I'm not a big fan of using the words always or never, but it just seems like in technology, product development, things just never go quite as planned. And is it bad estimation? Is it shifting priorities? Is it the team doesn't know what they're doing? All kinds of things get blamed, but I'm going to tell you something deeper than that.
It's a term we're going to talk about today called computational irreducible. Now that's a big term created by Steven Wolfram as it relates to more scientific methods. But I think there's a deeper meaning that we can use as people that are coaching and educating and teaching organizations how to be more agile. Usually we've chosen agile because the nature of our work is complex, risky, and uncertain.
So let's dive in. My name is Lance Stacy. I am the founder and leader of Big Agile, and I spend a majority of my time trying to help people either articulate a certain message better for their stakeholders or their leaders or help teams generally do better in their delivery methods.
The Elephant in the Room: We Don't Know What We're Doing
So let's dive in on this one here and talk about the big elephant in the room and product development is we don't know what we're doing. The customer doesn't know what they want. How can we predict and plan amidst all of that uncertainty when an organization really needs to be able to budget time and efficiency and go to market strategies on all those are not bad things to do.
The Chair Analogy: A Real-World Example of Computational Irreducibility
So anyway, I want to bring a focus element to this talk right now, and it's really that chair right behind me, that chair I've had since 2015. My wife bought that for me. It is absolutely my favorite chair. I hope y'all have favorite chairs, furniture like that. Maybe I'm weird, but anytime I would travel or be away for a long time, there was just obviously want to get back to my family, but at the same time, I just want to come sit in my chair now.
Right now it's up in my office. Used to, it was a first class citizen in our living room. Well, my wife decided to redecorate. She's an interior decorator by the way. So we go through this quite a bit and she said, I need to get you a new chair because it doesn't fit the current style. I'm like, well, I love this chair. So you can imagine what kind of debate ensues in that.
But the good news is she's out trying to find me a chair. She knows how much I love it, and I'm a pretty big guy, so it's not like I can just sit in any chair and be comfortable. So she's sending me all of these magazines. She's sending me pictures on the internet. She goes, what do you think about this chair? I'm like, well, it looks fine. I really don't care what it looks like. Obviously she's got the vision of what the room should look like, but what's most important to me is how does it feel when I sit in it?
The Critical Question: When Do You Really Know?
Now, what can you glean from that by looking at a picture or reading about reviews on the internet? I can look at it and I can say, well, that looks comfortable, but when do I really know it's actually comfortable? What would y'all say? I have to sit in it. That's computational irreducible. I can predict and plan all the time and say, I think this is what's going to happen, but until I actually sit in it, I don't.
Do y'all have projects like that? You sit around, you try to estimate 'em, and you think you've done a good job doing that, and then something comes up that is inevitable with our agile style of work.
The Chair Development Process: Component Teams vs Feature Teams
So I want to use this chair as an example, not only as, I don't know if it's the right chair till I sit in it, but I also want to use the chair as an example in a product development process. So what we're going to do is pretend that we have development people that are going to have various skills in making a chair. Now, making a chair is really not like making software. So all analogies break down at some point. But really the topic that I want to cover right now is more about organizational design. And one of the big reasons organizations can't deliver as best they can in an agile fashion is simply they don't have teams and backlog organized correctly to do so.
The Component Team Problem
So we're going to pretend we have Mr Customer over here and they're like, I would like to have a chair. I want y'all to go build me a chair. Here's the specs for a chair. Now, inevitably what might happen is the organization is going to say, okay, we're going to set up two or three maybe Scrum teams, and each team is going to be what we call a component team in Agile. That's our first example.
One team is going to build the chair legs right here. One team's going to build the seat support and one team's going to build the back support. Okay? So they're going to practice Scrum, they have no problem doing that. They build a backlog. They have a cross-functional team, so they think that can build the chair legs, the back support, and the seat support.
So they start running in 1, 2, 3 or four week sprint, and they realized that team one who's building the chair legs has been able to build, let's say 10 chair legs. That sprint team number two was able to build two seat supports, and team three only built one back support. So we're done with the sprint. Each team is going to showcase what they developed, but the customer's going to be sitting there going, okay, where is my chair?
No one of these teams are able to actually showcase a usable product increment by the end user. And that's what happens with component teams. You build a database team, you have a backend team, a front end team, a performance team, a security team. They're all building one small component of the overall thing that must be used by the user. So we're delaying our ability to see did we build a chair correctly and does the customer think that we've met their need? So the customers like me sitting there going, I don't know if that's the right chair until I sit in it.
The Integration Team Band-Aid
So the organization goes, oh, I got it. Then we need a fourth team over here. We'll call it the integration team. And what the integration team does is they sit there and they take all of the different components, and now the customer can look at a chair and say, Hey, how do I like sitting in it? But notice how we're like a sprint or two or three behind the other teams. Now what happens if all of these chair legs that we built on this team are defective? We would not know that until we started putting the chairs together in team four on the integration team.
The Software Inventory Problem
So essentially what you have in this scenario are component teams. These are teams that are only building a small component. Therefore, it translates into what we call software inventory. Software inventory is a very hard thing to see. Retail inventory is easy. You got a warehouse full of a bunch of stuff that's not good. I need it on the shelves to be sold. But in software, it's really detrimental to have all of these things sitting around that are parts of features that are sitting on the shelf waiting for another team to integrate 'em.
The Solution: Feature Teams and Cross-Functional Organization
So the real key point in Scrum that tackles that problem is computational irr. Reducibility is the theory that we need to organize and optimize teams to actually build an increment of the product so that the customer can experience it as early as possible. Customers don't know what they want, developers don't know how to do what they're doing. Things are changing all the time. Technology's changing. So the quicker we can get something out there, the quicker we can validate it.
So now let's reorganize ourselves and let's say these are going to be cross-functional. We'll call 'em feature teams. In Agile, we have all skills on each team to build the chair. So we have a chair leg person, a seat support person, a back support person. So every sprint, now each team has an opportunity to actually build a chair. Some teams still may not. They have to learn how to do this really well.
But at the end of our sprint, the customer's not sitting over here going, how's my chair? They can sit in two of 'em and actually see 'em and now have a belief and trust and confidence in the teams that they're actually able to produce something and then they'll start letting go of this idea. Here's what happens in organizations. You've got to plan it all up front. I don't trust you.
Building Trust Through Predictable Delivery
So really what we're trying to practice in Agile is reduce the complex adaptive system and be more predictable in spite of the work being unpredictable. So organizational design, organizing teams and backlogs and getting behind the spirit of agility is really important.
Scrum is really one of the few agile practices that demand has a constraint that by the end of the sprint we have something usable. But that's one of the best ways to say, Hey, team, did we engineer it correctly? Does it actually work? Are we able to deploy it and repeat that? But even more important, the stakeholders and the users can say, yes, that's what I wanted.
The Root Cause: Poor Team and Backlog Organization
That's one of the biggest issues that we find in teams when it comes to trying to predict the work that we have ahead of us, is we have not even organized teams and backlogs to do so.
Take Your Agile Journey to the Next Level
If you would like to learn more about those topics, we teach certified scrum master courses that really help you get behind the theories of Agile. What is the philosophy of delivering in an agile way? And that's really more about being, and then Scrum helps us learn how to enact that. So we have certified scrum master product owner, advanced courses, all of them touch on a little bit of these different angles of how to help your organization be more agile.
Ready to transform your organization's approach to product development? Explore the comprehensive classes that Big Agile offers to help you master the principles of computational irreducibility and build truly effective agile teams.