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

RE: [SPAM] Re: [scrumdevelopment] Scrum Vs Prince2

Expand Messages
  • Ken Schwaber
    His way of forcing the two together. The matrix that Mike referred to was not helpful, Ken _____ From: scrumdevelopment@yahoogroups.com
    Message 1 of 20 , May 2, 2007
    • 0 Attachment

      His way of forcing the two together. The matrix that Mike referred to was not helpful,

      Ken

       


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Nicholas Cancelliere
      Sent: Tuesday, May 01, 2007 8:35 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [SPAM] Re: [scrumdevelopment] Scrum Vs Prince2

       

       

      Is it just me - or does anyone else have a problem with this statement:

       

      "I find it particularly useful as Scrum is, at best, a skeleton that needs a lot of meat both inside, and in terms of topping and tailing a project."

       

      I wonder what he means by this.

       

       

      Nicholas

       

       

       

      On May 1, 2007, at 3:29 AM, bc purushotham wrote:



      Hi All,

      Can you please tell me what is the difference and
      similarities between Scrum and Prince2.

      Is is possible to use Scrum in prince2 project.

      Thanks,
      p

      ____________ _________ _________ _________ _________ __
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail. yahoo.com

       

    • dnicolet99
      I don t know what *he* means by it, but I think it s correct to say that Scrum is intentionally lightweight and allows for any sort of iterative process to be
      Message 2 of 20 , May 2, 2007
      • 0 Attachment
        I don't know what *he* means by it, but I think it's correct to say
        that Scrum is intentionally lightweight and allows for any sort of
        iterative process to be used along with it.

        It's significant that he writes, "at best." I think that gives away a
        bias on his part. I've noticed that sometimes people criticize Scrum
        because it omits methodological details; as I see it, that's a
        strength of Scrum, not a weakness. If someone is just looking for a
        project management cookbook, then they may find Scrum doesn't give
        them enough specific guidance for their needs.

        Dave

        --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
        <nickaustin74@...> wrote:
        >
        >
        > Is it just me - or does anyone else have a problem with this statement:
        >
        > "I find it particularly useful as Scrum is, at best, a skeleton that
        > needs a lot of meat both inside, and in terms of topping and tailing
        > a project."
        >
        > I wonder what he means by this.
        >
        >
        > Nicholas
        >
        >
        >
        > On May 1, 2007, at 3:29 AM, bc purushotham wrote:
        >
        > > Hi All,
        > >
        > > Can you please tell me what is the difference and
        > > similarities between Scrum and Prince2.
        > >
        > > Is is possible to use Scrum in prince2 project.
        > >
        > > Thanks,
        > > p
        > >
        > > __________________________________________________
        > > Do You Yahoo!?
        > > Tired of spam? Yahoo! Mail has the best spam protection around
        > > http://mail.yahoo.com
        > >
        > >
        >
      • Ken Schwaber
        Dave, We specifically leave off the guidance or prescription to leave the people free and responsible for managing for value, Sprint by Sprint. We break the
        Message 3 of 20 , May 2, 2007
        • 0 Attachment

          Dave,

          We specifically leave off the guidance or prescription to leave the people free and responsible for managing for value, Sprint by Sprint. We break the management role into three parts:

          1. The team is responsible for managing itself.
          2. The ScrumMaster is responsible for managing the Process
          3. The Product Owner is responsible for managing the Product Backlog, or “What” to maximize value. The PO tells the team what to do, the team figures out how to do it.

           

          In the matrix, you give a lot of responsibility to the ScrumMaster that they don’t own. They aren’t a replacement project manager. They are simply a process manager and change agent.

           

          Scrum doesn’t leave out project management methodological details to have them filled in by other methodologies. It relies on the above three groups to fill them in based on their knowledge, the circumstances, and their intelligence. Scrum relies on a feedback loop for them to improve, not external directions.

           

          Ken

           


          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of dnicolet99
          Sent: Wednesday, May 02, 2007 11:12 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [SPAM] [scrumdevelopment] Re: Scrum Vs Prince2

           

          I don't know what *he* means by it, but I think it's correct to say
          that Scrum is intentionally lightweight and allows for any sort of
          iterative process to be used along with it.

          It's significant that he writes, "at best." I think that gives away a
          bias on his part. I've noticed that sometimes people criticize Scrum
          because it omits methodological details; as I see it, that's a
          strength of Scrum, not a weakness. If someone is just looking for a
          project management cookbook, then they may find Scrum doesn't give
          them enough specific guidance for their needs.

          Dave

          --- In scrumdevelopment@ yahoogroups. com, Nicholas Cancelliere
          <nickaustin74@ ...> wrote:

          >
          >
          > Is it just me - or does anyone else have a problem with this statement:
          >
          > "I find it particularly useful as Scrum is, at best, a skeleton that
          > needs a lot of meat both inside, and in terms of topping and tailing
          > a project."
          >
          > I wonder what he means by this.
          >
          >
          > Nicholas
          >
          >
          >
          > On May 1, 2007, at 3:29 AM, bc purushotham wrote:
          >
          > > Hi All,
          > >
          > > Can you please tell me what is the difference and
          > > similarities between Scrum and Prince2.
          > >
          > > Is is possible to use Scrum in prince2 project.
          > >
          > > Thanks,
          > > p
          > >
          > > ____________ _________ _________ _________ _________ __
          > > Do You Yahoo!?
          > > Tired of spam? Yahoo! Mail has the best spam protection around
          > > http://mail. yahoo.com
          > >
          > >
          >

        • dnicolet99
          Ken, Thanks for the explanation. ... people ... break the ... that they ... Well, it isn t my matrix. I do think it reflects reality in many cases. It s not
          Message 4 of 20 , May 2, 2007
          • 0 Attachment
            Ken,

            Thanks for the explanation.


            > We specifically leave off the guidance or prescription to leave the
            people
            > free and responsible for managing for value, Sprint by Sprint. We
            break the
            > management role into three parts:
            >
            > 1. The team is responsible for managing itself.
            > 2. The ScrumMaster is responsible for managing the Process
            > 3. The Product Owner is responsible for managing the Product Backlog,
            > or "What" to maximize value. The PO tells the team what to do, the team
            > figures out how to do it.
            >
            >
            >
            > In the matrix, you give a lot of responsibility to the ScrumMaster
            that they
            > don't own. They aren't a replacement project manager. They are simply a
            > process manager and change agent.

            Well, it isn't my matrix. I do think it reflects reality in many
            cases. It's not always possible to act strictly as a process manager
            and change agent because in many cases management doesn't recognize
            the need for that role as distinct from the PM role. Even though
            that's less than ideal, when we have an opportunity to effect positive
            change it seems to me we ought to try.



            >
            > Scrum doesn't leave out project management methodological details to
            have
            > them filled in by other methodologies. It relies on the above three
            groups
            > to fill them in based on their knowledge, the circumstances, and their
            > intelligence. Scrum relies on a feedback loop for them to improve, not
            > external directions.

            Thanks for the clarification. I suspect many people miss that
            particular point. Maybe that's why some people say Scrum is
            incomplete. It demands a certain level of maturity on the part of team
            members and management. They may be unaccustomed to that, since
            conventional processes are prescriptive.

            Dave
          • Ken Schwaber
            It does require a certain level of maturity. If it isn t there, it exposes the consequences so the shortfalls can be addressed based on the severity of
            Message 5 of 20 , May 2, 2007
            • 0 Attachment

              It does require a certain level of maturity. If it isn’t there, it exposes the consequences so the shortfalls can be addressed based on the severity of consequences. The traditional PM approach says, “here it is, do it all and you’ll be fine.” Scrum says, “do it, and you’ll soon know where you are really in trouble so you can specifically address those areas first.”

              Best wishes,  Dave,

               

              Ken

               


              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of dnicolet99
              Sent: Wednesday, May 02, 2007 2:07 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: [SPAM] [SPAM] [scrumdevelopment] Re: Scrum Vs Prince2

               

              Ken,

              Thanks for the explanation.

              > We specifically leave off the guidance or prescription to leave the
              people
              > free and responsible for managing for value, Sprint by Sprint. We
              break the
              > management role into three parts:
              >
              > 1. The team is responsible for managing itself.
              > 2. The ScrumMaster is responsible for managing the Process
              > 3. The Product Owner is responsible for managing the Product Backlog,
              > or "What" to maximize value. The PO
              tells the team what to do, the team
              > figures out how to do it.
              >
              >
              >
              > In the matrix, you give a lot of responsibility to the ScrumMaster
              that they
              > don't own. They aren't a replacement project manager. They are simply a
              > process manager and change agent.

              Well, it isn't my matrix. I do think it reflects reality in many
              cases. It's not always possible to act strictly as a process manager
              and change agent because in many cases management doesn't recognize
              the need for that role as distinct from the PM role. Even though
              that's less than ideal, when we have an opportunity to effect positive
              change it seems to me we ought to try.

              >
              > Scrum doesn't leave out project management methodological details to
              have
              > them filled in by other methodologies. It relies on the above three
              groups
              > to fill them in based on their knowledge, the circumstances, and their
              > intelligence. Scrum relies on a feedback loop for them to improve, not
              > external directions.

              Thanks for the clarification. I suspect many people miss that
              particular point. Maybe that's why some people say Scrum is
              incomplete. It demands a certain level of maturity on the part of team
              members and management. They may be unaccustomed to that, since
              conventional processes are prescriptive.

              Dave

            • srinivas chillara
              ... Agreed. However, Don t you think a projecgt management cookbook, or guide etc, could be useful!?! (here I am not criticising what you ve written below, I m
              Message 6 of 20 , May 2, 2007
              • 0 Attachment
                > I've noticed that sometimes people
                > criticize Scrum
                > because it omits methodological details; as I see
                > it, that's a
                > strength of Scrum, not a weakness.

                Agreed.

                However, Don't you think a projecgt management
                cookbook, or guide etc, could be useful!?!
                (here I am not criticising what you've written below,
                I'm just wondering).
                >If someone is
                > just looking for a
                > project management cookbook, then they may find
                > Scrum doesn't give
                > them enough specific guidance for their needs.



                The traditional C-and-C means of executing projects
                (in an IT setting) must be having something in value
                for us. Maynot be the general Command and control
                approach, but some aspects. Maybe the way QC is set up
                independantly, more likely risk management, etc.


                Regards
                Cheenie


                Send a FREE SMS to your friend's mobile from Yahoo! Messenger. Get it now at http://in.messenger.yahoo.com/
              • David H.
                ... It in deed does, even though that only happens on a psychological level. C&C structures allows to perceive an illusion of control. We like to be in
                Message 7 of 20 , May 3, 2007
                • 0 Attachment
                  > The traditional C-and-C means of executing projects
                  > (in an IT setting) must be having something in value
                  > for us. Maynot be the general Command and control
                  > approach, but some aspects. Maybe the way QC is set up
                  > independantly, more likely risk management, etc.
                  >
                  It in deed does, even though that only happens on a psychological
                  level. C&C structures allows to perceive an illusion of control. We
                  like to be in control, it makes us feel safe and, you guessed it, in
                  control. Unfortunately that does not work for complex systems, still
                  be try to believe that we can command and control those environment,
                  because operating in a more free and less controlled manner makes us
                  feel uneasy.

                  But I could not explain this better than the many blogs and books that
                  have been written on this topic already.




                  --
                  Sent from gmail so do not trust this communication.
                  Do not send me sensitive information here, ask for my none-gmail accounts.

                  "Therefore the considerations of the intelligent always include both
                  benefit and harm." - Sun Tzu
                • dnicolet99
                  Hi Cheenie, Philosophically, I agree with Ken on this. I don t think the command-and-control approach works very well at all. I think a process cookbook can
                  Message 8 of 20 , May 3, 2007
                  • 0 Attachment
                    Hi Cheenie,

                    Philosophically, I agree with Ken on this. I don't think the
                    command-and-control approach works very well at all. I think a process
                    cookbook can easily become a crutch.

                    When a process cookbook is useful, it's only as a fallback position
                    for organizations that lack the maturity to work with a lightweight
                    framework like Scrum. Unfortunately, at the moment most organizations
                    fall into that category.

                    I hesitate to call a process cookbook "useful," because the choice of
                    words might be understood to mean I think it's "just as good." Rather
                    than "useful," I might say a process cookbook is "better than
                    nothing," or perhaps that it can be a pragmatic interim approach along
                    the way toward agility, provided people don't become too comfortable
                    with it and therefore cease to pursue continuous improvement.

                    When you say command-and-control must have something useful for us, I
                    wonder if it is an assumption based on the fact that things have been
                    done that way for such a long time. It's hard to accept the idea that
                    very smart people have been working in a suboptimal way, on purpose,
                    for decades on end.

                    Yet the Chaos Report for 1994, prior to widespread acceptance of Scrum
                    and other methods we now call "agile," indicates traditional-style IT
                    projects enjoyed a success rate under 20%. It determined most IT
                    projects were "challenged," which is a politically correct way to say
                    they did not deliver the expected value and did not come in on
                    schedule or on budget. That's where command-and-control will take you.

                    Separation of QC or QA isn't an aspect of command-and-control, it's
                    just a way of organizing the work. I'm not so sure QC or QA should be
                    as separate as it often is, anyway. Most of the work QC/QA specialists
                    do can be integrated directly into the development process and testers
                    can develop professionally along the lines of generalizing
                    specialists, just as developers are doing.

                    Risk management is something that must be done on all projects, but I
                    don't think it is connected with command-and-control vs agile
                    management. It's just part of the work to be done.

                    Dave

                    --- In scrumdevelopment@yahoogroups.com, srinivas chillara
                    <ceezone@...> wrote:
                    >
                    > > I've noticed that sometimes people
                    > > criticize Scrum
                    > > because it omits methodological details; as I see
                    > > it, that's a
                    > > strength of Scrum, not a weakness.
                    >
                    > Agreed.
                    >
                    > However, Don't you think a projecgt management
                    > cookbook, or guide etc, could be useful!?!
                    > (here I am not criticising what you've written below,
                    > I'm just wondering).
                    > >If someone is
                    > > just looking for a
                    > > project management cookbook, then they may find
                    > > Scrum doesn't give
                    > > them enough specific guidance for their needs.
                    >
                    >
                    >
                    > The traditional C-and-C means of executing projects
                    > (in an IT setting) must be having something in value
                    > for us. Maynot be the general Command and control
                    > approach, but some aspects. Maybe the way QC is set up
                    > independantly, more likely risk management, etc.
                    >
                    >
                    > Regards
                    > Cheenie
                    >
                    >
                    > Send a FREE SMS to your friend's mobile from Yahoo! Messenger.
                    Get it now at http://in.messenger.yahoo.com/
                    >
                  • Ken Schwaber
                    Absolutely . the best guides are all of the books that have been published over the years, such as risk management. The moment it becomes a guide it becomes
                    Message 9 of 20 , May 3, 2007
                    • 0 Attachment

                      Absolutely … the best guides are all of the books that have been published over the years, such as risk management. The moment it becomes a guide it becomes stepwise and restrictive, in my experience.

                      Ken

                       


                      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of srinivas chillara
                      Sent: Thursday, May 03, 2007 12:37 AM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: Re: [scrumdevelopment] Re: Scrum Vs Prince2

                       

                      > I've noticed that sometimes people

                      > criticize Scrum
                      > because it omits methodological details; as I see
                      > it, that's a
                      > strength of Scrum, not a weakness.

                      Agreed.

                      However, Don't you think a projecgt management
                      cookbook, or guide etc, could be useful!?!
                      (here I am not criticising what you've written below,
                      I'm just wondering).
                      >If someone is
                      > just looking for a
                      > project management cookbook, then they may find
                      > Scrum doesn't give
                      > them enough specific guidance for their needs.

                      The traditional C-and-C means of executing projects
                      (in an IT setting) must be having something in value
                      for us. Maynot be the general Command and control
                      approach, but some aspects. Maybe the way QC is set up
                      independantly, more likely risk management, etc.

                      Regards
                      Cheenie

                      Send a FREE SMS to your friend's mobile from Yahoo! Messenger. Get it now at http://in.messenger .yahoo.com/

                    • srinivas chillara
                      ... Aha! But such guide, in hands of sublime experts, like yours truly, don t become restrictive. No one can say I am not cheeky. But seriously, I see what you
                      Message 10 of 20 , May 7, 2007
                      • 0 Attachment
                        > The moment
                        > it becomes a guide it
                        > becomes stepwise and restrictive, in my experience.


                        Aha! But such guide, in hands of sublime experts, like
                        yours truly, don't become restrictive. No one can say
                        I am not cheeky.

                        But seriously, I see what you are saying, once it is
                        codified, it becomes restrictive, except for people
                        who have participated in it's codification, or maybe
                        the very few who truly "get it".

                        Cheenie




                        __________________________________________________________
                        Yahoo! India Answers: Share what you know. Learn something new
                        http://in.answers.yahoo.com/
                      • srinivas chillara
                        ... When you seperate things so clearly, it is difficult to disagree. I meant that ideas which might have come up, or/and matured during the development of C-C
                        Message 11 of 20 , May 7, 2007
                        • 0 Attachment
                          >
                          > Separation of QC or QA isn't an aspect of
                          > command-and-control, it's
                          > just a way of organizing the work. I'm not so sure
                          > QC or QA should be
                          > as separate as it often is, anyway. Most of the work
                          > QC/QA specialists
                          > do can be integrated directly into the development
                          > process and testers
                          > can develop professionally along the lines of
                          > generalizing
                          > specialists, just as developers are doing.
                          >
                          > Risk management is something that must be done on
                          > all projects, but I
                          > don't think it is connected with command-and-control
                          > vs agile
                          > management. It's just part of the work to be done.

                          When you seperate things so clearly, it is difficult
                          to disagree.
                          I meant that ideas which might have come up, or/and
                          matured during the development of C-C methodologies or
                          during those days, have value. Like "Risk mgmt" etc.

                          About seperation of QA/QC and dev, yes we can argue
                          for a while over that, but I'll leave it for another
                          thread.
                          In any case I found what you've written useful (in a
                          positive sense).

                          cheers
                          Cheenie




                          Office firewalls, cyber cafes, college labs, don't allow you to download CHAT? Click here: http://in.messenger.yahoo.com/webmessengerpromo.php
                        • srinivas chillara
                          ... Agreed, anyway I usually don t see things as Agile.vs.something or the other. Hello Dave, On second thoughts, let s not call it a cookbook but practice
                          Message 12 of 20 , May 7, 2007
                          • 0 Attachment
                            > Risk management is something that must be done on
                            > all projects, but I
                            > don't think it is connected with command-and-control
                            > vs agile
                            > management. It's just part of the work to be done.
                            > Dave

                            Agreed, anyway I usually don't see things as
                            Agile.vs.something or the other.


                            Hello Dave,
                            On second thoughts, let's not call it a "cookbook" but
                            "practice guideline".
                            And now have "risk mgmt", perhaps we can use it in the
                            context of Scrum?

                            This is situation that I've been through sometime ago.
                            I was a coach for a team (six good men) implementing
                            Scrum for the first time. We planned the first sprint
                            (4 week), and things went well for about a week. It
                            was important to show good progress to the higher
                            mgmt.
                            After about a week, the PO pushed off on leave
                            (holiday) for 2 weeks. Then just before he returned
                            the Scrum master took a week off, and so did another
                            team member a bit earlier. Ofcourse this impacted the
                            performance of the team for the sprint. They did quite
                            OK. However these exptended holidays of 3 people
                            during the same sprint was a nasty surprise. Actually
                            these people knew they were off on leave, jsut no one
                            thought it important enought to announce! (I know
                            amazing) These leaves were not taken into account
                            during the sprint planning. I think had we done a
                            quick risk assessment (ie rsk mgmt) we would have
                            planned better.


                            Now I am writing a small (one or two pager) Scrum
                            implemnetation guide for the company, so they can
                            think of things to cover while they run their sprint.
                            Like, all team member udate on significant leaves to
                            they are about to be taken that month. I am calling
                            this a "Scrum-running Guide"
                            What's your opinion on this. Should I circulate such a
                            guide for the benifit of the company. To a wider
                            public, or is it not such a good idea? Will this make
                            Scrum more codified/prescriprive/"cookbookish"!?!

                            yours in doubt
                            Cheenie





                            Office firewalls, cyber cafes, college labs, don't allow you to download CHAT? Click here: http://in.messenger.yahoo.com/webmessengerpromo.php
                          • dnicolet99
                            ... You re right to say the problem is that the leave was not taken into consideration during sprint planning. However, it is not a question of risk
                            Message 13 of 20 , May 8, 2007
                            • 0 Attachment
                              --- In scrumdevelopment@yahoogroups.com, srinivas chillara
                              <ceezone@...> wrote:
                              >
                              > However these exptended holidays of 3 people
                              > during the same sprint was a nasty surprise. Actually
                              > these people knew they were off on leave, jsut no one
                              > thought it important enought to announce! (I know
                              > amazing) These leaves were not taken into account
                              > during the sprint planning. I think had we done a
                              > quick risk assessment (ie rsk mgmt) we would have
                              > planned better.

                              You're right to say the problem is that the leave was not taken into
                              consideration during sprint planning. However, it is not a question of
                              risk management. It is not a business risk for employees to take
                              leave. It's normal.

                              What I've seen work well is for each team member to commit to a
                              certain number of hours for the project as part of sprint planning. If
                              we're working 40 hour weeks and we have 4 week sprints, then at most I
                              can devote 160 hours to the project. If I'm planning 2 weeks of leave,
                              then I must commit to 80 hours instead. That way, when the stories are
                              sized and added to the sprint, the team won't overcommit.

                              >
                              > Now I am writing a small (one or two pager) Scrum
                              > implemnetation guide for the company, so they can
                              > think of things to cover while they run their sprint.
                              > Like, all team member udate on significant leaves to
                              > they are about to be taken that month. I am calling
                              > this a "Scrum-running Guide"
                              > What's your opinion on this. Should I circulate such a
                              > guide for the benifit of the company. To a wider
                              > public, or is it not such a good idea? Will this make
                              > Scrum more codified/prescriprive/"cookbookish"!?!

                              It depends. If you try to include everything you can imagine and
                              everything you've read about or heard about, then the guide will be
                              justly ignored.

                              If you include lessons learned in context, such as the problem of the
                              "surprise" leave, then it will be relevant to your environment and
                              people will find it helpful.

                              I would also suggest that you make it a "living" document and update
                              it after each retrospective or after "surprise" lessons are learned. I
                              would further suggest that you never let the guide grow beyond one
                              printed page in length. When you find you are just about to add an
                              item that pushes the length over the one page limit, review the
                              contents and look for items that can be removed. This will help ensure
                              the guide remains relevant and useful while making it possible to post
                              a copy on the wall of team rooms.

                              >
                              > yours in doubt
                              > Cheenie
                              >

                              Yours doubtlessly,
                              Dave
                            • Nicholas Cancelliere
                              Anything that is published, and can have a finger pointed at it, becomes this way. Look it says right here on page 33 that you must do step X before step
                              Message 14 of 20 , May 9, 2007
                              • 0 Attachment
                                 
                                Anything that is "published," and can have a finger pointed at it, becomes this way.  "Look it says right here on page 33 that you must do step X before step Y."  Even though that might not work for your organization -- you'll get people who are more comfortable with the scapegoat.
                                 
                                People stop thinking for themselves and instead look for something to tell them the solution.  Then accountability is rationalized away because, well -- "I was just doing what it says to in the book for this situation!"
                                 
                                ...religion comes to mind when I think of this concept.
                                 
                                Nicholas


                                 
                                On 5/3/07, Ken Schwaber <ken.schwaber@...> wrote:

                                Absolutely … the best guides are all of the books that have been published over the years, such as risk management. The moment it becomes a guide it becomes stepwise and restrictive, in my experience.

                                Ken

                                 


                                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroup s.com] On Behalf Of srinivas chillara
                                Sent: Thursday, May 03, 2007 12:37 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: Re: [scrumdevelopment] Re: Scrum Vs Prince2

                                 

                                > I've noticed that sometimes people
                                > criticize Scrum
                                > because it omits methodological details; as I see
                                > it, that's a
                                > strength of Scrum, not a weakness.

                                Agreed.

                                However, Don't you think a projecgt management
                                cookbook, or guide etc, could be useful!?!
                                (here I am not criticising what you've written below,
                                I'm just wondering).
                                >If someone is
                                > just looking for a
                                > project management cookbook, then they may find
                                > Scrum doesn't give
                                > them enough specific guidance for their needs.

                                The traditional C-and-C means of executing projects
                                (in an IT setting) must be having something in value
                                for us. Maynot be the general Command and control
                                approach, but some aspects. Maybe the way QC is set up
                                independantly, more likely risk management, etc.

                                Regards
                                Cheenie

                                Send a FREE SMS to your friend's mobile from Yahoo! Messenger. Get it now at http://in.messenger.yahoo.com/




                                --
                                Nicholas Cancelliere, Austin TX
                                "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
                              • Nicholas Cancelliere
                                When I read this thread I think of the Bible. There are people who interpret it literally and there are people who read it and come away with base concepts.
                                Message 15 of 20 , May 9, 2007
                                • 0 Attachment
                                   
                                  When I read this thread I think of the Bible.  There are people who interpret it literally and there are people who read it and come away with base concepts.  I think with any written "code" of anything you have to interpret the intent or spirit of the thing described and go from there.
                                   
                                  Why do we have judges if we just live exactly by the letter of the law?  They are there to help interpret the law - to decide on how to apply the concept it embodies to specific situations.  This concept applies to anything really -- think for yourself.
                                   
                                  As a good Scrummaster, I think it is our job to enable everyone to their best thinking.  I don't want to be some cult leader where everyone submits to my interpretation of Scrum.  Instead I present concepts and ideas embodied by Scrum and Agile -- and then let the team run with it. 
                                   
                                  The way we recognize a process as Scrum is by certain core practices, which we can't deviate from -- if we do then we arn't doing Scrum.   Is this bad?  Not necessarily ... if it works for the team.  I believe though that history is a great teacher, and there is no need to reinvent the wheel, and most "new" things a team dreams up actually have already been done and tried.  Stick with what historically has worked and then make adjustments based on your needs.
                                   
                                  I don't believe there is a "cookbook" approach.  In the past two years I've worked intimately with 4 different teams on implenting Scrum, and no two have been alike enough that I could "cookie cutter" an approach to adoption.
                                   
                                  Nicholas


                                   
                                  On 5/7/07, srinivas chillara <ceezone@...> wrote:

                                  > The moment
                                  > it becomes a guide it
                                  > becomes stepwise and restrictive, in my experience.


                                  Aha! But such guide, in hands of sublime experts, like
                                  yours truly, don't become restrictive. No one can say
                                  I am not cheeky.

                                  But seriously, I see what you are saying, once it is
                                  codified, it becomes restrictive, except for people
                                  who have participated in it's codification, or maybe
                                  the very few who truly "get it".

                                  Cheenie


                                  __________________________________________________________
                                  Yahoo! India Answers: Share what you know. Learn something new
                                  http://in.answers.yahoo.com/




                                  --
                                  Nicholas Cancelliere, Austin TX
                                  "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
                                • srinivas chillara
                                  ... Thanks very much. I agree very much with limiting guides to a page or two. Most of the process definitions I suggest are of that length. Yours
                                  Message 16 of 20 , May 9, 2007
                                  • 0 Attachment
                                    > I would also suggest that you make it a "living"
                                    > document and update
                                    > it after each retrospective or after "surprise"
                                    > lessons are learned. I
                                    > would further suggest that you never let the guide
                                    > grow beyond one
                                    > printed page in length. When you find you are just
                                    > about to add an
                                    > item that pushes the length over the one page limit,
                                    > review the
                                    > contents and look for items that can be removed.
                                    > This will help ensure
                                    > the guide remains relevant and useful while making
                                    > it possible to post
                                    > a copy on the wall of team rooms.
                                    >
                                    > >
                                    > > yours in doubt
                                    > > Cheenie
                                    > >
                                    >
                                    > Yours doubtlessly,
                                    > Dave

                                    Thanks very much. I agree very much with limiting
                                    guides to a page or two. Most of the process
                                    definitions I suggest are of that length.

                                    Yours no-longer-in-doubt
                                    Cheenie




                                    Office firewalls, cyber cafes, college labs, don't allow you to download CHAT? Click here: http://in.messenger.yahoo.com/webmessengerpromo.php
                                  Your message has been successfully submitted and would be delivered to recipients shortly.