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

Re: [scrumdevelopment] Re: Scheduling Defect Fixes

Expand Messages
  • Ron Jeffries
    Hello, Roy. On Tuesday, February 1, 2011, at 11:07:38 AM, you ... It turns out not to be the case that it applies to other user requested requirements .
    Message 1 of 347 , Feb 1, 2011
      Hello, Roy. On Tuesday, February 1, 2011, at 11:07:38 AM, you
      wrote:

      > Ron, as you well know, iterative, agile, XP etc. methods all
      > include the notion that we Welcome Change, and handle it, by
      > Adaptive Planning, Adaptive Estimating etc. based on what we know
      > now, with the assumption, usually correct, that the future will
      > bring new and different requirements.
      >
      > Just-in-Time requirements detailing (not requirements
      > determination or requirements discovery) is a good idea because we
      > detail the requirements just in time to be developed, and we are
      > not using old requirements statements that may actually have
      > changed, even if we try not to recognise that, and we call it
      > 'scope creep' and everyone says Ohh, that's bad!
      >
      > So your comment that "we do not have any way of knowing what
      > Defect Stories, and what Technical Stories, will pop up.", as a
      > justification for doing, or not doing, something, is fallacious.
      > It is correct to say that, yes, but it also applies to other 'user
      > requested' requirements.

      It turns out not to be the case that it applies to other 'user
      requested requirements'. While new user requirements can pop up at
      any time, surprise requirements tend to cluster toward the beginning
      of the project, because that is the time of greatest learning.

      Similarly, technical issues tend to cluster toward the beginning and
      middle of the project, again because it is the time of greatest
      learning. There are two primary exceptions. Performance issues often
      crop up late. Redesign issues driven by newly discovered defects
      often crop up late.

      Defects, on the other hand, tend to crop up toward the end of the
      project, I think mostly because of generally inadequate testing.
      Thus their impact as an unknown element is disproportionately bad,
      the closer we get to our desired ship date.

      In addition, every new user requested requirement is carried to
      term, if not conceived, in the mind of and purview of the Product
      Owner. Her job is to listen to what users say and decide what to do.

      On the contrary, defects are not in her mind and purview, and are
      essentially out of her control. As you like to say, "they happen".
      As I like to say, programmers put them in without being asked to do
      so.

      The cases are quite different. And therein lies one of the forces
      that pushes against defect stories.
      >
      > This is why the future estimating completion date can vary (ok,
      > not too widly, I hope), or some requirements already identified
      > may end up in the 'probably not by the deadline' category.

      > I don't want to defend my suggestion about Technical Stories too
      > stoutly, but isn't collaboration, team work, PO on the team stuff
      > part of Scrum, XP and etc.? I would think it is a somewhat
      > dysfunctional situation if the developers explain to the PO that
      > some technical work needs to be done, and the PO refuses to allow
      > it. This seems a little bloody-minded to me, and hardly
      > collaborative and effective team work.

      Yes, it can reflect dysfunction, and unfortunately it happens very
      frequently. However, even with the best teams and teamwork,
      prioritizing technical vs user usually comes down to trust, because
      there really is no consistent way to monetize features and technical
      changes on the same scale. So the problem of technical stories is
      serious /whether or not/ we have good teamwork.

      Thus the recommendation to avoid technical stories.
      >
      > I hark back some months to another controversy we had, when I
      > suggested that the developers would usually have a particular DBMS
      > available that they would use in the project. It was pointed out
      > to me that this was badly not agile. But I stick to my point that
      > there are a lot of 'technical' things that should be in place even
      > before the project starts. So it could be said that the appearance
      > of a technical matter that needs doing in the middle of the
      > project is a result of the team not being fully prepared to start
      > the project. Nonetheless, it might happen (just like defects might
      > be created) and needs to be dealt with.

      Yes. I do not care to revisit the DBMS issue. But I agree that
      technical matters might pop up, and some of them are surely due to
      not being fully prepared.

      Nonetheless, most of these changes can be undertaken incrementally
      and as part of doing user stories. When that is possible, it is my
      opinion that it should be done. When it is not possible, we would
      schedule those activities /as if/ they were user stories, and, in my
      opinion, we would /not/ track them as if they were feature progress
      on the burn charts.

      It is legal to track them. It is recommended by some other advisors.
      What is clear, however, is that if you are going to track them as
      progress, you must also advance the goal line every time you accept
      one as a backlog item. I just prefer not to advance the goal line,
      and not to track them, because it keeps us focused on the
      high-leverage material, namely true features.

      > So what is this 'overhead' that you suggest we track, and how is
      > it factored in to the teams activities? ... which will presumably
      > affect the future delivery dates or achieveable functionality.

      Bug fixes are overhead, by my definition. I make this definition to
      help keep that laser focus on not creating bugs. If you can't get
      credit for fixing them, I hope you will be less inclined to put them
      in.

      Activities not directed to the project at all are overhead, such as
      all-company meetings, assignment to other projects and any other
      such activity. Other overhead items show up in every project. If
      people start noticing time wasted, track it.

      I would track the time simply. If we were scheduling defects and
      purely technical work in the Sprint, I'd just keep track of the time
      on those cards separately. If there was significant time away from
      the project, I'd get the team to track it. I would display this
      information on a regular basis on a simple swim-lane chart.

      > I clearly recall a situation in one company I worked for, when a
      > developer got lambasted by a manager for having failed to achieve
      > the work output he had been assigned (yeah, let's ignore the
      > awfulness of that for a moment). I recall him coming back to his
      > desk, thoroughly p****d off, muttering to himself 'Doesn't that
      > a***h**e realise I spent all of yesterday trying to fix a CICS
      > problem that we had'. If there had been the appropriate spirit of
      > cooperation and collaboration in that situation, and if the
      > developer had been able to put forward that CICS-fixing activity
      > as a backlog item, then maybe everyone would have been aware of
      > the work necessary to fix it, which clearly delayed the completion
      > of the other work.

      Instead, it appears that either the manager has amnesia, or the
      developer worked on something he was not asked by the manager to
      work on. I can see how this would be a serious problem. I do not see
      how the *ssh*l* was supposed to know, if he didn't ask for the CICS
      work and the developer didn't tell him. Most of us who can read
      minds choose not to reveal that power to civilians.

      I would agree that some rather terrible communications problem arose
      between the developer and the manager. Apparently the developer
      worked on something the manager did not assign. In Scrum, that would
      mean someone was working on something the PO did not assign. That
      would be, in my opinion, very bad. No one can manage a situation
      where people are not working on the things they are supposed to be
      working on ... nor where people are working on the right things and
      no one knows it.

      > Maybe this is a good reason to have 'Technical Stories'.

      It's a good reason to have managers and Product Owners actually
      directing the work. It's a good reason to have all the work on the
      backlog. It's a good reason never to undertake work that isn't on
      the backlog and scheduled by the Product Owner. Scrum addresses the
      manager / developer communications concern directly, out of the box.

      It might be a good reason to make this thing a "technical story", or
      it might not.

      Ron Jeffries
      www.XProgramming.com
      It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
    • Vikrama Dhiman
      ... Although, this is not Twitter. I really want to do a+1. Echoes my thoughts completely. Won t have been able to put it better myself. Thanks Vikrama Dhiman
      Message 347 of 347 , Feb 2, 2011
        >>It (and the length of this thread) is a great illustration of why I recommend that teams not get too wrapped up in estimation. They start looking for numerical precision, and that starts consuming the energy that could be put toward accomplish goals.

        Although, this is not Twitter. I really want to do a +1.

        Echoes my thoughts completely. Won't have been able to put it better myself.
         
        Thanks

        Vikrama Dhiman
        ================================================================
        Personal Blog : http://www.vikramadhiman.com/
        My Blog about all things Agile : http://agilediary.wordpress.com/



        From: George Dinwiddie <lists@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Wed, February 2, 2011 11:09:28 PM
        Subject: Re: [scrumdevelopment] Re: Scheduling Defect Fixes

         

        On 2/2/11 5:48 AM, Ron Jeffries wrote:
        > Hello, kbs_kulbhushan. On Wednesday, February 2, 2011, at
        > 12:23:59 AM, you wrote:
        >
        >> Does this make sense?
        >
        > Not really, but it was a delightful demonstration of how many
        > numbers can dance on the head of a pin.

        It (and the length of this thread) is a great illustration of why I
        recommend that teams not get too wrapped up in estimation. They start
        looking for numerical precision, and that starts consuming the energy
        that could be put toward accomplish goals.

        I suggest that the primary reason for estimating stories & tracking
        velocity is to help the team decide how much work they can do in the
        next iteration. I've found that developing clear acceptance examples
        (a.k.a. tests) helps them do that much better than more time spent
        honing estimates.

        I suggest that the secondary reason for estimating stories & tracking
        velocity is to help the PO predict how much functionality can be done by
        a certain date, or how long it will take to build a certain amount of
        functionality. When doing so, one has to remember that these are just
        estimates, no matter how much work you put into them. You need to allow
        some leeway for the things you don't know and can't predict. You need
        to track actual progress, and give that more weight than any predicted
        progress. And you need to measure actual progress in ways that don't
        mislead you. The more calculations you put in, the more likely you're
        going to fool yourself.

        - George

        P.S. Remember that the abbreviation for "estimation" is "guess."

        --
        ----------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------


      Your message has been successfully submitted and would be delivered to recipients shortly.