Working software: working for whom?
- Hi, folks!
On the flight back from Agile 2008, I'm now catching up on all the
interesting conversation, including the many questions and comments
directed at me. I want to chew over it for a bit, as there are a lot of
great topics that have come up, plus plenty of new perspective from the
conference itself. But I did want to address one thing now, my views on
the meaning of "working software" in the Agile Manifesto.
Having talked with other people who were there at the time the Manifesto
was written, they mostly agree with Ron and Alistair: "working software"
was about getting people away from writing endless documents, instead
writing code that the team could see in action. So if we ask, "for whom
is the software working?" the original answer appears to be "the
programmers and the product owner".
In its historical context, I think that was a major advance, and a bold
one. By pushing on it a bit, I don't mean to suggest anything negative
about the original Agile Manifesto. But I think we can and must take it
In talking with people at the Agile 2008 conference, it's clear that as
a community we do also value released software, software that delivers
value, software that is working not just to a programmer's eye, but also
to a layman's. XP has it right in the practices. As Alistair points out,
it is there in the AM principles. (Honestly, I had forgotten about them.
They are very rarely mentioned, and (Althoughthe web page suggests they
are peripheral, a footnote.)
However, if you ask people casually what "working software" means in the
Agile Manifesto, then the most common answer I get is in line with the
original meaning: it's the narrow and special meaning of working where a
programmer or on-team non-programmer calls it working.
I'm sure this will seem like a small difference to a lot of people. But
I think it has several negative effects.
First, it falls short of our own true values. Nobody I talked to was
opposed in principle to releasing software early and often. Everybody
wants to do that. But often people are hesitant about it, because
circumstance, habit, or ingrained attitudes make it difficult. I'm not
diminishing that practical difficulty. But our core statement of values
should be about things we are striving for, not the things we think can
be done easily in the short term.
Second, it unintentionally excludes people we need on our side, and on
our teams. Quite a number of people I've talked to see Agile methods as
programmer-centered, and to a lesser extent business-centered. If we say
working software is just working for programmers or business people,
they're right. For the user-centered world, that leaves out not only the
wide variety of user experience people, but the actual users.
Third, it encourages an attitude that Alan Cooper pegged perfectly as,
"The operation was successful but the patient died." If we make any
software a product owner wants, that's not a bad thing. But a much
better thing to strive for making things that succeed not just in the
team room, but in the world.
Fourth, it's a danger to Agile newbies. The number one thing my new
clients refer to when talking about "adopting Agile" is the Agile
Manifesto. If they get the notion that delivering what some business guy
says are the most important things is enough, that whenever he wants to
release is fine, then we've set them up with an unnecessary risk of
project failure. Until they close that outer feedback loop and the
software is used by its intended audience, they may be storing up
trouble with every line of code they write.
So I propose that we, as a community, change "working software" to mean
really, really working. In service. In use. Actually providing value to
actual people. Working for the end user.
Since this caused some confusion in the last round, let me make clear
what I am *not* saying.
I am not saying that all software has to be released after the first
iteration. That we are always striving to release doesn't mean we get
there instantly, any more than a new Agile team starts out perfectly
prioritizing people over processes, or is 100% responsive to change.
Values are the stars we sail our ships by, not the ports we call at.
I am not saying that we need to be more specific about what "working
software" means, other than "as close to released as we can get". We
don't need to tack on "usable" for the usability people and "reliable"
for the QA people and "secure" for the security people. Every project is
different, and we can let people decide for themselves what is shippable.
Third, by valuing really-really-working software the most, I'm not
saying that other things are worthless. Ideas are better than nothing.
Designs are better than ideas. Code running on my workstation is better
than untried designs. Code running so the product manager can see it is
yet better. So too is software ready for in-lab tests, internal demos,
limited release, and public beta. But I suggest that these things are
increasingly good because they are increasingly close to software that
delivers value in the real world.
And fourth, by saying that I want people to focus on shipping doesn't
mean that I want them to ship too soon. The decision about when to
release and to which audience is a complicated one, and there are plenty
of legitimate reasons to delay. However, I want all agilists to have a
bias to ship, in the same way we want people to always lean toward
improving interactions, rather than buying tools.
In sum, I'm saying that when asked "Working for whom?" our answer should
be, " Working for everyone who cares."
(long threads? on this forum? :-)
blog: TechnicalDebt.com <http://technicaldebt.com>
View Jon Kern's profile <http://www.linkedin.com/in/jonkern>
Landes Eric (CI/AMM1-NA) said the following on 8/20/08 9:39 AM:
> Sorry I'm a little late to this. But Kanban means visual board, so I
> don't think it's an inaccurate term. The idea is that you have a board
> that shows your work. See my reply I just sent for references. Sorry
> didn't realize this thread was so long!
> Eric Landes
> Microsoft MVP
> <http://feeds.feedburner.com/aspadvice/lhVO> (My Blog)
> <http://www.linkedin.com/pub/0/539/b14> Linked In Profile
> > -----Original Message-----
> > From: firstname.lastname@example.org
> > [mailto:email@example.com
> <mailto:agile-usability%40yahoogroups.com>] On Behalf Of Jon Kern
> > Sent: Monday, August 18, 2008 8:25 AM
> > To: firstname.lastname@example.org
> > Subject: Re: [agile-usability] Re: Kanban meets Disneyland
> > my original reply had my recollection from my experience on a
> > 1995-1998
> > IBM MES project... that was how IBM subject matter experts
> > explained it
> > to me...
> > but wikipedia has an adequate explanation
> > <http://en.wikipedia.org/wiki/Kanban
> > do you equate doing "tasks/features/bugs" the same thing as demand
> > "pulling" inventory when the number of graphics card falls below a
> > certain level?
> > anyway, my primary point is, even if there is a parallel in
> > some oblique
> > sense to kanban, why introduce an imprecise term to our industry
> > borrowed from another industry? why introduce a term that, in
> > its native
> > industry, was derived for significantly different purposes
> > and intentions?
> > but i remain open and ready to be convinced that this term/concept as
> > applied to software is somehow novel and marketable to stakeholders.
> > jon
> > blog: TechnicalDebt.com <http://technicaldebt.com
> > View Jon Kern's profile <http://www.linkedin.com/in/jonkern
> > aacockburn said the following on 8/17/08 11:41 PM:
> > >
> > > --- In email@example.com
> > > <mailto:agile-usability%40yahoogroups.com>, Jon Kern
> > <jonkern@...> wrote:
> > > >
> > > > ah, ok. well, it isn't really Kanban in the manufacturing sense.
> > >
> > > Ah, well, actually it is exactly Kanban in the manufacturing sense.
> > > If you think there is a different meaning to Kanban in the
> > > manufacturing sense, please tell what it is, don't just
> > play riddles.
> > >
> > >
> > ------------------------------------
> > Yahoo! Groups Links