Software Factory to Feature Factory

This post was adapted from Episode 120 of the Troubleshooting Agile Podcast.

The Taylorist Mindset and its Outcomes

In the Taylorist mindset, management is there to debug the machine of the company. The workers are interchangeable parts. And the job of management is to fine tune the machine and monitor all of the parts to make sure they’re compliant and doing what they’re told.

There is a role for motivation here. But the only motivation is negative. Just make sure that people know you’re watching and monitoring their progress, because if you don’t, well, then they’ll just goof off. They’re not really interested in getting work done. So you need to monitor them all the time to keep them within specified tolerances.

If you subscribe to this theory, if that’s where you start from, then you end up with a software factory, an environment in which everything came to you and was all specified upfront. There was a design document. And after the design document was a database design. And after that was a high level design. And after that was a low level design…Eventually you actually got to write some code. But really you were just a cog in the machine. Just turning the dials and building what you were told to build.

What’s both entertaining and disturbing, is that people are still doing this. Here’s an example from the medical field from about a year ago (before the pandemic). At the time their focus was on doing an incredible level of detailed analysis before everything they did. It really did feel like you were in a factory when you walked onto the floor and you just watched the people carefully, carefully specifying each thing.

It was almost like you were in one of those clean rooms building a satellite or something. It was very carefully architected. But at the end of the room, where the sales people sat, they were crying because their experience was that nothing new was coming out because the process was so incredibly slow. It was incredibly careful, but it was incredibly slow.

And what’s kind of interesting about this group is that their motivation wasn’t “our people are lazy.” Their slowness was due to the compliance rules that they were under. The process of making something that is used medically requires, they thought, this level of very, very detailed analysis that took six months to produce anything.

It turned out when we actually went and talked to the compliance people, they said, actually, we don’t care. We’re kind of confused why they do quite this much. What we need is a documented process. So, yeah, you could write down something, say what you’re going to release every two weeks. That would be great. Where’s that written down?

So these folks were trapping themselves in a software factory. And they were doing it thanks to a misunderstanding. As it turns out that this kind of thing continues and dresses itself up in agile clothes.

Cargo Culting

In the 1990s, it was an explicit, overarching theory that this was the rational, correct way to approach software development. This kind of carefulness, this kind of care and attention was scientifically, provably correct. It didn’t work well in practice, but that was the dogma and it was explicit and it was something that people could reference. “Of course we’re supposed to specify this. This is the way we avoid errors that will cost us more later.”

Now when people do it, it’s usually because they’ve fallen into it, into a software factory trap. It has some elements that are attractive, but it’s no longer the dominant paradigm. Instead, people have come to learn that this isn’t working. We need do something different. We need to be faster, more responsive. And this Agile, Lean, DevOps stuff all sounds good. We want to move there.

But now we hit a different problem as they’ve lost that overarching theory. In fact, they’ve kind of lost any theory at all, but they know what outcomes they want to get. And this leads now into cargo culting.

A cargo cult is a belief system in a relatively undeveloped society in which adherents practice superstitious rituals hoping to bring modern goods supplied by a more technologically advanced society. It is based on the experience of some specific islanders after World War Two. They would make headphones out of coconuts and build runways and they would get these sticks and they would try to signal planes to come. And of course, there weren’t any planes coming. What they had experienced was a mysterious group of people showed up with all this amazing cargo, these great results for them: knives and tools and things that they couldn’t imagine in their level of development and they wanted them back again. So they thought, well, the thing that happened was that people signalled the planes and the planes came in, the planes brought the cargo. So we’ll just do the same thing and the planes will show up. Of course, no planes ever showed up.

And the analogy is that when people grab a bunch of Agile practices, they will say, all right, so we’re supposed to do is stand up. So we’re gonna stand up every morning. OK. Good. And everybody stands up. But they don’t seem to have gotten any faster.

Well, let’s see. How about now we’re also supposed to hold a planning game. OK, great. Well, let’s order our official planning poker cards. We’ll make sure they’re the right color and we’ll get the right things. And now we’re playing planning poker, but we don’t seem to be any faster and we don’t seem to be getting anything.

Oh! Maybe what we should do is we should agile harder. We should stand up higher on our tiptoes. We should have different color planning poker cards.

And they keep looking for more of the actions that they can take, just like the islanders might try to make their coconut headphones more realistic and then make them better. That’s not the method that’s going to help you with the problem because you’re not dealing with the problem, which is that the attitudes, the conversations, and the culture are missing. You can’t create that by holding a different type of retrospective or grooming your backlog differently.

And it’s not that these approaches never work. Part of the reason these cargo culting approaches proliferate is that some people are able to do them productively. They put these practices in place and then the humans around there make them work, because it’s one of the characteristics of people. And this is one of the things we talk about in Chapter 1 of Agile Conversations, the attributes of people.

One of the attributes of people that’s very important is that they want to make projects succeed. You’ll have people who will use the openings that are created by the adoption of processes to try to make it work. And they sometimes can do that. It’s important to recognize that there are times when people put these practices in place and in fact, they do get better results. Not so much because of the practice, but because the humans involved now are maybe having different conversations and maybe they’re just working hard to fill any gaps and make sure good things happen.

And of course, the practices do create the opportunity to do that. So we’re not saying those things are bad to do. Don’t hold standups or, don’t have a backlog. But what happens is if you only rely on those things and you expect that some magic happen, you’re relying on magic.

The problem here is it’s about what’s visible and what’s invisible. And what’s visible is, “okay, that team had these reports and these metrics and they did these practices and they’ve gotten certified in this. Oh, these must be the important elements. Let’s go ahead and take those to this other team or this other organization and apply them the same way.

“Oh, look, we’re not getting the same results. Why is that? We must have the wrong mix of rituals and processes. Maybe we had the wrong consultant in. Maybe we missed a certain training. Maybe there are other metrics we should be tracking. Maybe this agile stuff just doesn’t work.”

Humans Are Not Simple

So people had a theory of scientific management. It wasn’t a good theory, but it was a theory. And then they lost a sense of theory about what makes things work. And they’ve kind of gone for this cargo cult approach of picking up all of these visible trappings. And when it fails to work, they’re kind of lost about what to do next.

Ultimately, it comes back to this element of people. If we want to make something happen with people, we have to care about their characteristics.

The Cynefin Framework talks about problems as being in different domains. There’s the simple, complicated, complex and chaos domains. And then there’s the disorder domain. And the point that we make in the book is that when you’re dealing with people, you know, the human, you’re very much dealing with things that are not simple. People are not simple.

When you go and say the same things to different people you get very different responses. And people are even complicated. There’s no person out there, there’s no expert, who can come in and tell you everything about every person in your team. There’s no one who can come and say, “OK. I know humans well enough. I understand everything there is to know about humans. And if we just make these tweaks, we’ll now get these humans running correctly.”

Some of the attraction of consultants is they claim that this stuff is really just complicated, that there’s a question of expertise. But in practice, our experience has been that humans are very rarely in the complex domain. There’s feedback loops, there’s emergent behavior, there’s properties. It’s sometimes very difficult to predict what’s going to happen.

Although when you look back it has retrospective coherence. You can understand how the team ended up there. But it would have been very hard to predict it ahead of time.

And so what do we do if we have this complex environment? Well, we need to be trying different experiments. We need to sense and respond. And how do we do that? Guess what? We have an idea. We need to have conversations.

One of the challenging things about adopting this, of course, is if you’re in the kind of cargo cult, feature factory mode, you’re probably looking for metrics and things you can measure and look at and determine how well your factory is running. And the challenging thing is there’s no Jira plugin for conversational quality.

Listen to the full Troubleshooting Agile podcast here.

- About The Authors

Douglas Squirrel

Coauthor of Agile Conversations

Follow Douglas on Social Media

• 
• 

Jeffrey Fredrick

Coauthor of Agile Conversations

Follow Jeffrey on Social Media

• 
•