Loading ...
Sorry, an error occurred while loading the content.

[XP] Re: iterations, continuous flow, kanban ...

Expand Messages
  • davenicolette
    Karl and Ron, Reading this thread is giving me a headache. Knowing both of you (or at least having spoken to each of you in person a few times), I m quite
    Message 1 of 187 , Jul 30, 2009
      Karl and Ron,

      Reading this thread is giving me a headache. Knowing both of you (or at least having spoken to each of you in person a few times), I'm quite puzzled at the level of hair-splitting you're indulging in here.


      Karl: We were doing 2-week sprints and we changed to a 1-week prioritisation cadence and a 2-week release cadence.

      Ron: In the absence of the time-box...

      Huh? /What/ absence? The team was /still/ doing 2-week sprints. They just changed the name to "release cadence." Looks like they introduced a one-week time-box, too. Any more time-boxes, and the process would look like a set of Russian dolls.

      Okay, so here's a story about a team I've been coaching for a few months. They're doing XP, and they've been doing 1-week iterations. They were feeling a lot of pressure to deliver something meaningful to production every week. Why? Because, as so many people tend to do, they interpreted the basic description of XP to mean they had to release a meaningful and useful increment of the solution all the way to production in every iteration. If they didn't do that, then they failed. They were bad people. It was time to don a hair shirt and flagellate themselves while walking on their bare knees over broken glass to the customer's office to beg for their very lives, whining "I'm not worthy! I'm not worthy!" all the way there. They were starting to feel as if "agile" was the worst thing that ever happened to them. This was the wrong kind of "schedule pressure," and it was completely unnecessary.

      I introduced them to a simple concept that's been going around the community for a while now: Decoupling the development cadence from the release cadence. I suggested to them that it was perfectly okay to deliver an increment of the solution every week to a staging environment where their customer could work with the new functionality. That gives the customer the opportunity to refine his/her thinking about the direction the solution is going, and to collaborate with the team to adjust course if necessary. Making the solution increment "potentially shippable" means that their work includes testing the deployment procedure to make sure the new functionality didn't break it.

      End users might be confused by new functionality that represents less than a usable feature, so there's no sense in releasing individual User Stories that don't add up to a complete feature. It's the customer's call to wave the green flag to release whatever stuff is in the staging environment to the real production environment. It's not a technical decision. Whenever they're ready, the code is ready.

      The "release cadence" is variable. Whenever a sufficient chunk of functionality is running with all tests passing in the staging environment, a release happens. So, the technical team has done its job as long as whole User Stories have been delivered to the staging environment and they're accepted by the customer. Decomposing the work into /small pieces that work/ is different from decomposing it into /increments that make business sense to release/. Therefore, those two goals don't have to be tied to the same cadence.

      The time-box is still in place. The team works on a one-week pulse. The value of the time-box for setting the pace of incremental delivery is not lost. All that is lost is the artificial pressure to deliver to production once a week. That was always a self-imposed pressure based on a literal-minded reading of XP practices. Changing the terminology relieved the pressure. It didn't actually change anything in a strictly mechanical sense. It was a psychological change.

      I don't see that kanban practitioners actually do away with time-boxes. The way I understand it is that kanban isn't /fundamentally based/ on the notion of fixed-length time-boxes. Teams that use kanban typically /do/ have some sort of pulse or heartbeat or cadence in their work. Corey Ladas tweeted a couple of months back that he's never seen a team using kanban that didn't iterate.

      Sprint. Cadence. Cycle. Iteration. Pulse. Rhythm. Heartbeat.

      It's just words, guys.

      WRT the notion of "dysfunctional" managers misinterpreting the weekly prioritization meeting as a delivery commitment, IMHO we have to coach management as well as technical staff.

      What Karl describes as keeping the queue filled with work is just what happens at the company where I'm working now. In fact, "commitment" is very explicit here. The team and customer jointly commit to stories in each iteration planning meeting. The team doesn't have to take a story whose acceptance criteria are unclear. They will commit to completing the story, and the customer must commit to being available for questions and for doing the acceptance testing. If the customer doesn't live up to those commitments, the story won't be promoted to the staging environment and the team won't be on the hook for that. Commitment is a two-way street.

      We're also careful to define commitment as a "reliable promise," in the sense David Schmaltz defines it, and not as a "guarantee." That means either party fulfills its commitment provided they (a) deliver on it as stated, or (b) notify the other party as soon as they realize they won't be able to deliver. This approach tends to encourage close collaboration without forcing the issue, and to keep people from feeling as if they've failed just because things don't always go as planned.


      P.S. Ron, check your email. Got a question about the pink book.

      P.P.S. Karl, still interested in London. Let me know if things are opening up there.

      --- In extremeprogramming@yahoogroups.com, "Karl Scotland" <kjscotland@...> wrote:
      > Hi Ron,
      > --- In extremeprogramming@yahoogroups.com, Ron Jeffries
      > <ronjeffries@> wrote:
      > >
      > > So I am wondering whether the absence of the time box would somehow
      > > make it too difficult for management to say "Hey, in the last two
      > > weeks, you guys only got seven things done. We need ten. Work
      > > harder." Put that way, I don't see why it'd be too difficult for
      > > them to come up with.
      > To me there's a difference between saying that, and having a
      > tool/opportunity to do something about it.
      > > I remain interested but not convinced. It seems if there is a
      > > prioritization cadence, it provides exactly the moment for our
      > > putative dysfunctional manager to say "Hey, you only did seven, you
      > > lazy slobs, and we need ten." So I don't see that there is
      > > necessarily that advantage due to kanban.
      > I think a time-boxed prioritisation/planning meeting sets expectation
      > even if there is no commitment. The number of items prioritised is based
      > on what the team might deliver within the time-box. Its this expectation
      > aspect which poor managers can use to apply pressure to the team.
      > A Kanban prioritisation cadence sets no expectation on what might get
      > done over a cadence. The prioritisation is rather restocking a queue to
      > ensure that the team always knows what to do next. Hence the
      > prioritisation is less of a tool/opportunity to pressure the team with.
      > I can see that's quite a subtle distinction. Possibly one of those
      > things you can only get by doing.
      > Karl
    • Ron Jeffries
      Hello, davenicolette. On Monday, August 10, 2009, at 7:52:58 PM, ... Yep! Ron Jeffries www.XProgramming.com www.xprogramming.com/blog Accroche toi a ton reve.
      Message 187 of 187 , Aug 10, 2009
        Hello, davenicolette. On Monday, August 10, 2009, at 7:52:58 PM,
        you wrote:

        >> Seems to me this is a quite valid thing to do, but that it's still
        >> managing scope.

        > That's fine. I don't want to get into a circular debate about
        > words. The key thing IMO is that we understand how to work with
        > that type of trade-off to the customer's benefit.


        Ron Jeffries
        Accroche toi a ton reve. --ELO
      Your message has been successfully submitted and would be delivered to recipients shortly.