This is a transcript of episode 125 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.

Moving on to Chapter 6 of Agile Conversations, it’s time to talk about commitment. Not engagement, which we argue is insufficient to produce effective results, only enthusiasm that is far too often misdirected out of confusion about what important words mean and how to measure progress. We offer specific tools for effective commitments and hear a story about a company that created a pile of bones instead of a Walking Skeleton.

Show links:

Listen to the episode on SoundCloud or Apple Podcasts.

Introduction

Listen to this section at 00:14

Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.

Jeffrey: Hi Squirrel.

Squirrel: Hey, we’re almost done with the book, aren’t we?

Jeffrey: Yeah. Chapter six, if you can believe it. Six of seven. So this is our continuing series where we’re going sort of parallel with–giving stories and context for–the various chapters. And today we’re talking about commitment, and particularly I think our focus today is about how engagement is not enough. And for me, that comes about because a lot of the management theory that I read these days, a lot of the management articles talk a lot about engagement. And our view is that that’s just not sufficient.

Squirrel: If your team is excited and interested and ready to go, surely that is enough? I mean, that’d be a great thing. I mean, a lot of what we hear people complaining about is ‘I’ve got this Agile team, and they stare at their shoes during stand up and they just can’t get excited about anything. They’re they’re not interested. So wouldn’t it be better if they were?’

Jeffrey: Well, yes, absolutely. So engagement is certainly good! We’re just saying it’s not sufficient. And this chapter actually is a little bit different than most of our previous ones. This chapter of commitment is really talking about elements of execution. And so we’re trying to say here about how to have an effective conversation so that you can execute effectively, not just building a shared understanding of what you’re doing or why you’re doing it, we’re going beyond that.

Squirrel: Yeah, we did those in the first three chapters, ‘Trust’ and ‘Fear’ and ‘Why.’

Jeffrey: Yes. Although there is an important element here: that we are trying to build a shared understanding of what it is we’re committing to, because I think that we often find that that’s actually part of the problem. We have people who are perfectly engaged, and yet disagreeing on what the commitment actually means is where we fall short.

Mutual Definitions

Listen to this section at 02:01

Squirrel: And you tell a story in the book about thinking, ‘oh, it’ll be done by Friday’ and it comes to Friday and ‘done’ didn’t mean the same thing to you as it did to the team.

Jeffrey: That’s right. And I think many different companies, many different teams have gone through the question of ‘what does done mean? Does done mean done?’

Squirrel: We even have a definition of done in scrum and…I don’t even remember which which methodology it’s in, but there’s the idea that you define what ‘done’ is. Isn’t that enough?

Jeffrey: Well, it turns out not exactly, because if we don’t agree on what those pieces we’re doing are…and there’s a lot more than just ‘will we know when we’re done?’ It’s also ‘what’s going to be done?’ So there’s a lot more that goes into this. I actually–in reviewing the chapter–was reminded quite a bit of domain-driven design. And the goal of understanding and building ubiquitous language, so that everyone on the project has the same meaning for all the components. So when we say ‘an account,’ for example, we know what we mean by ‘an account.’ If we say ‘a project,’ we know what we mean by ‘a project.’ If we mean ‘a transaction,’ we have the same understanding in ‘transaction’ and of what those life cycles are.

Squirrel: I was trying to solve a problem that actually I found very interesting, and I remember a very wise person, Keith Braithwaite, introducing me to a book called The Big Book of Concepts. I can’t remember if I ever told you about it Jeffrey, but there’s this giant book in which a psychologist wrote down all of the studies, all of the results that psychologists have got in trying to understand what a concept is. What do we mean when we say ‘furniture?’ What happens inside our brains? What models do we create? And the really good thing–I read the book that you actually don’t have to, the only thing you have to know about the book is it’s really big, it’s like a dictionary–the conclusion is nobody knows what a concept is. So if you go and ask people, for example, the classic example is you ask 10 people whether a clock is furniture, and you will get 10 different answers and they’ll be all over the spectrum. You will not get a definitive answer. If we ask, is a chair furniture? You’ll get a clear answer. There’s a clear middle, but there’s all these complexities at the edges. And psychologists cannot figure this out. They’ve been trying for a very long time. They wrote a giant book about it and they have no idea. So the domain-driven design and trying to nail down what ‘done’ is is trying to solve this problem. There’s actually a bigger problem here.

Jeffrey: To me, the interesting part, though, is where the problem comes in, which is that each of those 10 people that give you their answer, they feel that their answer is obvious.

Squirrel: Exactly. And they think everybody else knows that, too. ‘Of course, a clock is furniture. I’ve got a grandfather clock in my sitting room.’ ‘Of course, clearly, clock is not furniture. What do you mean? It’s this small thing that sits on the side of my bed. It sits on furniture. It’s not furniture.’

Jeffrey: Right. And everyone with their own concept in their mind feels perfectly clear. And so if you’re having this discussion, everyone has very obvious concrete examples in their mind, but they’re not sharing their examples. So in effect, they’re using the same word, but not agreeing on meaning.

Squirrel: And that’s what we talk about in the first part of the chapter: a whole bunch of techniques for defining what a word means through a conversation, making sure that you really do align on what the concepts mean, and if your application is all about furniture, do the clocks go on the furniture page or not? Another very nice one here that we should link to in the show notes is Gojko Adzic’s Specification by Example. It’s all about exactly creating those sorts of examples that can help you to define the meaning, but if you don’t have the conversation, if you just assume that the other person knows, you’re going to be in a world of trouble.

Jeffrey: And I think this does fit with our overall message, our core values that we stress right in beginning the book: the need for transparency and curiosity. So the ability to be mindful, to say ‘we should be sharing our examples,’ the exemplars that we have in our mind when we say ‘clock,’ and be curious about other people. So when you’re thinking ‘clock,’ what are you thinking here? When you’re saying ‘a transaction,’ what are you considering a transaction? What’s not a transaction? Get those examples. And as you describe, this justification by example is a way of then codifying those into your project.

Squirrel: And even into your automated tests.

Jeffrey: That’s right. So agreeing on a meaning is a first step for us about having a commitment conversation. But then there’s also this element of ‘what are we actually going to create?’ And you were telling me about a new problem, well, not a new problem, but a new phrase that you’d come up with, which was ‘a pile of bones.’’

Squirrel: Sure.

The Bare Bones of the Matter

Listen to this section at 06:47

Jeffrey: That we talked about many, many times before on this podcast, I believe, about a walking skeleton, but this is the first time you’ve brought up a pile of bones. Tell me a little more about that.

Squirrel: Sure. So just to remind listeners, the walking skeleton is an idea that goes all the way back to Alistair Cockburn in the 90s. What you do is you create a system that has the very, very basics. It’s not a minimum viable product. It’s even more basic than that, you couldn’t really put it live. But it exercises all the pieces, and then you add bones, meat and then flesh and decoration and clothes and things to the skeleton, until you have your whole application that actually does the whole thing. We go through several examples in the book. But I have a client who is very painfully going through the process of trying to understand all of the bones, thier different components that their development team created. They let their development team get very fractured, and so each one worked on a tiny piece of the whole system. They never put it together! So actually, one of the things I’m doing is–they brought me in–is to say, ‘OK, well, let’s have everybody to stop trying to put it together, stop trying to create all their pieces. Can you just tell me what pieces we’ve got?’ Because they’re not even sure. And because they had never tried to put any of the pieces together, they don’t work together, which is no surprise. And they’re having a terrible time delivering the system. No surprise. And they have had no chance for feedback. The few times that someone has actually tried out a couple of pieces trying to work together, a bit of an arm, for example. They say ‘this is completely wrong. This is not what I’m looking for.’ And this is the sort of thing that is the worst example. This is kind of the worst case you can get to. But I bet our listeners have many examples of partial piles of bones rather than walking skeletons, because this is a very common pattern.

Jeffrey: And this is a case where each particular bone there had very clear meaning.

Squirrel: Yeah. They had detailed requirements. They had a full specification. They were doing their unit tests. And they were verifying within their own piece that it worked correctly. Problem is, nothing worked together.

Jeffrey: Right. And when I hear this story, to me, it takes me way, way back to the pre-Agile days and the problems of upfront design and documentation-driven development. So very minute specifications of each piece, but not a good way to say, ‘does it all fit together? And when it all fits together, is it actually giving us what we want?’ So part of this walking skeleton is sort of a technical learning, but also then to say, you know, do we have a shape overall that we think works for us?

Squirrel: And what makes the walking skeleton so valuable is it gives you a place to hang your commitments. So you can say ‘I’m now making a commitment that these two pieces will work together by tomorrow. I’m making a commitment that I will be able to send a null message from point A to point B. The message won’t do anything yet. It won’t be valuable. You can’t give it to customers, but it’ll be valuable in the sense that I know that the message traffic can actually pass over the wire that I’m intending to use.’ And using that kind of a framework gives you a way to gradually build up the system, and avoid the pile of bones that my client wound up with because they would have been able to say very early: ‘these two don’t fit together. You’ve got this putting the data in the wrong place for that one, and there’s nothing coming out in the graph.’ That would have been very helpful to them; if they had had it they would not have wound up with a pile of bones.

Jeffrey: That’s right. So this could show kind of why we say engagement is not enough. You might have people who are perfectly engaged, really trying to solve the problem, thinking creatively, and yet that they can go awry in various ways, including not actually agreeing on what it is they’re trying to build, without realising it. And so, in a sense, building different pieces out of alignment.

Squirrel: And agreeing on meaning gives you the way to kind of define it upfront, to understand what you’re going to be doing. And the walking skeleton and avoiding the pile of bones gives you a way to understand what’s happening as it’s going. So you can correct and say, ‘wait a minute, we’re not aligned on what these words mean.’

Jeffrey: Right. And for me, one of the problems when people skip over these steps, this agree on meaning and this walking skeleton or the other sort of steps they might take to ensure they’re getting the right outcome, then what can happen is that engagement can end up turning into disengagement. You have people who start off very excited, but then when things start falling apart, when it turns out that they’ve put effort and time into it and then they’re told, you know, ‘this is terrible, this is not what we wanted.’ Or they end up failing to deliver it in some fashion, then they start to feel like, well, you know, this is hopeless. And I often see this happen when you go through a sort of intermediate phase where first people are engaged and they’re committed, but they haven’t really been committed to the right thing. And then they start having problems, but then they’re not sure how to how to correct them. And so then you go through a phase of compliance. We’re like, ‘OK, this isn’t working, but I guess we’re supposed to just keep working on this. That’s what we’ve been told to do.’

Squirrel: And ‘hey, my piece, I understand at least I’ve got a specification. I guess I’ll just build that.’ That’s where my client was.

Jeffrey: That’s right. So people will be less committed to the overall project, the overall deliverable. Instead, they try to look at something small that they can do, and in that sort of way be compliant with the direction of, you know, ‘we’ll just do this or that, fine, I’ll do something. I’ll do something that I feel confident about.’ And this is kind of a defensive mindset now. People are now beginning to operate not because they think that what they’re doing can be successful, but rather because they say, ‘well, this is what I need to do to avoid being embarrassed or avoid being attacked or avoid being criticised.’

Squirrel: ‘Well, hey, Jeffrey, you know, I’m just going to do my best. This project’s in a lot of trouble, but that’s not my fault. I’m just going to do my best to make sure that my piece works.’ This is the kiss of death.

Jeffrey: Exactly. That’s right. And then finally, what you get ultimately when people realise that this is not working and that, yes, they may be defending what they’re doing, but overall, this is just not going to be successful…then ultimately, you end up with people being disengaged. And the reason, I think, is that people really want to be part of successful projects, and they’re willing to do extra effort to help the project’s being successful, if they know which work is going to be helpful. When that’s not possible…the question I ask people in a one on one will be, ‘are you able to do work that you’re proud of?’ And when they feel that cannot do work that they’re proud of, they really can’t maintain engagement.

Squirrel: You’re espousing Theory Y there, of course, which we back strongly and explain more in the book. Theory X, of course, would say, ‘yes, you can give people orders to do all the pieces and they don’t really care anyway. So they’re just going to be disengaged. So there’s no point.’ But we’re endorsing the idea that maybe engagement could be useful, but it’s just not quite enough. You need to make sure that it’s properly directed, and that there’s a feedback mechanism so you can figure out when it’s not. And that comes back to having a conversation.

Jeffrey: That’s right.

Squirrel: All right. Well, thanks to listeners for hearing us out on this topic. If you’re interested, of course, you can buy the book, Agile Conversations. The link in the show notes, as always, and you can get in touch with us if you’re trying these out, if you’re having trouble with commitment. If your difficulty is that you’re creating a pile of bones and you’re not quite sure how to put it together, that’s something we like to talk to people about. So you can find us on Twitter and email. Everything’s on ConversationalTransformation.com. You can go have a look there if you’re interested. By the way, there’s also an events page there, and we have two exciting events coming next week. We’re speaking as a keynote at I.T. Pro-Live. And I believe that’s on Monday, next week and then on Tuesday, next week, we’re speaking at the DevOps Enterprise Summit London, which is not actually London. That’s actually just the world, as most things seem to be these days. So if you’re interested in hearing us riff on more of these topics, you can certainly do that there. And finally, of course, if you hit the subscribe button, you’ll hear us every Wednesday as we come out with more Troubleshooting Agile.

Squirrel: Thanks, Jeffrey.

Jeffrey: Thanks Squirrel.