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

Re: book, "Agile Software Development with Scrum"

Expand Messages
  • gilmanj_2000@yahoo.com
    Ken and Mike, I just wanted to thank you for your work on the book. Very well done! I read it in one sitting. In the future I would love to some real world
    Message 1 of 11 , Nov 26, 2001
    • 0 Attachment
      Ken and Mike, I just wanted to thank you for your work on the book.
      Very well done! I read it in one sitting. In the future I would
      love to some real world examples of backlogs. In addition, some
      sample templates/forms would be great. This could go in an appendix
      or on Ken's controlchaos site.

      Additional point, according to the book three things happen in the
      daily scrum 1) what I did 2) what I will do 3) what stands in my
      way. I suspect that some other things occur here. For example,
      daily estimating work remaining in the sprint. Doesn't this occur
      during the scrum? Are there other things that should occur during
      the scrum.

      Thanks again,

      John Gilman

      --- In scrumdevelopment@y..., "Ken Schwaber" <kschwaber@m...> wrote:
      > "Agile Software Development with Scrum" is now available in
      > bookstores and at Amazon.com. The book covers the theory, practice,
      > and advanced use of the Scrum development process. The second
      chapter
      > of the book can be viewed at
      http://www.controlchaos.com/section2.pdf
      >
      > Ken
    • Ken Schwaber
      John, One sitting? Thanks for the compliment! I ll look into getting some backlog examples up on controlchaos.com. The daily estimating work is done by team
      Message 2 of 11 , Nov 26, 2001
      • 0 Attachment
        John,

        One sitting? Thanks for the compliment!

        I'll look into getting some backlog examples up on controlchaos.com. The
        daily estimating work is done by team members as they work on the various
        sprint backlog tasks. It isn't done during the daily scrum meeting so as to
        keep the duration as short as possible.

        Ken Schwaber

        -----Original Message-----
        From: gilmanj_2000@... [mailto:gilmanj_2000@...]
        Sent: Monday, November 26, 2001 2:14 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Re: book, "Agile Software Development with
        Scrum"


        Ken and Mike, I just wanted to thank you for your work on the book.
        Very well done! I read it in one sitting. In the future I would
        love to some real world examples of backlogs. In addition, some
        sample templates/forms would be great. This could go in an appendix
        or on Ken's controlchaos site.

        Additional point, according to the book three things happen in the
        daily scrum 1) what I did 2) what I will do 3) what stands in my
        way. I suspect that some other things occur here. For example,
        daily estimating work remaining in the sprint. Doesn't this occur
        during the scrum? Are there other things that should occur during
        the scrum.

        Thanks again,

        John Gilman

        --- In scrumdevelopment@y..., "Ken Schwaber" <kschwaber@m...> wrote:
        > "Agile Software Development with Scrum" is now available in
        > bookstores and at Amazon.com. The book covers the theory, practice,
        > and advanced use of the Scrum development process. The second
        chapter
        > of the book can be viewed at
        http://www.controlchaos.com/section2.pdf
        >
        > Ken


        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...

        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • jonas.b@home.se
        Hi, Emerging requirements and self-organization I can understand and agree to. But I have harder understanding emerging architecture. Self- organizing teams
        Message 3 of 11 , Nov 28, 2001
        • 0 Attachment
          Hi,
          Emerging requirements and self-organization I can understand and
          agree to. But I have harder understanding emerging architecture. Self-
          organizing teams are just human nature, whereas architecture is a
          complex composition which is hard to change. I don't imply that
          emerging architecture is nonsense but I can't understand how it's
          possible.

          Thanks for the articles on InformIT Ken, they were great!

          Regards,
          Jonas

          --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
          wrote:
          > <Won't it be hard to create a stable architecture if you don't have
          > the end goal in sight? Or it is sufficient to use the information in
          > the backlog as a foundation?>
          >
          > Emergence of requirements and architecture, and self-organization
          are
          > research topics. Experientially, we know they work and are
          applicable to
          > software development, but the theoretical basis and its connection
          to
          > software development hasn't been made. See two articles that
          Prentice Hall
          > put up on www.informit.com under agile development that I wrote.
          >
          > <But doesn't it cause problems if highly skilled and
          > experienced engineers recieve the same salary as newly examined
          > nitwits? Are the Scrum team persistent? Do they remain the same in
          several
          > projects if they are well-fuinctioning?>
          >
          > In the overall performance review, evaluate the team and the
          individual's
          > contributions. Unless disfunction occurs, it's in the team and the
          > organization's benefit to keep teams working together, owning
          products and
          > systems.
          >
          > <Quite incompatible with the collective ownership rule of XP :-)>
          >
          > The product wasn't using XP, so we felt free to use this rule.
        • Ken Schwaber
          I don t understand the theoretical underpinnings of why emerging architecture and design work either. A number of us that develop and practice agile were
          Message 4 of 11 , Nov 28, 2001
          • 0 Attachment
            I don't understand the theoretical underpinnings of why emerging
            architecture and design work either. A number of us that develop and
            practice agile were talking about this the other day, and we agreed that:
            1. We don't know why it works.
            2. Preparing a detailed architecture and design at the beginning of a
            project is wasteful. It presupposes the requirements, often leads to
            developing technical capabilities that aren't needed (and require debugging
            and maintenance), doesn't fit with the desire to simplify, and imposes costs
            of the customer that they haven't agree to.
            3. In every case that we've relied on a stable architecture and design
            emerging, they did. Part of the reason is refactoring, but I suspect that
            the other reason has to do with team experience and the chaos theory
            "strange attractor."

            So, this is another of my research areas.

            Ken

            -----Original Message-----
            From: jonas.b@... [mailto:jonas.b@...]
            Sent: Wednesday, November 28, 2001 6:03 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Re: book, "Agile Software Development with
            Scrum"


            Hi,
            Emerging requirements and self-organization I can understand and
            agree to. But I have harder understanding emerging architecture. Self-
            organizing teams are just human nature, whereas architecture is a
            complex composition which is hard to change. I don't imply that
            emerging architecture is nonsense but I can't understand how it's
            possible.

            Thanks for the articles on InformIT Ken, they were great!

            Regards,
            Jonas

            --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
            wrote:
            > <Won't it be hard to create a stable architecture if you don't have
            > the end goal in sight? Or it is sufficient to use the information in
            > the backlog as a foundation?>
            >
            > Emergence of requirements and architecture, and self-organization
            are
            > research topics. Experientially, we know they work and are
            applicable to
            > software development, but the theoretical basis and its connection
            to
            > software development hasn't been made. See two articles that
            Prentice Hall
            > put up on www.informit.com under agile development that I wrote.
            >
            > <But doesn't it cause problems if highly skilled and
            > experienced engineers recieve the same salary as newly examined
            > nitwits? Are the Scrum team persistent? Do they remain the same in
            several
            > projects if they are well-fuinctioning?>
            >
            > In the overall performance review, evaluate the team and the
            individual's
            > contributions. Unless disfunction occurs, it's in the team and the
            > organization's benefit to keep teams working together, owning
            products and
            > systems.
            >
            > <Quite incompatible with the collective ownership rule of XP :-)>
            >
            > The product wasn't using XP, so we felt free to use this rule.


            To Post a message, send it to: scrumdevelopment@...
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...

            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          • Ken Schwaber
            Many methodologies initiate a project with a phase that defines the business architecture and the technical architecture of the system, in full. Based on the
            Message 5 of 11 , Nov 29, 2001
            • 0 Attachment
              Many methodologies initiate a project with a phase that defines the business
              architecture and the technical architecture of the system, in full. Based on
              the user fully stated requirements, the team defines a model of the overall
              business processes and how they interact, as well as all of the technology
              that underlies the business processes and allows them to interact and
              operate with the reliability, scalability, and performance required. The
              problem with this approach is that the requirements have to be fully known
              to do so, and the implication is that the system will be delivered as
              modeled (either iteratively or with a big bang).

              Emergent architecture (business and technical) says that the team thinks
              through, designs, and builds only that architecture needed to support the
              business value (sprint goal) needed to deliver the functionality for that
              iteration (sprint). Anything beyond that architecture is speculative (since
              requirements emerge), unnecessary for supporting that sprint's
              functionality, and extra cost - both in development, debugging, and
              maintenance.

              Although the team may "whiteboard" an overall model of the the system prior
              to starting, so they have a context, the model only provides a context. The
              details emerge with each sprint.

              Ken

              -----Original Message-----
              From: Peter McGowan [mailto:peter@...]
              Sent: Thursday, November 29, 2001 10:28 AM
              To: Ken Schwaber
              Subject: Re: [scrumdevelopment] Re: book, "Agile Software Development
              with Scrum"


              Hi Ken,

              What's "Emerging Architecture"?

              Peter

              ----- Original Message -----
              From: "Ken Schwaber" <ken.schwaber@...>
              To: <scrumdevelopment@yahoogroups.com>
              Sent: Wednesday, November 28, 2001 7:34 PM
              Subject: RE: [scrumdevelopment] Re: book, "Agile Software Development with
              Scrum"


              > I don't understand the theoretical underpinnings of why emerging
              > architecture and design work either. A number of us that develop and
              > practice agile were talking about this the other day, and we agreed that:
              > 1. We don't know why it works.
              > 2. Preparing a detailed architecture and design at the beginning of a
              > project is wasteful. It presupposes the requirements, often leads to
              > developing technical capabilities that aren't needed (and require
              debugging
              > and maintenance), doesn't fit with the desire to simplify, and imposes
              costs
              > of the customer that they haven't agree to.
              > 3. In every case that we've relied on a stable architecture and design
              > emerging, they did. Part of the reason is refactoring, but I suspect that
              > the other reason has to do with team experience and the chaos theory
              > "strange attractor."
              >
              > So, this is another of my research areas.
              >
              > Ken
              >
              > -----Original Message-----
              > From: jonas.b@... [mailto:jonas.b@...]
              > Sent: Wednesday, November 28, 2001 6:03 PM
              > To: scrumdevelopment@yahoogroups.com
              > Subject: [scrumdevelopment] Re: book, "Agile Software Development with
              > Scrum"
              >
              >
              > Hi,
              > Emerging requirements and self-organization I can understand and
              > agree to. But I have harder understanding emerging architecture. Self-
              > organizing teams are just human nature, whereas architecture is a
              > complex composition which is hard to change. I don't imply that
              > emerging architecture is nonsense but I can't understand how it's
              > possible.
              >
              > Thanks for the articles on InformIT Ken, they were great!
              >
              > Regards,
              > Jonas
              >
              > --- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
              > wrote:
              > > <Won't it be hard to create a stable architecture if you don't have
              > > the end goal in sight? Or it is sufficient to use the information in
              > > the backlog as a foundation?>
              > >
              > > Emergence of requirements and architecture, and self-organization
              > are
              > > research topics. Experientially, we know they work and are
              > applicable to
              > > software development, but the theoretical basis and its connection
              > to
              > > software development hasn't been made. See two articles that
              > Prentice Hall
              > > put up on www.informit.com under agile development that I wrote.
              > >
              > > <But doesn't it cause problems if highly skilled and
              > > experienced engineers recieve the same salary as newly examined
              > > nitwits? Are the Scrum team persistent? Do they remain the same in
              > several
              > > projects if they are well-fuinctioning?>
              > >
              > > In the overall performance review, evaluate the team and the
              > individual's
              > > contributions. Unless disfunction occurs, it's in the team and the
              > > organization's benefit to keep teams working together, owning
              > products and
              > > systems.
              > >
              > > <Quite incompatible with the collective ownership rule of XP :-)>
              > >
              > > The product wasn't using XP, so we felt free to use this rule.
              >
              >
              > To Post a message, send it to: scrumdevelopment@...
              > To Unsubscribe, send a blank message to:
              > scrumdevelopment-unsubscribe@...
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >
              >
              >
              > To Post a message, send it to: scrumdevelopment@...
              > To Unsubscribe, send a blank message to:
              scrumdevelopment-unsubscribe@...
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.