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

Scrum and eXtremeProgramming

Expand Messages
  • virman@aol.com
    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
    Message 1 of 2 , Apr 5 12:23 PM
    View Source
    • 0 Attachment
      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
    • 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 2 of 2 , Apr 17 1:26 PM
      View Source
      • 0 Attachment
        > 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.