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

Ohno Agile vs JIT Was Re: [agile-usability] Re: Agile manifesto discussion / first 2 practices

Expand Messages
  • James Page
    ... Yes more.... Plus how do recover back to iterations when you are in a Twitter like experience? When all you can do is respond to disaster. James
    Message 1 of 1 , Aug 14, 2008
      (This is interesting and relevant because of the current interest in iteration-less kanban type
      scheduling, which is very interesting, but is "exposed" due to the absence of a people-focusing mechanism. Start a new thread if  you want more on this).

      Yes more....

      Plus how do recover back to iterations when you are in a Twitter like experience? When all you can do is respond to disaster.

      James

      On Thu, Aug 14, 2008 at 11:15 PM, aacockburn <acockburn@...> wrote:

      --- In agile-usability@yahoogroups.com, William Pietri <william@...>
      wrote:
      >
      > Ok. A couple questions for both Ron and Alistair. (And anybody else,
      natch.)

      > It sounds like you two are deriving Agile's iterative
      > cycles from the "working software" bit in the Agile
      > Manifesto. Is that right?
      >
      > Do you consider "working software" to be a boolean, or a range?
      > That is, can some working software be more working than others?

      I think you have the derivation pointed in some wrong direction
      (but can't say which).

      For me, I'm certainly not deriving anything from the manifesto.
      I started working on this problem in 1991, and helped with the
      manifesto in 2001. For me, the manifesto was trying to find a
      short way to sum up 10 years of research.

      Back in 1995, I started giving talks stressing that the one
      thing I cared about more than anything else for a project
      team was to deliver real system to real users at least once
      a quarter. In my 1997 Surviving OO Projects book, I listed that
      as the crucial first step, a critical success factor (imho).

      However, as some people have commented, actually getting a company
      to actually deploy a system to actual users can be very difficult,
      often out of the hands of the developers.

      So, separately, I had (also in that book) the topic of increments
      and iterations, and learning after each (I didn't call them
      reflection workshops until the late 1990s sometime, I think).
      The 1980s / 1990s alternative term for these was "timeboxing".

      Timeboxing was described as useful for anything (presumably
      including writing documents) in the 1980s, early 1990s.

      What I added back then was the insistence that it be increments
      of functionality, preferably vertical slices (UI to DB) rather
      than horizontal.

      The XP team (think C3, Kent, Ron, Chet, all them early pioneers)
      shortened their timebox to 3 weeks and liked it. Still insisting
      on running programs over docs.

      The Scrum crowd (think Ken S., Jeff S, Mike Beedle) had settled
      on a month, and at least back in 2001, were talking about "demos"
      every sprint (nowadays there's more talk about shipping every
      month).

      The point being, that we all started from timeboxes of various
      sorts, each timebox showing that something had been built that
      could be examined for correctness, something could be executed
      so that simply reading words in a document differently wouldn't
      produce differing interpretation of "will it work" or not.

      We were IIRC not particularly fussed over what would be run, just
      that it couldn't involve sleight of hand, smoke, mirrors or
      dead text. The catch phrase from the 1990s was
      "bubbles don't break", referring to the bubbles in the data flow
      diagrams popular at the time. The point of that was that
      bubble diagrams can have all sorts of mistakes in them you won't
      see, which the computer will expose when you program it up.

      Inverting "bubbles don't break", you get "working software"
      --- as opposed to who-knows-if-it-works paper, and with the
      idea that if it is broken and you show it to someone, they will
      see it fast enough. Flaws get exposed.

      The "working software" value doesn't lead to timeboxing or
      iterations. Timeboxing and iterations are a project scheduling
      mechanism to help people focus. (This is interesting and relevant
      because of the current interest in iteration-less kanban type
      scheduling, which is very interesting, but is "exposed" due to the
      absence of a people-focusing mechanism. Start a new thread if
      you want more on this).

      I choose timeboxing as the first agile practice to install, because
      it gives people a chance to pause and reflect after each.
      I choose reflection workshops as the second agile practice to
      install, because it calls for people to do that pause and reflect.

      I have done timeboxing and reflection with a couple of teams who
      had no interest in agile -- it was already useful.

      Once timeboxing and reflecting are happening, then the team is
      "moving" their habits, and once they start moving their habits,
      they can likely choose any of many good directions to move into.
      Shipping more often being one; more user involvement being
      another; more testing being another; and so on.

      I sure hope this helped - it was a lot of typing.

      Alistair


    Your message has been successfully submitted and would be delivered to recipients shortly.