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

Feedback: Failures in XP

Expand Messages
  • PaulOldfield1@compuserve.com
    There are some of you asked for feedback on the situation described in Failures in XP . Here s what I got, verbatim. ++++ To summarize the responses, which I
    Message 1 of 1 , Feb 8, 2004
      There are some of you asked for feedback on the
      situation described in "Failures in XP". Here's
      what I got, verbatim.


      To summarize the responses, which I did pass on to Dave,
      there were those who adamantly proclaimed that should
      release notes be necessary it is the responsibility of the
      customer to represent the user community fully and the
      customer should create a User Story requesting a release
      note to which the Agile Team would immediately respond
      despite their antipathy for documentation. Others felt that
      Release Notes or other notification methods were part of
      their normal Agile Process and felt it did not make them less
      Agile by producing a public record of changes to be made.

      While some in the community labeled it a process issue,
      others blamed the practitioners who may either not have
      acted in a professional manner or correctly followed the
      Agile Process. Of course, we don't know the reason, and
      may never get the real story. As you recall, Dave was at
      least two-levels removed from the actual coding efforts, so,
      other than knowing the team was using an agile approach,
      and surmising from what little evidence we had at hand that
      it might be XP, we really can't access the sources to ascertain
      the specifics.

      The Rest of the Story. Dave did indeed submit his Business
      Case, and it was accepted and adopted. The proper
      documentation describing the changes was created in the
      detail necessary for him to create his fault trees to handle the
      quality production on the line. All's well for all. Except that as
      a result of the Business Case submission, new processes
      were imposed on the fledgling Agile Processes being
      practiced in the company. Dave mentioned that he recognized
      from many of the comments I forwarded to him much of the
      language and approach that seemed to be going on in the IS
      department of his company, and had a better understanding
      of what they were doing. The "company" now requires that all
      software changes emanating from a team such as this
      episode should hence forth be accompanied by sufficient
      documentation and/or release note notification such that all
      down line personnel who may come in contact with the
      changed software or in any way be affected by said changed
      software be fully and completely apprised of such changes.
      I made up the last sentence = it doesn't come from the company.
      The point is that additional work has now been imposed on
      the Agile Teams in the future, whether this additional
      documentation work is appropriate to the XP (or whatever)
      process or not. This brings up a discussion point of how
      processes get created in the first place and how the best of
      lean processes get subverted over time, but we'll leave that for
      another thread.
      My conclusion is that an apparently agile method that apparently
      was successful in this situation has now become less agile
      by ULM dictate because of :-
      Failure to enact the process correctly in the first place,
      Misapplication of the process tenets,
      Lack of professionalism and discipline among the participants,
      Trying to stretch the Process to fit a circumstance, for which the
      Process was not meant,
      Blind adherence to an Agile Process (much the way the BDUF
      are accused of doing with the Waterfall and other linear processes)
      Or, simply, the process doesn't scale.

      The unfortunate aspect for us on the list is that it not only is a
      set back for Agility in the small, but we still don't know the root
      cause so we can make adjustments in our own approaches.
      Appropriately ULM did not attempt to find and fix blame, but
      simply solve the problem and set policy to prevent the situation
      from happening again.

      In the end , I have to agree with Dave who wondered why it wouldn't
      have been simpler for the Team or some member of the Team to
      talk to him in the first place and save all this from happening. He
      drew one conclusion from the postings that I did try to disabuse
      him of: the Agile Team focuses primarily if not solely inwardly on
      those directly involved with the production of code. He found this
      strange. "I don't know why it still wouldn't be agile to talk to us even
      if we aren't directly involved with the development. We are affected"
      was one of his statements.


      I don't think I'll mark this down as a successful outcome. To me,
      a success would have the team talking to Dave (the maintainer
      of the system) face to face. If they had been doing this, nobody
      else would have asked them to write documents. As-is, if they
      still don't talk face-to-face, the team will not know what needs to
      go into the documents, they will be guessing until they receive
      feedback on the first batch. It looks like they guessed right, but
      maybe they got that information from the Business Case.

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