This post is adapted from 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.
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.
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?’
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.
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.
We 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. And I think many different companies, many different teams, have gone through the question of “what does done mean? Does done mean done?”
We even have a definition of done in Scrum and…I don’t even remember which methodology it’s in, but there’s the idea that you define what “done” is. Isn’t that enough?
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.
In reviewing the chapter we were 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.
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, 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?
The conclusion is nobody knows what a concept is. So if you go and ask people, for example, the classic example is you ask ten people whether a clock is furniture, and you will get ten 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.
To me, the interesting part, though, is where the problem comes in, which is that each of those ten people that give you their answer, they feel that their answer is obvious.
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, a 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.”
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.
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.
This fits 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 and even into your automated tests.
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?”
The Bare Bones of the Matter
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, the 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 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.
And this is a case where each particular bone there had very clear meaning. 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.
This story 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? 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.”
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.
This shows 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 they can go awry in various ways, including not actually agreeing on what it is they’re trying to build, without realizing it. And so, in a sense, building different pieces out of alignment.
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.”
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.” 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.
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.”
“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.
Finally, what you get ultimately when people realize 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.
We’re espousing Theory Y here, 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.