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

Re: [scrumdevelopment] Scrum Vs Prince2

Expand Messages
  • Nicholas Cancelliere
    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
    Message 1 of 20 , May 1, 2007
    • 0 Attachment

      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
      His way of forcing the two together. The matrix that Mike referred to was not helpful, Ken _____ From: scrumdevelopment@yahoogroups.com
      Message 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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.