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

Developers Held Accountable for Estimates

Expand Messages
  • Paul Hodgetts
    I ve read several times now the phrase developers are held accountable for their estimates in a way that seems to be saying that if I say it will take 12
    Message 1 of 50 , Mar 27, 2005
    • 0 Attachment
      I've read several times now the phrase "developers are held
      accountable for their estimates" in a way that seems to be
      saying that if I say it will take 12 hours, it better dang well
      take 12 hours. Or, at another level, if we say we will get
      these 5 stories done, we'd better deliver those 5 stories.
      There's something about that concept that worries me. I'm
      guessing I misunderstand something.

      What I understand about accountability for estimates is:

      As a developer, I should be accountable for doing the due
      diligence to come up with my best shot at an estimate. I should
      be accountable that I do enough due diligence, but stop when the
      due diligence hits that knee of the curve where the accuracy of
      the estimate no longer increases sufficiently for the additional
      cost of more due diligence. I should be accountable that I help
      define and follow the team's standards for this due diligence.

      When developing, I should be accountable for working diligently
      to complete my tasks and stories as quickly as possible. I
      should be accountable for doing work that conforms to the team's
      standards of goodness, and for helping define those standards.

      I should be accountable for paying attention to what really
      happened in developing, and for learning from the experience so
      that my future due diligence, estimating and developing will
      improve.

      Now here's where I have the problem. Let's say I work in a way
      that is accountable as above, and I estimate a task at 12 hours.
      I work on the task, accountable as above, and it takes 18 hours.
      I learn that the reason it took longer was that the database
      library is a bear to test with, and next time I will include
      more time to cover that for database tasks.

      I do not feel that I have violated my accountability here. But
      under some previous discussion, the implication is that I'm not
      delivering what was promised to the Customer, and I'm creating
      a situation where the Customer's trust is violated.

      I feel that being held accountable for getting the task done in
      12 hours is the wrong accountability. If I were held to that
      accountability, it would seem to cause me to either violate my
      accountability for good estimating by padding my estimate to
      always cover worst case, or to violate my accountability for
      good work by rushing through the task when it is taking longer
      than estimated. I value those two types of accountability more
      than that of meeting the estimate.

      I suspect I am misinterpreting what other folks mean when they
      are using the phrase "developers are held accountable for their
      estimates," but it sounds to me like the wrong accountability.
      If not, then I'd like to understand the balance of values that
      makes accountability for the estimate take precedence. What do
      others understand and think about this?

      Thanks,
      Paul
      -----
      Paul Hodgetts -- CEO, Coach, Trainer, Consultant
      Agile Logic -- www.agilelogic.com
      Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
      Complete solutions for adopting agile processes, Scrum and XP.

      Upcoming Events:

      Certified ScrumMaster Training, Las Vegas, NV - April 25-26, 2005
      http://www.agilelogic.com/CSM.html
    • Ron Jeffries
      Hi Dale, I would like to underline and agree with your remarks below. I like to offer a gush where appropriate, but especially in view of all the excitement
      Message 50 of 50 , Apr 1, 2005
      • 0 Attachment
        Hi Dale,

        I would like to underline and agree with your remarks below. I like
        to offer a "gush" where appropriate, but especially in view of all
        the excitement and discussion around this topic, I want to offer
        folks another chance to read your words.

        Thanks,

        Ron Jeffries
        www.XProgramming.com
        Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison

        On Friday, April 1, 2005, at 3:21:15 AM, Dale Emery wrote:

        > Hi Stuart,

        >> A company I worked for used a certain management training
        >> approach that dealt with managing commitments. It was part of
        >> "Sportsmind" but please don't interpret what follows as an
        >> accurate description of Sportsmind.

        > This reminds me of Watts Humphrey's idea of "Commitment
        > Discipline," from Managing the Software Process:

        > "The elements of an effective commitment are:

        > 1. The person making the commitment does so willingly.
        > 2. The commitment is not made lightly; that is, the work
        > involved, the resources, and the schedule are carefully considered.
        > 3. There is agreement between the parties on what is to be done,
        > by whom, and when.
        > 4. The commitment is openly and publicly stated.
        > 5. The person responsible tries to meet the commitment, even if
        > help is needed.
        > 6. Prior to the committed date, if it is clear that it cannot be
        > met, advance notice is given and a new commitment is negotiated."

        >> Implicit in that commitment however is the acknowledgement
        >> that the world changes, and that includes timescales,
        >> priorities, other work, unforeseen issues, and indeed, things
        >> like databases being a real bear to work with.

        > I'd prefer to have that acknowledgement explicit. Maybe not in
        > each commitment, but perhaps in the relationship, so that it's
        > clear that commitments made within the relationship fall under
        > that acknowledgement.
      Your message has been successfully submitted and would be delivered to recipients shortly.