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

book, "Agile Software Development with Scrum"

Expand Messages
  • Ken Schwaber
    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
    Message 1 of 11 , Oct 17, 2001
      "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
    • jonas.b@home.se
      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
      Message 2 of 11 , Nov 24, 2001
        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
      • 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 3 of 11 , Nov 24, 2001
          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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.