1. Nov 15th, 2006

    Commitment, Trust and Discipline

    Dmitri Zimine writes about the true cost of interruptions. Joel Spolsky contradicts by defending context switching. And Mishkin Berteig brings it back home by explaining the difference between hamburger management and discipline:

    “Why do we do it this way? The main reason is around trust and commitment.”

    “The trouble is, no one had really looked at the overall consequences. Everyone was doing local optimization.”

    I agree with Joel, cancelling the iteration is a drastic move that doesn’t sound responsive or flexible. In that respect, he’s absolutely right. It just happens to be the right thing to do(*).

    Because it’s all about commitment.

    Joel might be confusing agile with cowboy coding. Flaws and all, you have to respect that agile is a discipline. It doesn’t come from wishing, but from sticking to commitments.

    The opposite of discipline is not flexible, the opposite is chaos. It’s the reason projects run over time and over budget. Not lack of methodology, but lack of management.

    Is this interruption important enough to do? There’s only one way to find out. Make a commitment out of it.

    If it’s not important enough to make a commitment, it’s not important enough to cancel other commitments. You see, every interruption is self-justified. But unless you start managing them, you end up with nothing but a constant stream of interruptions.

    ADD project management.

    How do you respond to your clients? By making commitments and standing behind them. And by taking inputs to change those commitments.

    Because you’re making one promise to your clients, one thing they trust you to do. And it’s not a loose collection of local optimization. It’s to manage their invesment in the best possible way.

    And that takes discipline.

    (*) By which I mean, stay the course, or cancel the iteration.

    Photo by Velo Steve

    Posted by Assaf Filed in general

    1. Nov 15th, 2006

      Mishkin Berteig

      I’m a little confused… what do you agree with? You say “It just happens to be the right thing to do.” What’s the “it”?

      Oh, and thanks for the links! :-)

    2. Nov 15th, 2006

      Rogel

      What I understood from Joel was that he agreed that changing focus has cost, and it might cause a project (or iteration) to run late or over budget. However his claim was that although changing focus has its cost, it is sometimes necessary. His argument was that agility is to response to the business needs rather than to the agile methodology.
      “Yes, context switching is painful. Yes, you need to take into account the costs of context switching when you interrupt someone’s work. But every decision has pros and cons and when I hear a manager who is just talking about the cons without considering the pros, that manager is not doing their job.”

    3. Nov 15th, 2006

      Assaf

      Mishkin,

      The right thing to do is right there in your post: you either stay the course, or cancel the iteration.

      Which one you do depends on how important that sales call happens to be. But either way, it’s making a strong commitment.

      The “it will only take two minutes is just another form of deadly feature creep.

    4. Nov 15th, 2006

      Assaf

      Rogel,

      Dmitri’s argument is that you have two options. You stay the course, doing the client feature later (say next week, iterations are short). Or you cancel the iteration.

      It’s a tough call to make, but that’s exactly the point. Disruptions are disruptions, so be conscious and purposeful about them.

      The alternative is a form of wishful thinking, of trying to weasel “just two hours”, which never take just two hours.

      Sales are committed to closing a deal, which is always a local optimization. And if you let them continously interrupt, and interrupt they will, the project will run to the ground.

      They need to be committed to the project for the project to be successful. It’s perfectly fine to say “this is so big, drop everything.” But say it. Plan for it. Be committed.

      Manage those interruptions, or they’ll creep on you.

      Agile is in part a reaction to the inevitable feature creep, and these interruptions walk like and quack like a feature creep.

      Allowing interruptions is the opposite of being agile. Allowing changes to the plan, is being agile.

    5. Nov 15th, 2006

      Rogel

      preach to the choir Asaf. However sometime it is OK to decide that specific aspect of a project will be late if the business needs requires to divert the efforts somewhere else. This type of decisions are called management :)
      If I understand Joel correctly, his argument was that every decision has pros and cons and you can’t present only one of these.

    6. Nov 15th, 2006

      Assaf

      I’m reading the original article, and I can’t find anything that says no to change. All it’s asking for is a commitment.

      You want to change? Fine. But let’s make it just hard enough so changes are treated with the same seriousness as the effect they have on the project.

      Because if you try to weasel them in, they take over the project.

      Joel’s article contradicts that point. So they both agree change would, could and should happen. Just treat it differently.

    Your comment, here ⇓

    Or using OpenID