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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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.