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

iterations, continuous flow, kanban ...

Expand Messages
  • Ron Jeffries
    Welcome to one of the few remaining yahoo groups where you can talk about pretty much anything as long as you are at least half-civil part of the time. Lately
    Message 1 of 187 , Jul 24, 2009
    • 0 Attachment
      Welcome to one of the few remaining yahoo groups where you can talk
      about pretty much anything as long as you are at least half-civil
      part of the time.

      Lately I've been hanging out, as is my fashion, on tons of groups,
      including kanbandev, which includes some really smart folks and some
      flaming dorsal orifices, some of whom, present company included, are
      the same people. Some interesting ideas have come up and I suggest
      we kick them around here, where we have an insatiable curiosity and
      a willingness to take things apart to see how they work.

      Here are some starting ideas:

      1. Brad Swanson reported some serious concerns about time-boxed
      iterations leading to trouble:

      > In a recent presentation comparing Kanban & Scrum at Agile Denver,
      > I asked the audience of about 40 agile practitioners if they
      > believed the time box of a sprint was a positive motivation. A few
      > lukewarm hands slowly went up. I then asked if it was common for
      > people to take short cuts (create technical debt) in order to meet
      > their sprint commitment, and the majority of hands in the audience
      > shot in the air. It's true that a team _can_ avoid the short cuts,
      > but I believe artificial iteration boundaries make it more likely
      > that they will take short cuts. I think the best way to manage a
      > team to remove that problem is to remove the incentive to take
      > short cuts.

      We've talked here many times about how pressure seems to lead us to
      let technical debt drift in, and most any coach has seen teams get
      in trouble owing to pressure.

      A kanban approach doesn't have iterations as such, so there is not
      as good a place for that kind of pressure to stand. Could it be that
      iterations aren't as good an idea as we think? Sometimes? Ever?

      2. Norbert Winklareth posted some very interesting theory-based
      ideas suggesting that reduction of Work In Process (WIP) is at
      the core of much of the improved performance that Agile teams
      often observe. For example:

      > While I acknowledge that the other models you reference are important and
      > must be considered at some point in time, I assert that the Queuing Model is
      > the most fundamental model of all. Your reference to code as being the most
      > fundamental is true about the work that we do, not about the system in which
      > we do it. Note that I stated that Little's [Law] is independent of the work.
      >
      > Let me demonstrate why I assert that it is most fundamental model. A core
      > XP practice is on-site Customer. The literature, Beck, Jeffries etc al
      > state that this improves both the quality and timeliness of communication
      > and decision making. The net effect of these benefits is that they shorten
      > cycle time. Another core practice of XP is yesterday's weather. This
      > implicitly reduces WIP. Pair-programming, craftsmanship improves quality,
      > which means that done is reached faster and this reduces cycle time.
      > Information radiators reduce cycle time. Retrospective improvements can
      > reduce either WIP and/or cycle time and so on. I do not know of any other
      > model that can replace this one to explain the improvement impacts of each
      > of these practices.
      >
      > My point about RTF, and by the way thank you for this phrase, is that until
      > this is reached the feature is a WIP item. Many a team and person, myself
      > included, have cheated on this and the functionality was not done and the
      > project was delayed and/or had serous quality issues.

      If it's true that reduction of WIP is a core contributor to how
      Agile processes work, what does that tell us about how we might
      improve what we do?

      3. Arlo Belshee has been using a continuous flow approach in his
      projects

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      But the attitude of faith is to let go, and become open to
      truth, whatever it might turn out to be. -- Alan Watts
    • 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
      • 0 Attachment
        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.

        Yep!

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        Accroche toi a ton reve. --ELO
      Your message has been successfully submitted and would be delivered to recipients shortly.