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

Re: [XP] Sizing Agile projects

Expand Messages
  • seidolce1960
    ... Steven, So I understand, are you suggesting that measurement is a waste of time and so is estimating? If measurement is a waste of time exactly how do you
    Message 1 of 583 , Jan 31, 2008
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "Steven Gordon" <sgordonphd@...>
      wrote:
      >
      > On Jan 31, 2008 4:09 AM, seidolce1960 <David@...> wrote:
      > >
      > > Angela,
      > >
      > > While sizing iterations is important, the real key is to size the growth of
      > > the application.
      > > The delivered product. The iteration may or may not add any functionality
      > > to the installed
      > > application.
      > >
      > > It does not have to be an outside force measuring. I encourage teams to
      > > perform their own
      > > measurements and estimates. Once trained it should not take much time to
      > > measure (less
      > > than 1% of total effort).
      > >
      >
      > A critical part of what allows the agile approach to deliver better
      > results with less effort is the acknowledgment that the initial
      > requirements are rarely what should be delivered at the end of a
      > project. Even the requirements that remain intact from a high level
      > point of view will often have their details, organization, and
      > priorities re-arranged several times during an agile project.
      >
      > Iterative collaboration between developers and customers leads to the
      > discovery of initial requirements that are unnecessary bloat and new
      > requirements that could not be imagined until customers/users tried
      > out iterative deliveries of working software. This is what allows the
      > customer to drive the project based on what is being learned
      > collaboratively as well as how the market is changing during the
      > project.
      >
      > As such, even a 1% effort is wasteful when based on the details of
      > requirements whose content, organization, and priorities are changing
      > often. The current practice (I recommend
      > http://www.mountaingoatsoftware.com/book/1-agile-estimating-and-planning
      > ) is faster, sufficient and less resistant to change.
      >
      > > Estimates need to be evaluated on how they were derived and not what they
      > > say -- they
      > > are what they are. Estimates need to be based upon quantitative analysis
      > > not opinions.
      >
      > Another problem with estimates derived from quantitative analysis in
      > the context of agile projects is that such estimates provide a false
      > level of precision. When quantitative analysis says one feature will
      > take 13 hours and another will take 14 hours, is there really
      > sufficient data to justify a 1 hour difference? I think not, yet
      > using those numbers implies that the difference is meaningful.
      > Educated guesses using numbers 1, 2, 3, 5, 8, 13, 21, ... or 1, 2, 4,
      > 8, 16, ... provides a level of precision that is not misleading for
      > iteratively planning the project. The accumulative history of
      > velocity based on these numbers makes estimation precision an
      > unnecessary waste of time and effort.
      >
      > Steven Gordon
      >
      > >
      > > David Longstreet
      > > Software Economist
      > > www.SoftwareMetrics.Com
      > >
      > >
      >
      Steven,

      So I understand, are you suggesting that measurement is a waste of time and so is
      estimating?

      If measurement is a waste of time exactly how do you substantiate your comment,
      " agile delivers better results with less effort." How do you know what you state is true?

      In my short podcast, I am outlining a method to measure and compare
      (http://www.softwaremetrics.com/Agile/sizeagile.html). If individuals learn to measure
      their projects they should be able to draw their own conclusions about Agile.

      David Longstreet
      Software Economist
      www.SoftwareMetrics.Com
    • John A. De Goes
      Hi Dale, ... Agreed. It s comparatively easy to find a source of waste and reduce it. Logically, if you didn t introduce any other form of waste whilst making
      Message 583 of 583 , Mar 6, 2008
      • 0 Attachment
        Hi Dale,

        On Feb 28, 2008, at 6:00 PM, Dale Emery wrote:
        > Yeah. There's an idea tickling my brain, and slowly connecting lots of
        > other loose threads: A really good way to think about productivity
        > is not
        > to think about productivity per se, but instead about cost. In your
        > example, you've eliminated a cost, and allowed people to infer an
        > increase
        > in productivity.
        >

        Agreed. It's comparatively easy to find a source of waste and reduce
        it. Logically, if you didn't introduce any other form of waste whilst
        making this change, then you must have increased productivity, metric
        or no.

        > Here's a half-baked idea: To some extent, each new request from an
        > existing
        > customer expresses satisfaction with our prior performance. (That
        > is, how
        > likely are they to recommend you to themselves?)
        >

        Hmm, I'm not so sure about this. There's a certain cost associated
        with transitioning to a new provider. There's the cost of locating
        that provider, the cost of negotiations, the cost of transferring
        assets to the new provider, the cost of allocating time in the busy
        schedule of the new provider, and the ramp-up costs of the new
        provider becoming acquainted with the existing assets. All of which,
        combined, exceed by many orders of magnitude the cost of a new request
        -- even if the cost of said request is far higher than it should be,
        and its implementation leaves much to be desired.

        If a customer starts new projects with you, however, then that does
        say something about how satisfied they are with your performance.

        Regards,

        John A. De Goes
        N-BRAIN, Inc.
        http://www.n-brain.net
        [n minds are better than n-1]
      Your message has been successfully submitted and would be delivered to recipients shortly.