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

Post-Agile-Scrum

Expand Messages
  • Dmitry Beransky
    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
    Message 1 of 16 , Jan 24, 2008
      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 as
      preventing 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
    • Alan Shalloway
      ... with ... to ... you ... Dmitry: I just noticed this. Thanks for asking this great question. Questions to the webinar should be posted on the Lean Agile
      Message 2 of 16 , Feb 1, 2008
        --- 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 as
        > preventing 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
        ... 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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.