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

4608Re: Inside Steve's Brain

Expand Messages
  • Arlen Bankston
    Jun 10, 2008
      One other way to view Agile methods is that they continuously deliver
      "value." While this certainly consists primarily of software, Agile
      approaches have, at this point, been used outside of pure software
      development with a degree of success; from packaged software
      implementations (kissing cousin) to pure business projects (no
      programmers at all).

      "Value" can be:
      - Software that delivers on a portion of our business case
      - Information critical to realizing our business case (prototypes,
      spikes, etc.)

      Agile quite often relies on the software itself to deliver the
      information noted in the second bullet, but sometimes there are
      better/faster ways to get it that don't involve programming. The
      definition of "done" may differ ("the [COTS] company profile should be
      completely configured so that new policies can be entered," or "this
      model of our phone must allow for accurate all-weather testing of
      compound A5"), but you're still focusing on following one path to the
      end before starting down twenty others. Even with concurrent
      set-based design, you're still focusing on completion with minimal

      Ron's point is clearly valid regarding Agile Software Development (as
      one of the Manifesto signatories, it's hard to argue with his
      credentials!), and it avoids the slippery slope of defining "value" in
      such a way that it conveniently begins to reflect whatever artifacts
      you were producing before. Where I've seen it done successfully, the
      non-software value is primarily delivered by other Team members (e.g.
      designers), while the developers focus on the software. This allows
      as much exploration as is necessary, so long as there is actual
      development work being steadily delivered to the team.



      --- In agile-usability@yahoogroups.com, Ron Jeffries <ronjeffries@...>
      > Hello, Robert. On Tuesday, June 10, 2008, at 8:03:31 AM, you
      > wrote:
      > > Ron Jeffries wrote:
      > >> I meant that Agile Software Development is about software
      > >> development. It begins when the project begins, with software pretty
      > >> much that day. If someone wants to spend time dreaming or designing
      > >> or such prior to authorizing the software project, that is, in my
      > >> opinion, outside Agile.
      > > So I guess this is a similar resolution to another recent discussion
      > > on this list. I can understand the distinction you want to make, but
      > > I don't think it's very helpful, especially on this list.
      > With all due respect, I'm not at all sure that you do understand,
      > not entirely because we don't agree, although that might be playing
      > into it, since I suffer from that disability where one thinks that
      > smart people must ultimately agree. :-)
      > > I understood "software development" to be a broad inclusive term, and
      > > so covered, for example, UI designers: but you seem to be using it
      > > simply to mean "programming". Is that right?
      > No, not just programming. But I do mean the term to refer to the
      > course of actual development of software according to Agile
      > principles.
      > One of the essentials of Agile Software Development is "early and
      > continuous delivery of valuable software." As such, it seems to me
      > that while there might be lots of usability activity going on, and
      > that would be just wonderful, there //must// be software being
      > developed, or it isn't an Agile project at all.
      > Suppose that software is not being written now, but we are doing the
      > envisioning of software, the creation of fantasies about software,
      > imagining software, deciding whether or not to write software or
      > what software to write, or other just plain thinking about software.
      > What is that activity? I'm not sure. But it isn't Agile Software
      > Development because No Software.
      > Mind you, those may be important, even critical activities prior to
      > actually starting the project. It's just that since Developing
      > Software is a sine qua non to doing Agile Software Development,
      > activities like this, in the absence of Developing Software can't
      > possibly be part of an Agile project.
      > Now more to what I take to be our purpose here, these activities
      > certainly are also vitally important /during/ the project.
      > In my opinion, until a team is producing "Done" software at the end
      > of every iteration(*), it cannot claim to be doing "Agile Software
      > Development", or at least cannot claim to be doing it very well.
      > So what might go on before that could be incredibly wonderful and
      > valuable, and it could be a critical precursor to the project, but I
      > don't see how it can be Agile Software Development without ...
      > Software Development.
      > > It seems unreasonable to
      > > me, as UI design work strongly affects the software.
      > Yes, of course UI design work strongly affects the software. No one
      > is denying that. UI design might be critical to its success. Done
      > //inside// the Agile cycle, it can and should be a key part of Agile
      > Software Development.
      > Done //outside// the Agile cycle, I don't see how UI work could
      > possibly be part of Agile Software Development, nor why we would
      > want it to be.
      > > It also seems unhelpful to put designing in a group with dreaming
      > > and authorizing.
      > Part of designing is often done prior to authorizing the project,
      > and prior to actually initiating the project. As such it //is// in a
      > group with envisioning, authorizing, dreaming, and anything else we
      > do before we start actually doing the project. I don't have anything
      > against dreaming: I just distinguish it from other forms of work,
      > notably production of software.
      > Perhaps we have some disagreement on when an Agile project starts? I
      > suggest that it starts N days before the first delivery of software,
      > where N is the length of the iterations. (And no, I don't favor a
      > long zeroth iteration.)
      > Now "The XYZ Project" might be deemed to be started a year
      > beforehand, with people figuring out business models and wonderful
      > designs of all kinds. But that ain't Agile. With Agile, there
      > //must// be software. I don't see any way out of that without
      > completely redefining what we said at Snowbird.
      > > Further, it seems silly to put UI design outside of
      > > "Agile", when it has a process that is agile, and had it long before
      > > that was common in programming.
      > This argument seems to me to be specious. UI design may be "agile",
      > although it isn't always. But if we are talking about "Agile", it
      > seems to me that we need to talk about what was set forth in
      > Snowbird, and that includes the delivery of software.
      > > In a group on "agile usability", you seem to be suggesting that the
      > > main element of the process should be programming. I don't see how
      > > that makes sense, when you have not addressed how usability happens.
      > No, no, no. I am amazed at my apparent inability to express a simple
      > idea. A //critical// element of Agile Software Development is the
      > Development of Software. If there is no Software Development going
      > on, then there is no noun phrase for Agile to modify and therefore
      > there is no Agile Software Development.
      > The programming has an interesting aspect. The product cannot exist
      > without it, and in that sense it is a sine qua non. However, a great
      > idea or great design, or even a market blitz can sometimes transcend
      > a cruddy implementation. (Ladies and gentlemen, I give you:
      > Microsoft Windows!)
      > We must have programming (in one form or another). It's critically
      > important -- and yet it does not o'ershadow other critical elements.
      > > I still see this area as new, and I don't think there is a widely
      > > accepted way to bring UI design and usability testing together with
      > > programming in an agile process. You seem to want to some strong
      > > distinctions, yet I haven't seen any evidence that your approach leads
      > > to good software that includes good UI design.
      > For our purpose here, I do want a single strong distinction: Agile
      > Software Development is characterized by the regular iterative
      > production of software.
      > I'm not here to offer evidence. I don't know the answer to the
      > question. I'm just trying to keep us focused on a key question,
      > which is how to get good UI design //into// Agile Software
      > Development, rather than (for example) how to do it outside the
      > loop. To the extent that UX people try to do their work outside the
      > loop, I think we and they will lose.
      > > Have I missed something? Or is this word-play?
      > My answers here are: "Yes, I think so. No, emphatically not."
      > It is common in specialty groups like this one (and in groups with
      > names like "agile modeling" and "agile testing") to fall back into
      > looking at a way of doing these specialties "outside" the Agile
      > iterative cycle. The real value will come from those who recognize
      > that to use one's special expertise best in an Agile Software
      > Development project, one has to get //inside// the iteration.
      > Do you want to do UI in an Agile project? Super! If the Agile
      > project starts today, then two weeks (**) from today, and every two
      > weeks after that, we need real, value-bearing, software. "Agile
      > Usability" needs to get on board with that. Some folks, notably Jeff
      > Patton, are on board with that. Keep it coming!
      > Ron Jeffries
      > www.XProgramming.com
      > Speculation or experimentation - which is more likely to give the
      correct answer?
      > (*) There are branches of "Agile" who think that iterations are not
      > necessary. They agree that frequent delivery of value-bearing
      > software is necessary, and generally deliver more frequently, not
      > less so.
      > (**) Or one week, or a month. Some short regular cycle. Shorter
      > generally better.
    • Show all 140 messages in this topic