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

13471Re: [scrumdevelopment] Stories and Algorithms

Expand Messages
  • Steven Farlie
    May 1, 2006
      I agree with all the things that you just said and I would never advise
      people to just cop-out on the tough stuff. Iterative development has been
      proven to be extremely effective in many situations. But I would never
      advise people to use it in *all* situations, just 99.9% of them.

      I have worked on algorithms before and they are quite unlike "normal"
      business software. They tend to have an innate complexity that appears
      quite irreducible. They are usually easy to test, in that they give right
      or wrong answers, but also difficult to test, in that the answer may take
      weeks or months to come out. If you are lucky you will have one person in
      your team that actually understands the problem and can work the solution.

      So I would advise Mike (though I don't really know the problem) to isolate
      the algorithm into it's own sub-project and give it to your resident
      genius. Leave the algorithm as a black box in the main project. It may
      seem unbelieveable to some, but many projects succeeded without
      Steven Farlie

      > Driving to find a way to slice a problem so it fits into iterative
      > development often leads to good things like:
      > - identifying concrete test cases before implementation
      > - discovering sets of inputs that are of no use to the customer (which
      > can sometimes lead to a less complex solution)
      > - being able to get valuable feedback early
      > - all the other things we get from the agile approach (rhythm, more
      > realistic estimates, early discovery of issues, elimination of waste
      > ...)
      > Just passing the more complex problems to the non-agile approaches is
      > a cop-out which will make it too easy to just not try to tame our
      > complexities.
      > On 5/1/06, Steven Farlie <steven@...> wrote:
      >> Not at all. I'm saying that you should recognise when a particular
      >> process
      >> is inappropriate for the task at hand.
      >> It's the old "when you have a hammer everything looks like a nail"
      >> problem. Put down the hammer (iterations) and find the proper tool for
      >> the
      >> job. Mike may need to move the algorithm work into a subproject with a
      >> more appropriate methodology.
      >> There are plenty of other methodologies out there. A lot of them worked
      >> for someone at some point in time for a particular problem. Perhaps
      >> their
      >> problem was similar to Mike's.
      >> --
      >> Steven Farlie
      >> > Does that mean just do not solve this problem or any other problem
      >> > that you cannot fit into iterations?
      >> >
      >> > On 4/30/06, Steven Farlie <steven@...> wrote:
      >> >> What made agile successful was not that they magically found a silver
      >> >> bullet to solve all problems. Instead they discarded preconceived
      >> >> notions
      >> >> and dogma to experiment with process and find out what works for them
      >> >> and
      >> >> what doesn't. It just so happened that a lot of other people had the
      >> >> same
      >> >> problems that they did.
      >> >>
      >> >> My suggestion is that you go the agile way and stop trying to crowbar
      >> >> this
      >> >> problem into iterations.
      >> >> --
      >> >> Steven Farlie
      >> >
    • Show all 16 messages in this topic