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

Working software: working for whom?

Expand Messages
  • William Pietri
    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
    Message 1 of 177 , Aug 9, 2008
      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."

    • Jon Kern
      thanks! (long threads? on this forum? :-) jon blog: TechnicalDebt.com View Jon Kern s profile
      Message 177 of 177 , Aug 20, 2008

        (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:
        > Jon,
        > 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
        > <http://feeds.feedburner.com/aspadvice/lhVO> (My Blog)
        > http://www.linkedin.com/pub/0/539/b14
        > <http://www.linkedin.com/pub/0/539/b14> Linked In Profile
        > > -----Original Message-----
        > > From: agile-usability@yahoogroups.com
        > <mailto:agile-usability%40yahoogroups.com>
        > > [mailto:agile-usability@yahoogroups.com
        > <mailto:agile-usability%40yahoogroups.com>] On Behalf Of Jon Kern
        > > Sent: Monday, August 18, 2008 8:25 AM
        > > To: agile-usability@yahoogroups.com
        > <mailto:agile-usability%40yahoogroups.com>
        > > 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
        > <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
        > <http://technicaldebt.com>>
        > > View Jon Kern's profile <http://www.linkedin.com/in/jonkern
        > <http://www.linkedin.com/in/jonkern>>
        > >
        > >
        > > aacockburn said the following on 8/17/08 11:41 PM:
        > > >
        > > > --- In agile-usability@yahoogroups.com
        > <mailto:agile-usability%40yahoogroups.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
        > >
        > >
        > >
        > >
      Your message has been successfully submitted and would be delivered to recipients shortly.