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

RE: [scrumdevelopment] Re: book, "Agile Software Development with Scrum"

Expand Messages
  • Ken Schwaber
    Jonas,
    Message 1 of 11 , Nov 25, 2001
      Jonas,


      <Are there any plans of more Scrum books? Aren't books very important
      in order to facilitating making Scrum more popular? (compare with XP
      where they have many books from different viewpoints)>

      I've cc'ed this to other Scrum practioners who may plan to be or may be
      writing books. As I said, my next book if regarding value driven
      project/product management using Scrum.


      <Does Scrum address the issue of burn outs and negative stress? (E.g.
      in RAD different persons are responsible for different phases in
      order to prevent too much negative stress)
      Is it perhaps "enough" with empowering the team to make the
      commitment (so that they take on as much work as they can handle) and
      to control the chaos? Or is it perhaps ut to the ScrumMaster to
      prevent burn outs from happening?>

      I've never seen a Scrum team burnout. Sprints are only thirty days, and the
      team is doing what it commits to, with complete flexibility to adjust the
      functionality to deliver business value (Sprint Goal). However, sometimes
      the team gets into team heroics, wanting to blow someone's socks off, or
      really makes an extraordinary effort to prepare a product for a show, or a
      specific customer. In these cases, I've recognized their efforts by giving
      them several days off (a five day weekend?) and a gift certificate that they
      can use to take their families to dinner (after all, the family was without
      the team member). I feel justified doing so because the team has contributed
      extraordinarily.

      <Is most of requirements enginnering issues unnecessary? The backlogs
      seems to be quite informal and the aim seems to be more focused in
      defining as much as necessary for the stakeholders to get roughly the
      same picture of the system.
      Is the backlogs mentioned in contracts? If so, it would require the
      backlogs to be quite formal.>

      Requirements engineering started because of the contractual style of
      initiating and managing projects. When a team was stuck with a fixed cost,
      time, functionality and quality - but emerging requirements and unstable
      technology - they usually reduced functionality (sometimes reduced quality,
      also). So requirements engineering was built in ... you promised us this,
      show us how you delivered it. Talk about making a bad situation worse!! In
      Scrum, we drive for business value. Give us a vision of what you want,
      describe the business objective, and the development team(s) will
      collaboratively work together to deliver the value every Sprint. Since
      requirements emerge, particularly as the customers see the working
      functionality and change their mind about how to use it, Scrum facilitates
      taking advantage of what's in hand. In contractually managed projects,
      change orders are used to control change, but what they really do is stifle
      change.

      <How do you write contract when using Scrum? Because it is up to the
      team to decide how much to do within a sprint the Sprint Backlog are
      not so feasible for contract, is it? Or do you only make the
      agreement with the customer that he pays for man-hours and have to
      rely on the company to give him as much value for his money?>

      Exactly. The contract focuses on vision and business value, what the system
      has to help make occur in a fixed period of time. The team and customer then
      work on the "art of the possible", fitting the most important functionality
      in within the required time to deliver the value. DSDM has a saying that 20%
      of the functionality delivers 80% of the business value. I agree.

      <Is it possible for the customer to abort the project between any Sprints?>
      At the end of each Sprint, the customer can change cost (more team, less
      teams, no teams), functionality (different functionality than planned for
      the next Sprint), quality (make it buggier?). The customer gets to drive the
      project Sprint by Sprint.

      <Here in Sweden it is some debate over fixed-price vs. current
      account, where one side states that it is the developer who should
      take the risk (thus fixed-price), whereas the other side states that
      it is impossible to predetermine the price (thus current account).>

      Why is each side trying to stick the other side with risk? Note the word
      "side". The moment you have sides, everyone loses. Trust evaporates, and
      mediocrity results. Every technology project is risky and Scrum requires
      that both sides collaborate to manage the risk and the uncertainty, focusing
      on results in a unpredictable environment. By producing working product
      every thirty days, the "risk" is never more than 30 days of cost, and
      judgements are based on inspection of working product rather than belief in
      assertions.>


      <When talking about shared/team responsibility the story of the four
      men often arise:
      "This is a story about four people named Everybody, Somebody, Anybody
      and Nobody.
      There was an important job to be done and Everybody was sure that
      Somebody would do it.
      Anybody could have done it, but Nobody did it.
      Somebody got angry about that, because it was Everybody's job.
      Everybody thought Anybody could to it, but Nobody realised that
      Everybody wouldn't do it.
      It ended up that Everybody blamed Somebody when Nobody did what
      Anybody could have done."
      Is it unapplicable on Scrum? Is it plain nonsense?>

      How horrible!! and, yes, it happens all of the time, but not with Scrum.
      Scrum has the team commit to what they can do over the next Sprint and gives
      them absolute authority and isolation to do their best to deliver to their
      commitment. At the end of the team, the team has to demonstrate working
      product functionality that demonstrates value. Team and working
      functionality. These are the only things looked at when the Sprint ends.
      Based on what the team has done, the customer may at that point decide not
      to fund any further Sprints, or to trade out the entire team and get a new
      team. A Sprint really puts the team on the spot --- as a group they have
      committed; as a group, they will be judged. It gives us what we've always
      asked for, the authority and time to do our best. Now we have this freedom
      for a whole 30 days. Let's see what we can build, let's show off a little,
      let's have some fun and build something really useful, great and neat. We've
      all seen sports teams that are so dysfunctional from interal arguments and
      politics that they can't perform (Boston RedSox come to mind). Every game,
      just like every Sprint, this dysfunction is real obvious and can be
      addressed.

      <Isn't it easy that the product transforms into different products too
      much when you're not fixating the end goal? Like starting out to be a
      pc program and then transforms into a internet application and so
      forth.>

      The value to the business, the Sprint Goal for each Sprint, the customer
      decision about what to build in the next Sprint, keeps the team focused.
      Technology decisions become subservient to business value decisions. The
      business person is left with the tradeoff of increasing marketshare
      immediately with old technology that will require more maintenance, or
      increasing marketshare more slowly while implementing more versatile new
      technology. The business person thinks, "if I'm delivering this
      functionality sooner than the competition on connected browsers, will I get
      more customers, OR, should I go for existing functionality on wireless
      devices and create a marketing campaign that shows us as advanced and our
      competition as behind the times?" Business decisions drive technology
      decision, for the life of the product and for the initiation of each Sprint.

      <In Scrum there are no such thing as time reporting, right? Can the
      members choose to work 30 hours week?
      Isn't it common that the customer would like to see figure of how
      much time is spent on different activities?>

      Yeetch!!! What do you care about my hours, my dress, my anything if the team
      is collaborating with the user and delivering business value. The deal at
      the start of the Sprint is, "we'll agree on what business value to deliver
      over the Sprint, and then we the team have complete autonomy to figure out
      how we'll do so." If the team figures that they work best together during
      the night hours and management insists that they work during the day,
      management has placed an impediment on the team that prevents it from
      delivering the most business value. As such, management is violating their
      primary responsibility ... the productivity of the organization and the
      overall sustenance and survival of the orgnization. This type of change in
      thinking takes time, but the teams love it because it treats them as
      responsible adults and holds them to it.

      <Are process improvement models, e.g. CMM,SPICE,ISO9001 applicable to
      Scrum?>

      Maybe, but I don't really care. Process improvement was put in place to try
      to make the defined processes work better (see chapter 6 in the book). The
      underlying assumption is that everyone would have to follow the improved
      process and therefore greater productivity and predictability would occur.
      Scrum only puts a framework in place. When we wrap Scrum around XP, we're
      wrapping Scrum around a great set of engineering processes, but XP processes
      also aren't "defined", pert chart based processes, so much as a framework.

      <Which career paths is possible with Scrum? Only developer
      ->ScrumMaster? If so, isn't this a drawback?>

      Scrum tightly links the business and the teams. People evolve and
      self-organize into the roles that they fulfill best. Some engineers become
      sales-support or customer implementation because they love working in
      customer environments. This evolves based on personal desires, skills, and
      tendencies tied to business needs. This, of course, drives HR nuts, because
      HR is mostly designed around predictable, defined, hierarchical career
      paths. Change the review process so that teams (not just individuals) are
      rewarded. Open everything up and let people thrive based on their
      contributions, not politics and all of the "Dilbert" stuff. There are no
      "system architects" and "lead designers" in Scrum teams. There are only
      people who are respected and listened to based on their experiences, skills,
      and effort.

      <Is it customary to educate different stakeholders in Scrum before
      starting the project? I know of one company that is using DSDM that
      offers a one-day education about DSDM. How else can you prevent the
      customer from hiring a competitor who promise the functionality at a
      fixed price?>

      DSDM and Scrum deliver fixed price contracts. However, both require
      collaboration that focuses on delivering the most business value for that
      price in that timeframe. In chapter 5 of the book, Mike and I talk about
      someone building security into an existing system. Scrum is introduced as no
      big deal, just a way of dealing with the complexity and allowing management
      to make adjustments based on what's found. My next set of research is how to
      introduce collaborative, adaptive, emergent, self-organizing processes like
      Scrum into an organization as a way of doing business, top down. Right now,
      with Scrum being implemented bottom up, we low ball the organizational
      effects. The business people pick up on the benefits and then start wanting
      "scrum, or whatever that approach is" used more widely.


      <When scaling Scrum up to a large project it seems that the cross-
      functional teams are lost (the book talks about test, CM, support
      teams and so forth). Is this the case? Aren't cross-functional an
      essential part of Scrum?>

      Teams can be used to address any set of work, such as product support or new
      product development. Include or exclude responsibilities from teams as
      needed so that the team can move as quickly as possible without creating
      long term problems. Jeff Sutherland and I once gave development teams at an
      organization development responsibility only. They put out code that was
      difficult to maintain and the support teams got behind. So we implemented a
      "once you code it, you own it forever" rule which slowed the development
      teams down, but had them build better software.

      Best of luck with your thesis. You are in the middle of something really
      neat.
      Ken Schwaber
    • jonas.b@home.se
      Thanks for you answer! ... may ... Nice! ... Goal). ... off ... Hopefully do all ScrumMasters act that way. ... get ... fixed ... collaboratively work
      Message 2 of 11 , Nov 26, 2001
        Thanks for you answer!

        > Jonas,
        >
        > <Are there any plans of more Scrum books? Aren't books very
        > important in order to facilitating making Scrum more popular?
        > (compare with XP where they have many books from different
        > viewpoints)>
        >
        > I've cc'ed this to other Scrum practioners who may plan to be or
        may
        > be writing books. As I said, my next book if regarding value driven
        > project/product management using Scrum.

        Nice!

        > <Does Scrum address the issue of burn outs and negative stress?
        > (E.g. in RAD different persons are responsible for different phases
        > in order to prevent too much negative stress)
        > Is it perhaps "enough" with empowering the team to make the
        > commitment (so that they take on as much work as they can handle)
        > and to control the chaos? Or is it perhaps ut to the ScrumMaster to
        > prevent burn outs from happening?>
        >
        > I've never seen a Scrum team burnout. Sprints are only thirty days,
        > and the team is doing what it commits to, with complete flexibility
        > to adjust the functionality to deliver business value (Sprint
        Goal).
        > However, sometimes the team gets into team heroics, wanting to blow
        > someone's socks off, or really makes an extraordinary effort to
        > prepare a product for a show, or a specific customer. In these
        > cases, I've recognized their efforts by giving them several days
        off
        > (a five day weekend?) and a gift certificate that they can use to
        > take their families to dinner (after all, the family was without
        > the team member). I feel justified doing so because the team has
        > contributed extraordinarily.

        Hopefully do all ScrumMasters act that way.

        > <Is most of requirements enginnering issues unnecessary? The
        > backlogs seems to be quite informal and the aim seems to be more
        > focused in defining as much as necessary for the stakeholders to
        get
        > roughly the same picture of the system.
        > Is the backlogs mentioned in contracts? If so, it would require the
        > backlogs to be quite formal.>
        >
        > Requirements engineering started because of the contractual style of
        > initiating and managing projects. When a team was stuck with a
        fixed
        > cost, time, functionality and quality - but emerging requirements
        > and unstable technology - they usually reduced functionality
        > (sometimes reduced quality,also). So requirements engineering was
        > built in ... you promised us this, show us how you delivered it.
        > Talk about making a bad situation worse!! In Scrum, we drive for
        > business value. Give us a vision of what you want, describe the
        > business objective, and the development team(s) will
        collaboratively > work together to deliver the value every Sprint.
        Since requirements
        > emerge, particularly as the customers see the working functionality
        > and change their mind about how to use it, Scrum facilitates
        > taking advantage of what's in hand. In contractually managed
        > projects, change orders are used to control change, but what they
        > really do is stifle change.

        Sadly I must agree with you! (Sadly since I've just taken I course
        called 'Reuirements Engineering' :-)

        > <How do you write contract when using Scrum? Because it is up to the
        > team to decide how much to do within a sprint the Sprint Backlog are
        > not so feasible for contract, is it? Or do you only make the
        > agreement with the customer that he pays for man-hours and have to
        > rely on the company to give him as much value for his money?>
        >
        > Exactly. The contract focuses on vision and business value, what
        the
        > system has to help make occur in a fixed period of time. The team
        > and customer then work on the "art of the possible", fitting the
        > most important functionality in within the required time to deliver
        > the value. DSDM has a saying that 20% of the functionality delivers
        > 80% of the business value. I agree.
        >
        > <Is it possible for the customer to abort the project between any
        > Sprints?>
        > At the end of each Sprint, the customer can change cost (more team,
        > less teams, no teams), functionality (different functionality than
        > planned for the next Sprint), quality (make it buggier?). The
        > customer gets to drive the project Sprint by Sprint.

        Power to the people and Power to the customer! I like that!

        > <Here in Sweden it is some debate over fixed-price vs. current
        > account, where one side states that it is the developer who should
        > take the risk (thus fixed-price), whereas the other side states that
        > it is impossible to predetermine the price (thus current account).>
        >
        > Why is each side trying to stick the other side with risk? Note the
        > word "side". The moment you have sides, everyone loses. Trust
        > evaporates, and mediocrity results. Every technology project is
        > risky and Scrum requires that both sides collaborate to manage the
        > risk and the uncertainty, focusing on results in a unpredictable
        > environment. By producing working product every thirty days, the
        > "risk" is never more than 30 days of cost, and judgements are based
        > on inspection of working product rather than belief in assertions.


        I second that!

        > <When talking about shared/team responsibility the story of the four
        > men often arise:
        > "This is a story about four people named Everybody, Somebody,
        > Anybody and Nobody.
        > There was an important job to be done and Everybody was sure that
        > Somebody would do it.
        > Anybody could have done it, but Nobody did it.
        > Somebody got angry about that, because it was Everybody's job.
        > Everybody thought Anybody could to it, but Nobody realised that
        > Everybody wouldn't do it.
        > It ended up that Everybody blamed Somebody when Nobody did what
        > Anybody could have done."
        > Is it unapplicable on Scrum? Is it plain nonsense?>
        >
        > How horrible!! and, yes, it happens all of the time, but not with
        > Scrum. Scrum has the team commit to what they can do over the next
        > Sprint and gives them absolute authority and isolation to do their
        > best to deliver to their commitment. At the end of the team, the
        > team has to demonstrate working product functionality that
        > demonstrates value. Team and working functionality. These are the
        > only things looked at when the Sprint ends.
        > Based on what the team has done, the customer may at that point
        > decide not to fund any further Sprints, or to trade out the entire
        > team and get a new team. A Sprint really puts the team on the spot
        > --- as a group they have committed; as a group, they will be
        judged.
        > It gives us what we've always asked for, the authority and time to
        > do our best. Now we have this freedom for a whole 30 days. Let's
        see
        > what we can build, let's show off a little, let's have some fun and
        > build something really useful, great and neat. We've all seen
        sports
        > teams that are so dysfunctional from interal arguments and
        > politics that they can't perform (Boston RedSox come to mind).
        Every
        > game, just like every Sprint, this dysfunction is real obvious and
        > can be addressed.

        Yes, quite horrible but a nice play on words :-)
        I like the Scrum way much more.

        > <Isn't it easy that the product transforms into different products
        > too much when you're not fixating the end goal? Like starting out
        to
        > be a pc program and then transforms into a internet application and
        > so forth.>
        >
        > The value to the business, the Sprint Goal for each Sprint, the
        > customer decision about what to build in the next Sprint, keeps the
        > team focused.
        > Technology decisions become subservient to business value
        decisions.
        > The business person is left with the tradeoff of increasing
        > marketshare immediately with old technology that will require more
        > maintenance, or increasing marketshare more slowly while
        > implementing more versatile new technology. The business person
        > thinks, "if I'm delivering this functionality sooner than the
        > competition on connected browsers, will I get more customers, OR,
        > should I go for existing functionality on wireless devices and
        > create a marketing campaign that shows us as advanced and our
        > competition as behind the times?" Business decisions drive
        > technology decision, for the life of the product and for the
        > initiation of each Sprint.

        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?

        > <In Scrum there are no such thing as time reporting, right? Can the
        > members choose to work 30 hours week?
        > Isn't it common that the customer would like to see figure of how
        > much time is spent on different activities?>
        >
        > Yeetch!!! What do you care about my hours, my dress, my anything if
        > the team is collaborating with the user and delivering business
        > value. The deal at the start of the Sprint is, "we'll agree on what
        > business value to deliver over the Sprint, and then we the team
        have
        > complete autonomy to figure out how we'll do so." If the team
        > figures that they work best together during the night hours and
        > management insists that they work during the day, management has
        > placed an impediment on the team that prevents it from delivering
        > the most business value. As such, management is violating their
        > primary responsibility ... the productivity of the organization and
        > the overall sustenance and survival of the orgnization. This type
        of
        > change in thinking takes time, but the teams love it because it
        > treats them as responsible adults and holds them to it.

        No dress code? :-)
        But they still have to report how much they work to the company,
        right? Or is the salary fixed? (That would be great, but is it
        possible?)

        > <Are process improvement models, e.g. CMM,SPICE,ISO9001 applicable
        > to> Scrum?>
        >
        > Maybe, but I don't really care. Process improvement was put in
        place
        > to try to make the defined processes work better (see chapter 6 in
        > the book). The underlying assumption is that everyone would have to
        > follow the improved process and therefore greater productivity and
        > predictability would occur.
        > Scrum only puts a framework in place. When we wrap Scrum around XP,
        > we're wrapping Scrum around a great set of engineering processes,
        > but XP processes also aren't "defined", pert chart based processes,
        > so much as a framework.

        Perhaps there will emerge Emperical-CMM :-)

        > <Which career paths is possible with Scrum? Only developer
        > ->ScrumMaster? If so, isn't this a drawback?>
        >
        > Scrum tightly links the business and the teams. People evolve and
        > self-organize into the roles that they fulfill best. Some engineers
        > become sales-support or customer implementation because they love
        > working in customer environments. This evolves based on personal
        > desires, skills, and tendencies tied to business needs. This, of
        > course, drives HR nuts, because HR is mostly designed around
        > predictable, defined, hierarchical career paths. Change the review
        > process so that teams (not just individuals) are rewarded. Open
        > everything up and let people thrive based on their contributions,
        > not politics and all of the "Dilbert" stuff. There are no
        > "system architects" and "lead designers" in Scrum teams. There are
        > only people who are respected and listened to based on their
        > experiences, skills, and effort.

        I like the idea. 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?

        > <Is it customary to educate different stakeholders in Scrum before
        > starting the project? I know of one company that is using DSDM that
        > offers a one-day education about DSDM. How else can you prevent the
        > customer from hiring a competitor who promise the functionality at a
        > fixed price?>
        >
        > DSDM and Scrum deliver fixed price contracts. However, both require
        > collaboration that focuses on delivering the most business value
        for
        > that price in that timeframe. In chapter 5 of the book, Mike and I
        > talk about someone building security into an existing system. Scrum
        > is introduced as no big deal, just a way of dealing with the
        > complexity and allowing management to make adjustments based on
        > what's found. My next set of research is how to introduce
        > collaborative, adaptive, emergent, self-organizing processes like
        > Scrum into an organization as a way of doing business, top down.
        > Right now, with Scrum being implemented bottom up, we low ball the
        > organizational effects. The business people pick up on the benefits
        > and then start wanting "scrum, or whatever that approach is" used
        > more widely.

        So now Scrum is inserted as a flu shot. And when everyone sees the
        remarkable effect they are addicted.

        > <When scaling Scrum up to a large project it seems that the cross-
        > functional teams are lost (the book talks about test, CM, support
        > teams and so forth). Is this the case? Aren't cross-functional an
        > essential part of Scrum?>
        >
        > Teams can be used to address any set of work, such as product
        > support or new product development. Include or exclude
        > responsibilities from teams as needed so that the team can move as
        > quickly as possible without creating long term problems. Jeff
        > Sutherland and I once gave development teams at an organization
        > development responsibility only. They put out code that was
        > difficult to maintain and the support teams got behind. So we
        > implemented a "once you code it, you own it forever" rule which
        > slowed the development teams down, but had them build better
        > software.

        Quite incompatible with the collective ownership rule of XP :-)

        > Best of luck with your thesis. You are in the middle of something
        > really neat.
        > Ken Schwaber

        Thanks! And thanks for all the answers! I don't know if they'll stop
        coming until I've seen Scrum in action so just tell me when to
        stop! :-)
        Yes I start to realise that Scrum is quite neat!

        Jonas Bengtsson
      • Ken Schwaber
        Message 3 of 11 , Nov 26, 2001
          <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.
        • 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 4 of 11 , Nov 26, 2001
            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 5 of 11 , Nov 26, 2001
              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 6 of 11 , Nov 28, 2001
                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 7 of 11 , Nov 28, 2001
                  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 8 of 11 , Nov 29, 2001
                    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.