Jade: Hello, welcome to another episode of the Agile Weekly Podcast, I’m Jade Meskill.
Derek: I’m Derek Neighbors.
Clayton: I’m Clayton Lengel‑Zegich
Roy: And I’m Roy Van De Water.
Jade: Guys, today we wanted to talk about an article that will be published in Agile Weekly tomorrow.
Roy: Product tie in there.
Jade: Subscribe to the Agile Weekly Newsletter at AgileWeekly.com. Written by Allan Kelly, the title is, Commitment Considered Harmful. I know we have no opinions or thoughts about this, so this might be a very boring podcast.
Roy: I’m curious, why is commitment considered harmful? By who, maybe is a better question?
Jade: Allen has to say that he has seen through some of his interactions with clients and other people, that…this is a quote from him. Commitment protocol for filling an iteration is actively damaging for software development teams in anything other than the very short‑run.
Derek, you’re shaking your head.
Derek: I don’t know. Maybe it’s too many years of therapy coming out.
Jade: Too few?
Derek: If I follow the trail…when I first saw this article, I immediately thought that it was part of the no estimates crowd shtick of stuff.
Jade: He specifically states that he does not follow the no‑estimates crowd.
Derek: Yeah, but I certainly thought it was going down that route. What I tend to see is this pattern of, there’s something, there’s something, there’s something, and it’s all rooted in two things. Every software manager is evil and the people will manipulate the system or me.
To me, going back to McCarthy’s core protocols and the perfect boss, I expect to work in a place with fucking adults. At some point, how long can we basically say, the boss might manipulate me? Well then go to a fricking job that doesn’t have a boss that manipulates you.
That’s got nothing to do with commitment. The boss that’s manipulating you with commitment or estimates is going to manipulate you if you don’t have commitment or estimates either, because they’re a manipulating asshole.
Roy: Yeah, that argument’s just too broad. You can replace whatever with, there’s this thing that some people have used, so you don’t do it.
Jade: Let’s step back a second, though. We do a lot of consulting. We’ve been to a lot of companies. How many have you showed up at that are full of fully functioning adults?
Derek: Not a ton, but I think my problem is attack that problem. Don’t attack the lack of commitment as being a problem. I hear commitment. I hear estimates. I hear accountability. I hear all of these things.
The very first thing that was thrown out here is, “Well, you can’t have commitment, because people will game it.” Well, people will game anything. So if you have a culture that is OK with people gaming things.
Roy: We talked about it in the past that‑‑what is it? I think, Jade, you quoted somebody that said, “96% of a person’s ability to self‑improve is dictated by the system.” Do you remember who that was?
Jade: W. Edwards Deming.
Roy: There you go. That may be the same problem in this case. What if it is a culture of a commitment that is holding these people back from becoming the adults they can? Because they are currently being rewarded for making false commitments or for gaming the system.
Derek: Right. I would argue that in that point they’re not really making commitments. The word ‘commitment’ is being bastardized to control somebody to say, “You have to tell me how much you’re going to do,” and then I’m going to threaten you, or lord over you, or manipulate you.
Jade: They’d beat you with a stick.
Derek: Beat you with a stick, beyond that. Well, to me, that’s not a commitment. A commitment is me saying what I really can believe, and me truly believing in that and doing that. That’s not somebody else saying, “Hey, Jade. I want you to commit to mowing my lawn tomorrow. All sorts of bad things are going to happen if you don’t mow my lawn. You’re OK with that, right? Your job is depending on it. You’re OK with it?”
I feel like to me, that’s not a fair thing for commitments, or for estimates, or for anything else.
Jade: No. I think that what we would argue if we were working with a team, and they said, “Well, we’re doing commitments.” I think from our point of view, we would say, “OK. Why don’t you look at the work that you do?” Maybe the team, they look at one story, and they say, “This is all we can do.”
The manager, I think the way that people abuse commitment, and say, “Hey, you guys have 150 hours over the next sprint, that all you are going to be working on this.” You have to have 150 hours of work to do.
I think we would say, “If you want to commit to doing 20 hours of work, and that’s all you want to commit to, that’s all your going to commit to.” That’s an acceptable scenario, as far as I think we’re concerned with how commitment works. That’s now how most people… Bad managers aren’t going to abuse that, and so that comes out his commitment is bad.
Derek: What about the idea though, if you’re feeling rushed, and that making the commitment is the most important thing above all else, like keeping to your word, the idea that you allow quality to suffer because of that. That you might choose to take some shortcuts or to cut some corners, because you are trying to push it out the door.
You don’t necessarily do all the good practices that you want to have, and maintain a quality suffer project. Those things will buildup over time to create a ton of technical debt that you can no longer maintain.
Jade: Yeah. That’s just part of, I think, if you’re committing to doing something and you have some standard for what it needs to be done. If the standard of done means half‑assed, then, OK, fine. No, that’s not really how you want standard done.
I think that is part of the bigger picture of, “What does it mean to be done?” If we’re going to rush through something, are we really done? Did we really “hit our commitment”? Probably not.
Derek: I think that it’s kind of the straw man out there, right? People like to throw it out. I see so many teams that have no sense of commitment that have really crappy quality.
Like to me, those things are not linked. I think what happens is when somebody is forcing you to the trough to drink water and really just slams your head in, you’re going to do stupid things. But I don’t think that’s because commitment is bad.
I would say that a team that is truly committed and committed in everything they do, they say, “Hey, we’re going to have…we’re going to write tests first. We’re going to make sure that our product owner is happy with the work that we’re doing. We’re going to commit to all these things and we’re going to commit to do what we say we’re going to do.”
You can’t say, “We finished everything, but it doesn’t meet the product owner’s requirements and it’s not tested and it’s not…” because at that point you don’t have a commitment either.
Jade: But technically, it’s done.
Derek: I know…
Jade: The way you said, the phrase, “Do what you say you’re going to do.” I think that was a big shift that we had an [sp] integrim of the concept. It sounds so simple, right? Do you what you say you’re going to do.
I think that’s really to me is what commitment means. I’m going to say I’m going to do something and then, I’m going to do it, but that’s not easy.
Derek: No. It’s not easy and I think commitment isn’t easy. Like committed to do something is difficult, right? But it doesn’t have to be this, you know, abusive tool.
Jade: I think to me the thing that I really love about Agile when it’s done really, really well is it becomes the truth killer. So if you can go around and say, “My team is so awesome. I’m so awesome,” and all this stuff and make all these promises and never, ever fulfill them like you’re just a lying piece of crap.
Who can trust you? Whereas, if you say, “Hey, I can only do this really, really small thing,” but I think a lot of developers have problems with this because when they say, “Oh yeah, I can do this. I do this,” and somebody says, “OK, so you’re committing to that and I’m going to kind of hold you to that. Let’s talk about it at the end,” and then, you can’t do it.
The developer doesn’t say, “Man, maybe I think I’m way full of myself and I should not commit to nearly as much, less time, next time. I should commit to half of that, because I didn’t even get close.”
Instead they say, “Well, the problem was this and the problem was that.” Everybody else in the world was the problem and it wasn’t me.
I think that’s just…if you’re honest with yourself about wanting to improve and you really want feedback, the only way you can do that is to measure yourself. So if you’re not saying, “I think I can do X,” and then, going out and doing it and measuring can you do it, how the hell can you improve?
Derek: So we can go from the standpoint of commitment adds at least some level of stress to the…
Jade: True, it does.
Derek: …to the developer, right? Because now they are kind of freaking out about this promise that they made and trying to keep it. But what positive benefit does a commitment actually get?
If I’m a developer making a commitment, what benefit do I get by, other than stressing out about it? Is that stressing out, is that the benefit that I get? That I get more accurate at estimating sounds, I get more accurate at committing sounds great.
But getting better at committing if committing itself doesn’t give me any value, am I just getting better at something that doesn’t matter?
Jade: I think you can build some trust. Or if you say you’re going to do something and you do it and you repeat that multiple times, you can build some trust that when you say you’ll do something, you’ll do it.
I think, it also is a discipline thing. Having a commitment, I think, helps you be disciplined. Discipline, I think, is a very difficult thing to have in software development.
A lot of teams lack that and I think that’s just another mechanism that helps reinforce that.
Derek: I think the other thing is commitment is a two‑way street. It’s not just the developer who’s committed. The idea is that I’m saying, “I will do this if you don’t bring in anything else to me to do during this period.”
Jade: Like the [sp] Schrum?
Derek: Yeah. I mean, I think it’s part of the whole contract. So when people say, “Like we do Schrum, but we don’t do this and we don’t do any of this stuff.” It’s like, “Well, how can you even live up to the basic premise of Schrum, which was we’re going to agree to do X, Y, Z, you agree to leave us alone?”
One of the things I’ll add is any developer out there that thinks that estimates, commitments, everything else are horse crap, come work for me and let’s talk about how we pay you. Is every week I’ll decide what we pay you?
I’m not going to tell you what you get paid until after you’ve done the work and it’s entirely negotiable up to me whether I think you deserve the money or not. You may get money. You many not get money and you’re going to be happy about it.
That’s what you do to every damn product owner you work with when you have no ability to say, “This is what you’re getting.” They’re spending money on you. They are giving money to you to do a job.
If you don’t do what you say you can do, and you continue to extend…this is why so many companies have problems is contractors or independent third‑party companies where they get to the point where they’ve not delivered what they said they were going to deliver and everybody ends up pissed off and everybody gets sued.
This is why this happens. I think it’s almost juvenile or naive to think, “Why can’t we just meander and do whatever we want and you just pay us?”
Man 2: This state of affairs would be totally unacceptable in just about every other industry.
Derek: Sure, it would be.
Jade: What is it about software development that allows people to think that that’s OK?
Derek: It’s creative. It’s an art. It’s an unknown magic. I give money to this group of people that have weird social habits. That I do not understand and I have never experienced them before. They do some magic.
The type of the keyboard and magic happens. Then, they have this thing that I cannot possibly understand how it works. I could never possibly do it myself. I couldn’t learn how to do it.
So, I just have to keep appeasing the magic over here.
Jade: But this happens to people that do understand that world as well.
Derek: That goes back to the hope thing, then, right? If people are hoping that…at the beginning of this, you could have the worst possible sprint and have a retrospective where you’re talking about all these terrible things.
A lot of times when the sprint planning starts the next time, it’s like, “OK, we have a clean slate. Everything’s in the air for this time. Everyone is very hopeful.”
Because people want to be hopeful, right? They want to think that this time’s going to be different. So they repeat the same mistakes.
Jade: Robo Roy did you have something to say?
Roy: If I hold this is in, maybe it’ll get better. It’s getting better.
I think that’s one of our things is we don’t see ourselves as developers. Often times, it’s somebody delivering a service of some kind and having an output. I think failure is OK.
I think it’s entirely OK, but the failure shouldn’t be that we aren’t able to deliver something. It’s whether what we deliver or not necessarily is usable or meaningful, right?
We should be able to deliver something that somebody can learn from. The business should get something at the end that they can put into practice and say like, “Oh, this is right or this is wrong.”
Derek: Do y’all know the [inaudible] you’re saying?
Derek: I’m just going to sell it now.
Roy: I think ultimately we just…as practitioners if we could do what we say we’re going to do, that would go so much further than where we currently are today, it’s not even funny.
Jade: So how do we get there? We’ve got two minutes to solve this problem.
Derek: Hey, I didn’t commit to anything. I would say the best thing that I think works for teams if they want to improve commitment is basically really take a deep dive in look at what it means to do what you say you’re going to do and also, understand that you can say you’re going to do smaller things than other people want you to do.
I can commit to less work than people want me to commit to and if I can do that and have success and build and learn and inspect it to death and improve, I think that is a better long‑term outcome than basically lying every time and not ever fulfilling my promises.
Jade: Is that part of the major problem?
Jade: Is that people can’t reconcile that fact?
Derek: They don’t feel empowered to say no to those things. Either by themselves or by some other constraint.
Roy: I think they are stupid on purpose, too. Most teams I see are still doing two week sprints, still doing like…I mean, if you’re not able to do what you say you’re going to do, go to a smaller block of something and say like, “If I say I’m going to do this in the next two hours, can I really do it.”
You’re much better off at failing at doing something in two hours, then you are failing in doing something in 10 days or 15 days.
Derek: I was working with a team and I ripped down the board and said, “Show me what you can do in one hour.” They couldn’t do it.
Roy: I think that’s a big problem. I don’t think it’s a matter of not allowing people to be creative or not giving them license to do something.
I think in teams that are high‑performing, they are not doing a bunch of planning. They are not doing a bunch of estimating, but they don’t need to because if they say, “Hey, we can deliver you something kick‑ass in four weeks.”
There’s trust that they’re going to do it in four weeks. I don’t have to think twice about it, right? Where you have to get into the legalism of things are when there is absolutely no trust.
The problem is the only way to build trust is to do what you say you’re going to do. Until you can do that, you’re screwed.
Jade: Tell us what you guys think about commitments. Any experiences that you’ve had with teams or yourself, failures to commit, all of these things.
You can find us on Twitter @Agileweekly, and on Facebook, facebook.com/agileweekly. Talk to you next week.
Announcer 1: If there is something you would like to here on a future episode, get over to intergramtech.com/podcast where you can suggest a topic or a guest.
Looking for an easy way to stay up‑to‑date with the latest news, techniques and events in the Agile community, sign up today at agileweekly.com. It’s the best Agile content delivered weekly for free.
The Agile weekly podcast is brought to you by Integram Technologies and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integramtech.com or subscribe on iTunes.
Announcer 2: Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile hotline. It’s free. Call 866‑244‑8656.