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

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

Expand Messages
  • Ken Schwaber
    Jonas, I caught your note on the way out, so I ll just make a quick response. I ll answer the rest of your questions tomorrow. XP is aimed at the engineering
    Message 1 of 11 , Nov 24, 2001
    • 0 Attachment
      Jonas,
      I caught your note on the way out, so I'll just make a quick response. I'll
      answer the rest of your questions tomorrow.

      XP is aimed at the engineering team, introducing sound engineering
      principles and human interactions. Scrum is aimed at the way an organization
      goes about new initiatives. Our next book is titled something like,
      "Business Value Driven Project Management", and the focus is how
      organizations that are agile can iteratively and by priority beat the
      competition and deliver value to the marketplace. XP is relatively simple
      and Scrum has been used to wrap it successfully in numerous organizations.
      Scrum starts at the initiative maker, the CEO, CTO, Product VP, Board of
      Directors ... where they need to cause things to happen, and happen quickly.
      Scrum breadth includes both single, software development projects to
      enterprise product development projects, encompassing software, hardware,
      marketing, sales, public relations, and all the other aspects of a product
      that is the core of an organization. For example, GE Finance used Scrum to
      build a leasing system that got them additional market share. They measured
      success not by the project being done on the promised date for the expected
      cost, but by gaining market share.
      Talk to you tomorrow.
      Ken

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


      Hello,
      Now I finally have got the book from Amazon and managed to take the
      time to read it. I must say that the book was really good, especially
      interesting to read about the emergence of Scrum, the principles
      behind it and some case studies. Now I feel even more interested in
      trying it out myself!
      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)

      But of course did the reading of the book make more questions arise
      (please bear with me :-)


      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?

      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.

      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? Is it
      possible for the customer to abort the project between any Sprints?
      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).

      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?

      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.

      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?

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

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

      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?

      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?


      Oups, too many questions! Sorry! :-)

      Best regards,
      Jonas Bengtsson


      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
      Jonas,
      Message 2 of 11 , Nov 25, 2001
      • 0 Attachment
        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 3 of 11 , Nov 26, 2001
        • 0 Attachment
          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 4 of 11 , Nov 26, 2001
          • 0 Attachment
            <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 5 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 6 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 7 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 8 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 9 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.