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

RE: [scrumdevelopment] Scrum and eXtremeProgramming

Expand Messages
  • Jeffrey P. Vasquez
    ... My apologies for the tardiness of this comment, however, I feel compelled to question the language in item 7 of the analysis, namely One of the silly
    Message 1 of 2 , Apr 17, 2000
      > Kent Beck and I have been doing some comparisons of XP and
      > Scrum to see how
      > each can benefit from the other. The first comparison is attached.
      > Ken Schwaber

      My apologies for the tardiness of this comment, however, I feel compelled to
      question the language in item 7 of the analysis, namely "One of the silly
      rules is that management isn't allowed to change the product
      [backlog]...during the [sprint]." In my opinion this is one of the most
      fundamental and core mandates of Scrum, often overshadowing others of
      seemingly greater importance.

      While the primary goal of generating the backlog is to create the definition
      of the product being delivered, of equal importance from a project
      management aspect is the project "buy-in" which accompanies its approval.
      The engineers' commitment to delivering the product as defined by the
      backlog at the conclusion of the sprint is their "buy-in" to the sprint. No
      accommodations are made with respect to schedule or definition once they've
      approved the backlog.

      The product managers' and marketing staff's commitment to the deliverable as
      it is defined by the backlog is their "buy-in" that the sprint will produce
      the result they accept and expect. No accommodations are made with respect
      to content or scope of the deliverable once they've approved the backlog.

      Moreover, the backlog then becomes the contract between the development and
      product groups. It must be viewed by both as a train that's departed the
      station and is bound for its destination. The product group may work on
      where to go from there, i.e. generating backlog for second and subsequent
      sprints, or it can pull the emergency cord and bring the whole train to a
      halt in middle of nowhere. However, by communicating the gravity of
      interrupting the sprint in exactly this metaphor of "pulling the emergency
      cord," we mandate that the product group really commit to thinking through
      any decision to pull that cord.

      I have found no better way of managing not only the productivity of the
      development group, but more importantly, their job satisfaction, which are
      my ultimate responsibilities as a manager.

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