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

Re: Post-Agile-Scrum

Expand Messages
  • Tobias Mayer
    ... Beyond Scrum... I m not sure why that phrase makes me uneasy, but it does. Perhaps it has something to do with branding or over-complicating. What
    Message 1 of 16 , Feb 1, 2008
      > The answer to this question will go beyond Scrum...

      Beyond Scrum...  I'm not sure why that phrase makes me uneasy, but it does.  Perhaps it has something to do with branding or over-complicating.  What exactly is leanagilescrum?  Is it like Scrum v2.0, or Scrum for grown-ups or something?  Seriously, is this a statement that Scrum is deficient?

      Tobias



      --- In scrumdevelopment@yahoogroups.com, "Alan Shalloway" <alshall@...> wrote:
      >
      > --- In scrumdevelopment@yahoogroups.com, "Dmitry Beransky"
      > yahoo@ wrote:
      > >
      > > Questions to Alan Shalloway.
      > >
      > > Alan, my team and I listened to you webinar today and we came out with two questions:
      > >
      > > 1) You said that QA's job should be not as much fixing bugs aspreventing them. Our QA person wanted to know what specifically she can do (designing acceptance tests and setting up regression tests) to prevent bugs.
      > >
      > > 2) You talked about managers still being involved in Scrum. Could you give a few specific examples of such involvement?
      > >
      > > Thanks
      > > Dmitry
      > >
      > Dmitry:
      > I just noticed this.
      >
      > Thanks for asking this great question. Questions to the webinar
      > should be posted on the Lean Agile Scrum user group I moderate
      > (http://tech.groups.yahoo.com/group/leanagilescrum). The answer to
      > this question will go beyond Scrum and this user group is meant to be
      > focused on Scrum. In any event, other questions / dialogs about the
      > webinar have already been taking place there and you might find them
      > interesting as well.
      >
      > Alan Shalloway
      > CEO, Net Objectives
      >
    • Mike Cohn
      Tobias-- You left off the (tm). It should always be written as leanagilescrum (tm). Mike
      Message 2 of 16 , Feb 2, 2008
        Tobias--
        You left off the (tm). It should always be written as leanagilescrum (tm).

        Mike


        On Feb 2, 2008, at 12:03 AM, Tobias Mayer wrote:


        > The answer to this question will go beyond Scrum...

        Beyond Scrum...  I'm not sure why that phrase makes me uneasy, but it does.  Perhaps it has something to do with branding or over-complicating.  What exactly is leanagilescrum?  Is it like Scrum v2.0, or Scrum for grown-ups or something?  Seriously, is this a statement that Scrum is deficient?

        Tobias



        --- In scrumdevelopment@ yahoogroups. com, "Alan Shalloway" <alshall@...> wrote:
        >
        > --- In scrumdevelopment@ yahoogroups. com, "Dmitry Beransky" 
        > yahoo@ wrote:
        > >
        > > Questions to Alan Shalloway.
        > > 
        > > Alan, my team and I listened to you webinar today and we came out with two questions:
        > > 
        > > 1) You said that QA's job should be not as much fixing bugs aspreventing them. Our QA person wanted to know what specifically she can do (designing acceptance tests and setting up regression tests) to prevent bugs.
        > > 
        > > 2) You talked about managers still being involved in Scrum. Could you give a few specific examples of such involvement?
        > > 
        > > Thanks
        > > Dmitry
        > >
        > Dmitry:
        > I just noticed this. 
        > 
        > Thanks for asking this great question. Questions to the webinar 
        > should be posted on the Lean Agile Scrum user group I moderate 
        > (http://tech. groups.yahoo. com/group/ leanagilescrum) . The answer to 
        > this question will go beyond Scrum and this user group is meant to be 
        > focused on Scrum. In any event, other questions / dialogs about the 
        > webinar have already been taking place there and you might find them 
        > interesting as well.
        > 
        > Alan Shalloway
        > CEO, Net Objectives
        >


      • Michael James
        ... I m going to beat you all to the punch by forming a leanagilescrumrup group. --mj (king of the Star-Belly Sneetches)
        Message 3 of 16 , Feb 3, 2008
          --- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@...> wrote:
          >
          > Tobias--
          > You left off the (tm). It should always be written as leanagilescrum
          > (tm).
          >
          > Mike

          I'm going to beat you all to the punch by forming a "leanagilescrumrup"
          group.

          --mj (king of the Star-Belly Sneetches)
        • Ilja Preuss
          ... I think it should be something more along the lines of leanagilescrumcrystalfdd . Or perhaps leanagilescrumpairprogrammingtdd . Adding RUP simply adds
          Message 4 of 16 , Feb 3, 2008
            Michael James wrote:
            > --- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@...> wrote:
            >> Tobias--
            >> You left off the (tm). It should always be written as leanagilescrum
            >> (tm).
            >>
            >> Mike
            >
            > I'm going to beat you all to the punch by forming a "leanagilescrumrup"
            > group.


            I think it should be something more along the lines of
            "leanagilescrumcrystalfdd". Or perhaps
            "leanagilescrumpairprogrammingtdd". Adding RUP simply adds too much of a
            different flavor to the mix - or can anyone tell how Scrum is *widening*
            the topic from Agile?

            Cheers, Ilja
          • woynam
            You left off the tm, leanagilescrumruptm.
            Message 5 of 16 , Feb 4, 2008
              You left off the tm,

              leanagilescrumruptm.


              --- In scrumdevelopment@yahoogroups.com, "Michael James" <michael@...>
              wrote:
              >
              > --- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@> wrote:
              > >
              > > Tobias--
              > > You left off the (tm). It should always be written as leanagilescrum
              > > (tm).
              > >
              > > Mike
              >
              > I'm going to beat you all to the punch by forming a "leanagilescrumrup"
              > group.
              >
              > --mj (king of the Star-Belly Sneetches)
              >
            • Alan Shalloway
              ... it ... Scrum ... Tobias: As I mentioned to Dmitry, I am happy to answer this question on the LeanAgileScrum user group. The answer involves more than what
              Message 6 of 16 , Feb 4, 2008
                --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer"
                <tobyanon@...> wrote:
                >
                >
                > > The answer to this question will go beyond Scrum...
                >
                > Beyond Scrum... I'm not sure why that phrase makes me uneasy, but
                it
                > does. Perhaps it has something to do with branding or
                > over-complicating. What exactly is leanagilescrum? Is it like
                Scrum
                > v2.0, or Scrum for grown-ups or something? Seriously, is this a
                > statement that Scrum is deficient?
                >
                > Tobias
                >
                Tobias:

                As I mentioned to Dmitry, I am happy to answer this question on the
                LeanAgileScrum user group. The answer involves more than what is in
                Scrum and this user group is about Scrum. I don't want to get banned
                again.

                Alan Shalloway
                CEO, Net Objectives

                >
                >
                > --- In scrumdevelopment@yahoogroups.com, "Alan Shalloway" <alshall@>
                > wrote:
                > >
                > > --- In scrumdevelopment@yahoogroups.com, "Dmitry Beransky"
                > > yahoo@ wrote:
                > > >
                > > > Questions to Alan Shalloway.
                > > >
                > > > Alan, my team and I listened to you webinar today and we came
                out
                > with two questions:
                > > >
                > > > 1) You said that QA's job should be not as much fixing bugs
                > aspreventing them. Our QA person wanted to know what specifically
                she
                > can do (designing acceptance tests and setting up regression tests)
                to
                > prevent bugs.
                > > >
                > > > 2) You talked about managers still being involved in Scrum.
                Could
                > you give a few specific examples of such involvement?
                > > >
                > > > Thanks
                > > > Dmitry
                > > >
                > > Dmitry:
                > > I just noticed this.
                > >
                > > Thanks for asking this great question. Questions to the webinar
                > > should be posted on the Lean Agile Scrum user group I moderate
                > > (http://tech.groups.yahoo.com/group/leanagilescrum). The answer to
                > > this question will go beyond Scrum and this user group is meant
                to be
                > > focused on Scrum. In any event, other questions / dialogs about
                the
                > > webinar have already been taking place there and you might find
                them
                > > interesting as well.
                > >
                > > Alan Shalloway
                > > CEO, Net Objectives
                > >
                >
              • Alan Shalloway
                ... Of course Scrum is deficient. Virtually everything is deficient. Things are good for certain things. Not for everything. Scrum is really great for some
                Message 7 of 16 , Feb 4, 2008
                  --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer"
                  <tobyanon@...> wrote:
                  > Seriously, is this a
                  > statement that Scrum is deficient?
                  >
                  > Tobias
                  >

                  Of course Scrum is deficient. Virtually everything is deficient.
                  Things are good for certain things. Not for everything. Scrum is
                  really great for some things, not for others.

                  To say you can't live on just protein makes protein deficient. But
                  not bad. Scrum is great. It's just that it focuses on teams,
                  projects and customers. It's very good for that. That is not always
                  what the problem is, however. Especially in larger organizations.

                  However, I can't go very far on this discussion group, so I'll leave
                  this at that here.

                  Alan Shalloway

                  >
                  >
                  > --- In scrumdevelopment@yahoogroups.com, "Alan Shalloway" <alshall@>
                  > wrote:
                  > >
                  > > --- In scrumdevelopment@yahoogroups.com, "Dmitry Beransky"
                  > > yahoo@ wrote:
                  > > >
                  > > > Questions to Alan Shalloway.
                  > > >
                  > > > Alan, my team and I listened to you webinar today and we came
                  out
                  > with two questions:
                  > > >
                  > > > 1) You said that QA's job should be not as much fixing bugs
                  > aspreventing them. Our QA person wanted to know what specifically
                  she
                  > can do (designing acceptance tests and setting up regression tests)
                  to
                  > prevent bugs.
                  > > >
                  > > > 2) You talked about managers still being involved in Scrum.
                  Could
                  > you give a few specific examples of such involvement?
                  > > >
                  > > > Thanks
                  > > > Dmitry
                  > > >
                  > > Dmitry:
                  > > I just noticed this.
                  > >
                  > > Thanks for asking this great question. Questions to the webinar
                  > > should be posted on the Lean Agile Scrum user group I moderate
                  > > (http://tech.groups.yahoo.com/group/leanagilescrum). The answer to
                  > > this question will go beyond Scrum and this user group is meant
                  to be
                  > > focused on Scrum. In any event, other questions / dialogs about
                  the
                  > > webinar have already been taking place there and you might find
                  them
                  > > interesting as well.
                  > >
                  > > Alan Shalloway
                  > > CEO, Net Objectives
                  > >
                  >
                • Tobias Mayer
                  But Scrum isn t protein... or carbohydrates. It isn t a thing, rather it is a framework for things. Scrum is a diet plan; it isn t the food. A balanced diet
                  Message 8 of 16 , Feb 4, 2008
                    But Scrum isn't protein... or carbohydrates. It isn't a thing, rather
                    it is a framework for things. Scrum is a diet plan; it isn't the food.
                    A balanced diet is deficient if you abuse it, neglect certain aspects of
                    it or assume to know better than the dietician.

                    Okay... ridiculous metaphor ending now. It is too late for this
                    nonsense.

                    Tobias


                    --- In scrumdevelopment@yahoogroups.com, "Alan Shalloway" <alshall@...>
                    wrote:
                    >
                    > --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer"
                    > tobyanon@ wrote:
                    > > Seriously, is this a
                    > > statement that Scrum is deficient?
                    > >
                    > > Tobias
                    > >
                    >
                    > Of course Scrum is deficient. Virtually everything is deficient.
                    > Things are good for certain things. Not for everything. Scrum is
                    > really great for some things, not for others.
                    >
                    > To say you can't live on just protein makes protein deficient. But
                    > not bad. Scrum is great. It's just that it focuses on teams,
                    > projects and customers. It's very good for that. That is not always
                    > what the problem is, however. Especially in larger organizations.
                    >
                    > However, I can't go very far on this discussion group, so I'll leave
                    > this at that here.
                    >
                    > Alan Shalloway
                    >
                    ...
                    \
                  • Alan Shalloway
                    ... rather ... food. ... aspects of ... OK, bad metaphor. But it s not a framework for _everything_. That s my point. So the question to me is, what is the
                    Message 9 of 16 , Feb 5, 2008
                      --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer"
                      <tobyanon@...> wrote:
                      >
                      > But Scrum isn't protein... or carbohydrates. It isn't a thing,
                      rather
                      > it is a framework for things. Scrum is a diet plan; it isn't the
                      food.
                      > A balanced diet is deficient if you abuse it, neglect certain
                      aspects of
                      > it or assume to know better than the dietician.
                      >
                      > Okay... ridiculous metaphor ending now. It is too late for this
                      > nonsense.
                      >

                      OK, bad metaphor. But it's not a framework for _everything_. That's
                      my point. So the question to me is, what is the scope of Scrum?
                      Where is it good to be applied? Everywhere, for everything? Is
                      anybody claiming that? Scrum can obviously be used for more than
                      software development since its origins were not in software
                      development but rather product development.

                      I believe there are limits to the Scope of Scrum. That doesn't mean
                      I don't like Scrum (See my blog "Praise for Scrum"
                      http://www.netobjectives.com/blogs/praise-for-scrum).

                      Let's look at what I do not believe is part of Scrum. If you think
                      it is, please point me to Scrum materials where these are discussed:

                      1. Focus on time not $$$
                      2. Value stream mapping
                      3. Look to the system for errors when they occur, not the people
                      4. Focus on building smaller pieces of functionality so you can
                      manage product portolios more effectively
                      5. Think in terms of your product lines, not your projects
                      6. One of management's main roles is to educate their staff
                      7. Use design patterns to defer commitment and handle variations in
                      implementation

                      (most of these are lean concepts).

                      Here are some concepts that are not part of Scrum but which most
                      successful Scrum teams have incorporated into their use of Scrum:

                      1. select XP engineering practices (most particularly, up-front
                      testing and continuous integration)
                      2. defining acceptance tests before writing code

                      What is unique to Scrum?
                      I'd say not much since it is a manifestation of Lean principles.

                      I wonder why one can't take the attitude that Scrum isn't everything
                      to everybody without someone thinking I'm attacking Scrum?

                      Now I believe I've still managed to stay within the range of this
                      user group by talking about the scope of Scrum. If you want more
                      information from me on those things outside of Scrum we'll have to
                      do that elsewhere.

                      Alan Shalloway
                      CEO, Net Objectives
                    • Michael James
                      ... I think most of us agree Scrum is an open framework, silent on most issues, raising more questions than it answers. Silence makes people uncomfortable --
                      Message 10 of 16 , Feb 6, 2008
                        --- In scrumdevelopment@yahoogroups.com, "Alan Shalloway" <alshall@...> wrote:

                        > Let's look at what I do not believe is part of Scrum. If you think
                        > it is, please point me to Scrum materials where these are discussed:
                        >
                        > [etc.]

                        I think most of us agree Scrum is an open framework, silent on
                        most issues, raising more questions than it answers. Silence
                        makes people uncomfortable -- we all want to be spoon fed
                        easy answers though at some level we realize there are none.

                        Coaches who *get Scrum* use this silence to shift the
                        responsibility of answering these questions away from the
                        methodologist back to the practitioner. While canned
                        answers work well for some situations, they've failed
                        us badly when applied to uncertain requirements and
                        uncertain technologies.


                        --mj
                      • Alan Shalloway
                        ... I hear people say this, but then I wonder why I am so often attacked for saying Scrum has limits. ... One of my favorite sayings is from Voltaire -
                        Message 11 of 16 , Feb 6, 2008
                          --- In scrumdevelopment@yahoogroups.com, "Michael James"
                          <michael@...> wrote:

                          > I think most of us agree Scrum is an open framework, silent on
                          > most issues, raising more questions than it answers.

                          I hear people say this, but then I wonder why I am so
                          often "attacked" for saying Scrum has limits.

                          >Silence makes people uncomfortable -- we all want to be spoon fed
                          > easy answers though at some level we realize there are none.
                          >

                          One of my favorite sayings is from Voltaire - "Doubt is
                          uncomfortable, certainty is ridiculous."

                          > Coaches who *get Scrum* use this silence to shift the
                          > responsibility of answering these questions away from the
                          > methodologist back to the practitioner. While canned
                          > answers work well for some situations, they've failed
                          > us badly when applied to uncertain requirements and
                          > uncertain technologies.

                          When people are armed with the knowledge to figure out their
                          problems, I let them do that. That is critical. When people don't
                          have the knowledge to figure out their problems, it is negligence to
                          expect them to do so. A good coach can tell the difference. A good
                          coach won't give them answers, but rather guide them with basics or
                          with good questions to get where they need to be. At times, a
                          starting point may be given.

                          If a coach sees that people are looking at the wrong thing, sometimes
                          it is worth saying - hey, look at this, not that! Don't take me too
                          literally here, I would probably set up what if questions, etc.

                          Again, I believe you have re-iterated my point. Scrum is a
                          framework. Perhaps there are other things besides a framework that
                          could be useful to a team and/or enterprise the team is working in.

                          Alan Shalloway
                          CEO, Net Objectives
                        • Simon Kirk
                          ... I see your point, but I do wonder how you feel qualified at the time to assume you know the right starting point. Perhaps I don t understand how much you
                          Message 12 of 16 , Feb 10, 2008
                            On 6 Feb 2008, at 17:01, Alan Shalloway wrote:
                            > --- In scrumdevelopment@yahoogroups.com, "Michael James"
                            > <michael@...> wrote:
                            >
                            > > I think most of us agree Scrum is an open framework, silent on
                            > > most issues, raising more questions than it answers.
                            >
                            > I hear people say this, but then I wonder why I am so
                            > often "attacked" for saying Scrum has limits.
                            >
                            > >Silence makes people uncomfortable -- we all want to be spoon fed
                            > > easy answers though at some level we realize there are none.
                            > >
                            >
                            > One of my favorite sayings is from Voltaire - "Doubt is
                            > uncomfortable, certainty is ridiculous."
                            >
                            > > Coaches who *get Scrum* use this silence to shift the
                            > > responsibility of answering these questions away from the
                            > > methodologist back to the practitioner. While canned
                            > > answers work well for some situations, they've failed
                            > > us badly when applied to uncertain requirements and
                            > > uncertain technologies.
                            >
                            > When people are armed with the knowledge to figure out their
                            > problems, I let them do that. That is critical. When people don't
                            > have the knowledge to figure out their problems, it is negligence to
                            > expect them to do so. A good coach can tell the difference. A good
                            > coach won't give them answers, but rather guide them with basics or
                            > with good questions to get where they need to be. At times, a
                            > starting point may be given.
                            >
                            I see your point, but I do wonder how you feel qualified at the time
                            to assume you know the right starting point. Perhaps I don't
                            understand how much you know about "their" situation; I'd be
                            interested in how you make the decision to provide the starting point
                            or not.
                            >
                            >
                            > If a coach sees that people are looking at the wrong thing, sometimes
                            > it is worth saying - hey, look at this, not that! Don't take me too
                            > literally here, I would probably set up what if questions, etc.
                            >
                            > Again, I believe you have re-iterated my point. Scrum is a
                            > framework. Perhaps there are other things besides a framework that
                            > could be useful to a team and/or enterprise the team is working in.
                            >
                            >
                            Here's where I worry about this conversation about the "limits of
                            Scrum" - that is, how does one decide to define limits on a framework
                            that doesn't define an explicit interest in (say) any of the areas you
                            defined in your examples of the limitations of Scrum.

                            What I mean is how can one say any of those examples is a limit of
                            Scrum, when they aren't really what Scrum "talks about". I agree that
                            there are other things besides a framework for the team to discuss,
                            but any of them can be done by the team within their application of
                            Scrum.

                            At that point it's a grey area whether they are within the scope of
                            Scrum or not: for example they're "outside" as they're not explicitly
                            defined by Scrum, but they're "inside" because one can do them within
                            Scrum. For instance (I'm not advocating this by the way) one could
                            define tasks to represent use of design patterns (your point seven),
                            and presto! They're trackable in a burndown, say. Are they within
                            Scrum now, or not?
                          • Alan Shalloway
                            ... time ... point ... Well, working with dozens of teams over the last few years and being associated with other trainers/coaches in our company that have
                            Message 13 of 16 , Feb 10, 2008
                              --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@...> wrote:
                              >

                              > I see your point, but I do wonder how you feel qualified at the
                              time
                              > to assume you know the right starting point. Perhaps I don't
                              > understand how much you know about "their" situation; I'd be
                              > interested in how you make the decision to provide the starting
                              point
                              > or not.

                              Well, working with dozens of teams over the last few years and being
                              associated with other trainers/coaches in our company that have
                              worked on even more gives me a fair amount of experience. But
                              perhaps more importantly, by understanding Lean principles I can see
                              what is causing the impediments better than the team can.

                              As I've been repeatedly saying, Lean gives insights into how to solve
                              many of the impediments teams face. In other words, I've seen it
                              before. But actually, it doesn't matter if the start is "correct".
                              The team needs to be infused with the attitude of continuously
                              improving their process. Thus, if things are not optimal (they never
                              will be) they will improve it anyway.

                              > >
                              > >
                              > Here's where I worry about this conversation about the "limits of
                              > Scrum" - that is, how does one decide to define limits on a
                              framework
                              > that doesn't define an explicit interest in (say) any of the areas
                              you
                              > defined in your examples of the limitations of Scrum.
                              >
                              > What I mean is how can one say any of those examples is a limit of
                              > Scrum, when they aren't really what Scrum "talks about". I agree
                              that
                              > there are other things besides a framework for the team to
                              discuss,
                              > but any of them can be done by the team within their application
                              of
                              > Scrum.
                              >
                              > At that point it's a grey area whether they are within the scope
                              of
                              > Scrum or not: for example they're "outside" as they're not
                              explicitly
                              > defined by Scrum, but they're "inside" because one can do them
                              within
                              > Scrum. For instance (I'm not advocating this by the way) one could
                              > define tasks to represent use of design patterns (your point
                              seven),
                              > and presto! They're trackable in a burndown, say. Are they within
                              > Scrum now, or not?
                              >

                              Well, I agree that limits may be the wrong word. Scope is probably
                              better. However, in your example, what would be in the scope would
                              be the tracking of design patterns, not the design patterns
                              themselves.

                              Alan Shalloway
                              CEO, Net Objectives
                            • Mike Sutton
                              Most of the points made in this thread are very relevant, I do feel that scope of Scrum is pretty huge. Particularly with the CSM role - remove all/any
                              Message 14 of 16 , Feb 11, 2008
                                Most of the points made in this thread are very relevant, I do feel
                                that 'scope' of Scrum is pretty huge. Particularly with the CSM role
                                - remove all/any obstacle that is impeding the Team's ability to
                                deliver its commitment.

                                Thats a pretty tall order that can set the SM on a collision course
                                with practically everyone in the business - even the team!!

                                So off all the great points made in this thread, the one that I'm
                                most pleased at seeing is...

                                Infusing the team with the attitude of continuous improvement. It is
                                at the heart of agile. A good coach knows to ask the dumb questions
                                that create opportunities to inspect. Then adaption becomes something
                                that can be considered.

                                thats my tuppence worth.
                                mike
                                csm.csp.cspo.certified.certifiable.


                                --- In scrumdevelopment@yahoogroups.com, "Alan
                                Shalloway" <alshall@...> wrote:
                                >
                                > --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@> wrote:
                                > >
                                >
                                > > I see your point, but I do wonder how you feel qualified at the
                                > time
                                > > to assume you know the right starting point. Perhaps I don't
                                > > understand how much you know about "their" situation; I'd be
                                > > interested in how you make the decision to provide the starting
                                > point
                                > > or not.
                                >
                                > Well, working with dozens of teams over the last few years and
                                being
                                > associated with other trainers/coaches in our company that have
                                > worked on even more gives me a fair amount of experience. But
                                > perhaps more importantly, by understanding Lean principles I can
                                see
                                > what is causing the impediments better than the team can.
                                >
                                > As I've been repeatedly saying, Lean gives insights into how to
                                solve
                                > many of the impediments teams face. In other words, I've seen it
                                > before. But actually, it doesn't matter if the start is
                                "correct".
                                > The team needs to be infused with the attitude of continuously
                                > improving their process. Thus, if things are not optimal (they
                                never
                                > will be) they will improve it anyway.
                                >
                                > > >
                                > > >
                                > > Here's where I worry about this conversation about the "limits
                                of
                                > > Scrum" - that is, how does one decide to define limits on a
                                > framework
                                > > that doesn't define an explicit interest in (say) any of the
                                areas
                                > you
                                > > defined in your examples of the limitations of Scrum.
                                > >
                                > > What I mean is how can one say any of those examples is a limit
                                of
                                > > Scrum, when they aren't really what Scrum "talks about". I agree
                                > that
                                > > there are other things besides a framework for the team to
                                > discuss,
                                > > but any of them can be done by the team within their application
                                > of
                                > > Scrum.
                                > >
                                > > At that point it's a grey area whether they are within the scope
                                > of
                                > > Scrum or not: for example they're "outside" as they're not
                                > explicitly
                                > > defined by Scrum, but they're "inside" because one can do them
                                > within
                                > > Scrum. For instance (I'm not advocating this by the way) one
                                could
                                > > define tasks to represent use of design patterns (your point
                                > seven),
                                > > and presto! They're trackable in a burndown, say. Are they
                                within
                                > > Scrum now, or not?
                                > >
                                >
                                > Well, I agree that limits may be the wrong word. Scope is probably
                                > better. However, in your example, what would be in the scope
                                would
                                > be the tracking of design patterns, not the design patterns
                                > themselves.
                                >
                                > Alan Shalloway
                                > CEO, Net Objectives
                                >
                              Your message has been successfully submitted and would be delivered to recipients shortly.