This is a transcript of episode 120 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
The first chapter of Agile Conversations is all about people-centred development, and we tell the story of our own journey from over-determined software factory to today’s feature factories, with similar Taylorist theories of management in both. In today’s episode, we go into more depth on the causes of this tragic journey, touching on old and new topics like Theories X and Y, the Cynefin framework, and why there isn’t a JIRA plugin for conversational quality.
- Theories X and Y
- 12 Signs You’re Working in a Feature Factory by John Cutler
- Cargo cults
- Cockburn on people
Squirrel: Welcome back to Troubleshooting Agile! Hi there Jeffrey.
Jeffrey: Hi Squirrel.
Squirrel: So it’s an exciting day. After years of preparation and lots of sweat, Agile Conversations, our new book is out and available. You can find a link in the show notes or just search for Agile Conversations and you’ll find audio books and a Kindle version. And even one of those old physical things that have these things you turn call pages and it’s full of all kinds of suggestions of the kind that we’ve been making for one hundred and twenty or so episodes here on the podcast. So if you’re looking for a written version of that, go and have a look. And we’re gonna be talking about aspects of the book and items from the book. For the next few weeks, because we’re excited about it and we expect that lots of our listeners will be reading it and will have questions. So, of course, we like hearing those. And in particular, we had one reader/listener who came to us with a plea. So we thought we’d meet his plea. What did he plead with us to do?
Jeffrey: Well, this was one of our advance readers. This is Chris Read. He put me up on Twitter. And one of the elements he said was don’t skip Chapter One. And I was happy for him to say that he we actually had, as of a slack instances as well, for Agile Conversations. And it has been available to our pre readers up to this point, but will now open to everyone. So if you’re interested in being part of our slack, do email us. And the email is on the Web site. And in that slack, when he was discussing it, Chris said the point. He said,’you know, this history is amazingly important. Thanks for including it’. And he also said, I think you should try and find a way to more strongly encourage people to read it in the introduction. So he was encouraging us to build that into the book. Unfortunately at that point the introduction was set.
Squirrel: We’d already printed the introductions so that option wasn’t available. But then we thought, ‘Hey, people are listening on the podcast. Here’s where-.
Jeffrey: That’s right!
Squirrel: Make the case for reading Chapter One.
Jeffrey: Exactly. So Chris tells you don’t skip chapter one and we should encourage people to read it. So here’s our chance to encourage people and we do encourage you read it because we think the history is important to kind of understand why Agile and Lean and DevOps in these various digital transformations so often go astray. And there’s a really interesting different ways that it can go astray. But I think in the way they go astray partially is related to the history. So we start our history lesson in the software factory going back to where you and I began. And then throughout the chapter, we cover the various waves that came through software, as you and I experienced it. And then look at where we finally end up today. And people listen to Troubleshooting Agile. They know where we ended up is not a place where agile is being used perfectly everywhere.
Squirrel: Or even being used. There’s things which kind of looks like it but aren’t really. And so we bring in John Cutler’s idea of The Feature Factory. You can read more about it, we’ll link to his article in the show notes. But we bring that full circle. We started in this software factory which had this very Taylorist point of view. We’ll talk more about that. And then we come back to something that maybe has shorter iterations, but otherwise it’s all the same stuff.
Jeffrey: And we aren’t going to try to recapitulate all of the history that’s in the chapter. In fact-.
Squirrel: You can read the book!
Jeffrey: Exactly. We wrote it for reason. We’re now going to encourage you to read it. I think we did want to bring up this core element of why things go astray. And, you and I, were talking even before we just started this podcast about sort of these two elements and the culture of Taylorism and that we describe and the scientific management, as it was called. But that’s only part of the explanation.
The Taylorist Mindset and its Outcomes
Jeffrey: And so maybe it’s worth saying a bit about the Taylorist mindset, which we would often describe also sort of theory X, that the managements are there to debug the machine of the company. The workers are interchangeable parts. And the job of management then is to be fine tuning the machine. And you then are monitoring all of the parts to make sure that they’re compliant and that they are doing what they’re told. And there is a role for motivation here. But it’s really just the only motivation is of a negative kind. Just make sure that people know that 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.
Squirrel: And if you’d subscribe to this theory, if that’s where you start from, then you end up with a software factory and that’s what we remember, Jeffrey, and I’m sure some of our older listeners with some grey hairs will remember this environment in which everything came to you and it was all kind of specified upfront. And 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 it was so specified for you. I remember getting thick manuals and my very first job that really specified where the semicolon should go. It was it was to that level of detailed description. And you were a cog in the machine. Just turning the dials and building what we were told to build. What’s both entertaining and disturbing, is that people are still doing that. So I have the recent example of a client in the medical field. They’re a bit busy right now with all that’s happening in the world. But at the time I was working with them a year or so ago, their focus was on doing an incredible level of detailed analysis before everything they did. And you 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.
Squirrel: It was almost like you were in one of those clean rooms building a satellite or something. It was very carefully architected. Each thing that you do, except when you went to the end where the sales people sat and they were crying because their experience was there was nothing new 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 this kind of Theory X explicitly. It wasn’t ‘our people are lazy.’ It was 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 I 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, said what we’re going to release every two weeks. That would be great. Where’s that written down? So these folks were trapping themselves in the software factory. That kind of thing you and I remember but they were doing it in 2019 and they were doing it thanks to a misunderstanding, as it turned out that this kind of thing continues and dresses itself up in agile clothes.
Jeffrey: And I think that’s a good point, which is it’s no longer what you’d call an overarching theory. And I think this is the big change is that in the 90s it was an explicit, overarching theory that this was the rational, correct way to approach it was the mainstream view. Was this kind of carefulness, this kind of care and attention was scientifically, provably correct. It didn’t work well in practise, 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. So now when people do it, it’s usually because they’ve fallen into it, it has there’s some elements that are attractive, but it’s no longer the dominant paradigm. Instead, people have come to learn. 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 in a sense of any theory at all, but they know what they want to get as far as outcomes. And this leads now into this other area we described as being a problem, which is cargo culting. I think we’ve talked about cargo cult before, but for people who may not have heard that episode, you know, can you tell us about what what’s cargo cults and what’s cargo cult agile .
Squirrel: Sure. So this is a concept I first heard about from James Shore. You tell me, like everything else in the world, it was on the C2 Wiki originally, which I’m certainly willing to believe. The idea is that just like these specific islanders and you can read about them, we’ll put a link in the show notes who after World War Two would put on, there pictures of them so this is not made up, this is actually true. They would make headphones out of coconuts and build runways out of whatever they had around in the in the area of ash or gravel or whatever. And they would get these sticks and they would try to signal the planes in. And of course, there weren’t any planes coming what they had experienced was this mysterious group of people who 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 signal 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 show up.
Squirrel: And the analogy is that when people grab a bunch of agile practises, 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 stand up. 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 colour 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 colour 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.
Jeffrey: And it’s not that these approaches never work. I think this is kind of the interesting point for me is that these cargo culting approaches, part of the reason they proliferate is that some people are able to do them productively. You know, they put these practises in place and then the humans around there make them work, you know, because it’s one of the characteristics of people. And this is one of the things we talk about in this in chapter one is sort of the attributes of people. And one of the attributes of people that’s very important is that they want to make projects succeed. So 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. And so I think it’s important recognise that there are times when people put these practises in place and in fact, they do get better results, not so much because the practise, 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.
Squirrel: And of course, the practises 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 don’t have a backlog. That’s not what we’re saying. But what happens is if you only rely on those things and you expect that some magic happen, you’re relying on magic..
Squirrel: Something magically happening. And that’s not that’s not very scientific. That’s not likely to work.
Jeffrey: That’s right. And I think the problem here is it’s about what’s visible and what’s invisible. And what’s visible are, ‘okay, that team had these reports and these metrics and they did these practises 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 organisation and apply them the same way.’ Oh, look, we’re not getting the same results. Why is that? We must we must have the wrong mix of rituals and processes. Maybe we had the wrong consultant in. And maybe you missed a certain training. Maybe there are other metrics we should be tracking.
Squirrel: Or you know what? We’ve done a lot of that and maybe this agile stuff, it actually just doesn’t work.
Jeffrey: Well, you know, it worked over there. Yeah. Maybe it can’t work here now.
Squirrel: It’s not gonna work for us.
Humans are not Simple
Jeffrey: Yeah. And so it’s a weird thing where people had a theory of scientific management. It wasn’t a good theory, but it was a theory. And then they’ve lost a sense of theory about what makes things work. And they’ve kind of gone for this cargo cult approach of OK, We pick up all of these visible trappings and then when it fails to work, they’re kind of left about what to do next. Other than, as you say, you know, agile, harder, you know, DevOps, more, what we’re lining up in this chapter more than anything else is that, look, it comes back to this element of people. And if we want to make something happen with people, we have to care about their characteristics. And we close the chapter with talking about a framework that you and I talked about recently on this podcast, which is the Cynefin Framework. And in there listeners will recall, the Cynefin Framework talks about problems as being in different domains. And so there’s the simple domain, complicated, complex and chaos. And then there’s the disorder domain. And the point that we make in the book here 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, like there’s no person out there, there’s no expert that 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 do about humans. And if we just make these tweaks, we’ll now get these humans running correctly.’
Squirrel: I know all their Myers Briggs types. So once I know that I know exactly how to put them together and then the machine will run smoothly. Just pay me a few thousand pounds. That doesn’t work.
Jeffrey: Brilliant. We’re kind of, maybe, seeing what some of the attraction of consultants, which is they claim that this stuff is really just complicated, that there’s a question of expertise. But in practise, my experience has been that humans are very rarely in the complex domain that there’s feedback loops, that there’s emergent behaviour, that there’s properties, that 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. And it’s something that our listeners heard from us many times, which is we need to have conversations.
Squirrel: What a crazy idea. And one of the challenging things about adopting that, of course, if you’re in the kind of cargo cult feature factory mode, is that you’re you’re probably looking for metrics and things that you can measure and look at and determine how well your factory is running. And the challenging thing is there’s not a Jira plug in for conversational quality. Right.
Jeffrey: I think there could be.
Squirrel: There could be, yeah.
Conversations make the Company
Jeffrey: Before this why don’t people look for evidence of their conversations. Maybe that’s something that change will happen from the book is people will start saying, ‘hey, am I being curious? Am I being transparent? And you could poll the team. You know, you could say from our stand up today. Here’s a poll. You know, to what extent were you curious?
Jeffrey: To what extent were you transparent today?
Squirrel: Count the number of genuine questions to ask today? That would be exactly interesting metric, that it would be a qualitative metrics metric. It wouldn’t be rigorous in the way that burn up chart or story points or something like that is. And therefore, it’s going to be more challenging to adopt. So that’s why the theories and ideas in the book, we think are going to be tough for people to adopt. But really, really rewarding when they do, because it does require a steep change in your thinking. You have to think about conversations and people as first class elements of your software organisation. And that’s a huge shift.
Jeffrey: So hopefully people now will have some sense of why they want to read Chapter one. It’s gonna give you the history of the industry going back from the 90s to today. It will talk about these different waves that have come through. And we talk a lot about their people centric nature, about how each in their own way was leveraging the properties and powers of humans. But then when they end up being missed, either because people go back to the Taylorist type mindset, usually by accident, more than design, or they end up focussing on kind of a cargo cult approach and miss that human, you know, centric nature of these processes. And when they leave the humans out of the equations and then wonder why they don’t get the results, we’re trying to help people bring the humans back front and centre and say, by the way, there’s techniques and skills. You can learn to work effectively with these things that are otherwise invisible.
Squirrel: Sounds great. Well, if you’re human and work with humans, then this book’s for you. So please have a look at it. Agile Conversations link in the show notes or just search Google. And of course, we also like hearing from you so you can find us at ConversationalTransformation.com. Also, AgileConversations.com works thanks to someone who was very kind to sell it to us a few months ago. So you can find us at any of those Web site addresses and you can e-mail us and tweet us and carrier pigeon and anything else you want. We’d love to hear your stories of working with humans where you’ve been stuck in a feature factory and what difficulties you’re having in addressing that and the questions you have about the book. So please do get in touch with us. We also are here every week and we’re going to be talking about each chapter of the book as we go through the highlights, as we did today. And we’re going to go through trust and fear and why and commitment and accountability, all the conversations that we cover in the book. So if that sounds interesting, the best way to make sure you hear us every Wednesday is to hit the subscribe button or whatever it is you use and make sure that you’re listening to us each week as we come out for troubleshooting Agile.
Squirrel: Excellent. Thanks, Jeffrey.
Jeffrey: Thanks Squirrel.