Are commitments the only way?

Have I told you folks lately how much I appreciate the answers I get here? I mean I’m grateful, and feel all warm inside, but also, I just really love reading them and learning what agile looks like in different places, for different people. I learn so much from you! So, if I haven’t said so lately (or even if I have), thanks.

So, last night, Justin @searls lit up twitter with this:

Agile friends: anyone out there still believe the “agile commitment” is worthwhile? My writing wants your (starkly opposing) viewpoint.

Later, once the conversation had taken off, he added this:

an agile team guesses what they can accomplish in an iteration, commits to it, and submits to ritualistic beating upon failure.

On the subject of commitments helping with trust, Zach @zspencer said:

Promises that are kept help. Promises that aren’t don’t.

To which Justin replied:

success is never certain, or commitment would be unnecessary. You’d recommend a team risk promising an uncertain outcome?

Wow. Big conversation. And there’s a question coming. First, the part where I ramble. :)

Are promises part of life?

…I don’t typically make promises. I have intentions, and I share values with people. I care about them having what they need to be happy, and I care about me having what I need, too. I love collaboration and I love getting things done. That’s something I want. But it seems to me a promise would mean I’ll do something even if I don’t want to, even if something changes so the original plan won’t work. Or even if I was wrong about what would, in the future, be possible (or a good idea).

If I “promise” to finish something by Friday, and I don’t, it may well be because I choose to do something else rather than finish. For example, maybe it took longer than I thought, and I valued getting some sleep and taking breaks more than finishing, for example.

Maybe I chose to organize my collection of e-books instead of working on the project.

Would a promise help with that?

If I did choose to organize files instead, we’d have a problem that’s not about promises, and not about Friday. It’s a problem the moment I lose interest in the thing we both want to create. Maybe it’s too hard (I feel stuck). Maybe I’m not engaged. Maybe I don’t have the tools I need. Maybe the environment at work is so pressured that I can’t think. A good retrospective might help us figure out what’s really going on.

But if we’re on the same side, you know that we both value what we’re working on together. Maybe in a particular case, “you” means a manager or business owner, and “me” means a developer. We share an agenda, a devotion to something of value, and we work toward that at a pace we find, not just sustainable, but exciting, interesting, productive. We work out a shared intention, and then watch what happens.

People often tell me I don’t really mean that I don’t make promises, so let me be really clear. My spouse and I don’t make promises to each other, either. If one of us were unhappy, neither of us would want that person to stay. No promise is required when we’re both doing what we value.

So that’s me. I would really like to know how promises and commitments look in your work. (I don’t mean to bombard you; there are a lot of questions here, but I’d welcome an appreciate an answer to one or two that jump out at you.)

Here’s what I’m wondering…

Do you use commitment on your agile projects? What do you mean by commitment? What happens if you “break” that commitment? What causes the commitment to be broken? What are the consequences?

How do you build trust on your teams? Or between your team and the business?

Have you found a way to work — successfully, in the world — without commitment? What does that look like? What changes when you work that way?

4 thoughts on “Are commitments the only way?

  1. rdm

    My idea of an agile commitment would be: “I promise to deliver something”. And, diving deeper into that, that something is based on a priority list. And, diving even deeper, that priority list winds up being subject to change as we discover where we are and what we can do.

    In other words, I promise to give my best effort, and my efforts tend to be pretty good. But, as a general rule, for software development, I cannot in good faith promise any specific deliverable except by delivering it.

    Ok, I can deliver something that has an arbitrary look — that’s a simple matter of arranging pixels. But when we get into how it’s connected to other things, and how people can work with those other things? Asking me to promise in that region is similar to asking someone to make promises on someone else’s behalf. If you already have their promises in hand, that’s one thing, but when you are getting into something new… when you are inventing new promises… you are in the realm of fantasy and supposition.

    Or, in a different very context, a commitment is what a car salesman wants from me. And, if I am wise, I am going to be very cautious and slow, about making big commitments. But that’s not agile — agile requires we be working towards shared goals. And if my commitment, to put forth my best effort towards that goal, is not enough? In that case, I think we are moving away from agile processes and towards something like buying a car.

  2. Glen Ivey

    I feel much more comfortable with the XP-style “we’ve got an ordered backlog and are going to work through it as fast as we can” (while doing a good job) than with Scrum-style sprint commitments. My current team doesn’t use commitments. We organize our work generally around goals for what functionality will go into each release and each iteration (we don’t always align them), but the details of that match-up almost always get adjusted during an iteration, and I think it allows us to do a much better job of matching what’s best for the business with what we can actually deliver.

    It also allows us to avoid the feeling of failure when we miss a “commitment”, especially when the miss was caused by something that originated externally during the middle of the iteration. Double-especially when reacting to that thing, instead of trying to postpone it until the end of a sprint, produces a (much) better business result.

    The other side of the problem with commitments is that they lock in the Product Owner at a much higher level of granularity. The rule that we use in my team is that the PO is free to reprioritize any story that development hasn’t actually started on. And this happens frequently, without all of the inherent waste involved in trying to predict the future in unrealistic detail, and then having to rework and recreate all of that detail each time you want to make a change. I’ve seen teams with fewer developers than ours that had a person dedicated to maintaining “the plan” in Microsoft Project–pure waste. And the effort necessary to make commitments that you can actually keep the majority of the time is also waste.

  3. Alex Baranosky

    Commitments are almost impossible to make in software, and trying to do so often backfires making the developers feel guilty for being professionals, and the product owners upset for being misled.

    I prefer to say that we’ll do our best, and then do it, and if something gets in the way of timely delivery, responding to it the best we know how.

  4. Ingvald Skaug

    i like the Kanban way, letting WIP limit be the driver instead of commitments (like in Scrum).

    (see David Anderson’s article on Kanban vs Scrum, especially the part on “change catalyst”)

    this leads f.ex. to different focus in standup meetings: instead of watching the commitments (what did you do, what are you going to do etc) you focus on how the work of the team flows, removing impediments, identifying bottlenecks etc.


Leave a Reply to Glen Ivey Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>