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

41807Re: [scrumdevelopment] What does agile really mean?

Expand Messages
  • matt gelbwaks
    Oct 9, 2009
    • 0 Attachment
      I love your analogy, but the one point you forgot to include was that the answer is "it depends upon what your client's expecatations are."

      m

      On Fri, Oct 9, 2009 at 7:00 AM, Malcolm Anderson <malcolm.b.anderson@...> wrote:
       

      Hi Joshua



      On Thu, Oct 8, 2009 at 7:31 PM, Joshua Partogi <joshua.partogi@...> wrote:
      >
      >
      > What is your experience as a Scrum Master or Coach when dealing about
      > this perception from someone that does not really understand what
      > agile in software development really means? Is agile in software
      > development really mean to deliver a software real fast? Or is this a
      > misperception from some people when translating the word agile in
      > software development? Or perhaps I am the one that got the wrong
      > perception about what agile really means?
      >

      To simplify the other great answers from Roy and Dan; Yes, it is a
      misconception that "agile" is going to make your software development
      process faster.

      If you have good disciplines, your team is going to seem to slow down.

      The speed savings (in my experience) tend to come from the work that
      your team doesn't do. Agile teams (once your customers are used to
      getting software once or twice a week) quickly stop building software
      that their customers *MIGHT* need. This frees the team up to do more
      work for more customers.

      The speed savings (in my experience) also come from the debugging that
      your team doesn't do. I'm going to make some numbers up that feel
      right (and if someone can point to the research that either supports
      or contradicts my numbers, I'd appreciate it) but, the debugging time
      that a normal team spends at the end of a project hacking it into
      "deliverable" is cut down at least to half, probably closer to one
      third. The problem is that this debugging time is not budgeted so it
      seems like spending that debugging time up front is slowing the team
      down.

      To grossly oversimplify it:

      Which is faster, getting from New York to Miami at 40 mph going down
      the eastern sea board, or going 100 miles an hour via Seattle and LA?

      Malcolm



      --
      Cheers,
             m
    • Show all 15 messages in this topic