Ohno Agile vs JIT Was Re: [agile-usability] Re: Agile manifesto discussion / first 2 practices
(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).
Plus how do recover back to iterations when you are in a Twitter like experience? When all you can do is respond to disaster.
JamesOn Thu, Aug 14, 2008 at 11:15 PM, aacockburn <acockburn@...> wrote:
--- In firstname.lastname@example.org, William Pietri <william@...>
> Ok. A couple questions for both Ron and Alistair. (And anybody else,
> 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
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
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.