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

RE: [scrumdevelopment] monitoring bad SCRUM

Expand Messages
  • Mike Cohn
    Mike- At the worst case a sprint review meeting (held once a month at the end of the sprint) would uncover functionality that you thought was delivered but
    Message 1 of 25 , Apr 25, 2003
    • 0 Attachment

      Mike—

      At the worst case a sprint review meeting (held once a month at the end of the sprint) would uncover functionality that you thought was delivered but wasn’t. Even if the functionality isn’t of UI work it can still be demonstrated at a Sprint Review. There may be details that aren’t visible in any way but not that many per sprint. I was in a sprint review earlier this week that demonstrated new functionality for users to import bulk data into the database. There was no UI yet we still demo’d that part of the back-end system. Additionally, even if one deceptive programmer lies in the daily scrum meetings the lies should be caught by a tester on the team. If the developer and tester collude to lie there’s nothing you can do until the sprint review but you will find out then.

       

      -Mike

       

      -----Original Message-----
      From: Mike [mailto:ezxs@...]
      Sent:
      Friday, April 25, 2003 1:51 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] monitoring bad SCRUM

       

      I have an interesting problem with SCRUM.   We do international project management and last year after persuasive talks by Dan Rawsthorne we have started using SCRUM.  It has been working out amazingly well.

       

      The last project we have started was handled by a new project manager and has had some bad results.  When we did a little analysis of why things went wrong we realized that it was mostly because we have learnt to just trust developer feedback on what has been done and what hasn’t been done.  When that feedback is accurate SCRUM works great, however when that feedback is misleading the backlog becomes worthless.

       

      In the meantime I have added other fields to the backlog:

       

      id

      Task description

      Original Effort Est.

      Left over effort estimate

      Dev (alias)

      PM (verified/unverified)

      QA (alias + status)

      1122

      Implement login dialog

      2

      0

      Ruben

      Roscoe: verified

      Sureva: Done with test pass

      1112

      Implement print functionality

      2

      2

      Ruben

      Roscoe:

      Sureva:

       

       

       

       

       

       

       

       

      Basically all we are trying to do it to make sure that PMs see that the feature is implemented to the spec and QA makes a pass on it before we sign of on something as being “DONE”

       

      Has anyone had this kind of experience?  I can see a big drawback with non GUI related stuff and the backend programming… but what are you fellow-scrummers doing when SCRUM goes bad?

       


      Mike Borozdin // IBE Corporation
      office:    425.990.4545
      cell:       206.850.3294
      msft:      425.705.6754

      web:      ibe-us.com

      The content of this e-mail is created only for viewing by the parties in the "To" and "CC" line.  The rights to forward or copy the text or attachment are explicitly withheld. The message is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use of provided information.

      (c) 2003 International Business Engineering Corporation. All rights reserved.

       

       



      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    • Mike
      Ok, great, so what I am hearing is that the extension of this log to have a tester and the PM sign off on the feature completion seems like a good addition.
      Message 2 of 25 , Apr 25, 2003
      • 0 Attachment

        Ok, great, so what I am hearing is that the extension of this log to have a tester and the PM sign off on the feature completion seems like a good addition.

         

        This problem is obviously not SCRUM specific, Waterfall approaches have a lot more loopholes where people can inadvertently (or not J ) misrepresent their progress.  However I think SCRUM might offer an opportunity to address this problem a lot better due to the binary state of the tasks.

         

        The components obviously do not have to be GUI.  The backend components should have unit tests in which case the GUI is the JUnit or cutest J.

         

        Regards,

                    Mike.

         

        -----Original Message-----
        From: Mike Cohn [mailto:mike@...]
        Sent: Friday, April 25, 2003 5:30 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: RE: [scrumdevelopment] monitoring bad SCRUM

         

        Mike—

        At the worst case a sprint review meeting (held once a month at the end of the sprint) would uncover functionality that you thought was delivered but wasn’t. Even if the functionality isn’t of UI work it can still be demonstrated at a Sprint Review. There may be details that aren’t visible in any way but not that many per sprint. I was in a sprint review earlier this week that demonstrated new functionality for users to import bulk data into the database. There was no UI yet we still demo’d that part of the back-end system. Additionally, even if one deceptive programmer lies in the daily scrum meetings the lies should be caught by a tester on the team. If the developer and tester collude to lie there’s nothing you can do until the sprint review but you will find out then.

         

        -Mike

         

        -----Original Message-----
        From: Mike [mailto:ezxs@...]
        Sent: Friday, April 25, 2003 1:51 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] monitoring bad SCRUM

         

        I have an interesting problem with SCRUM.   We do international project management and last year after persuasive talks by Dan Rawsthorne we have started using SCRUM.  It has been working out amazingly well.

         

        The last project we have started was handled by a new project manager and has had some bad results.  When we did a little analysis of why things went wrong we realized that it was mostly because we have learnt to just trust developer feedback on what has been done and what hasn’t been done.  When that feedback is accurate SCRUM works great, however when that feedback is misleading the backlog becomes worthless.

         

        In the meantime I have added other fields to the backlog:

         

        id

        Task description

        Original Effort Est.

        Left over effort estimate

        Dev (alias)

        PM (verified/unverified)

        QA (alias + status)

        1122

        Implement login dialog

        2

        0

        Ruben

        Roscoe: verified

        Sureva: Done with test pass

        1112

        Implement print functionality

        2

        2

        Ruben

        Roscoe:

        Sureva:

         

         

         

         

         

         

         

         

        Basically all we are trying to do it to make sure that PMs see that the feature is implemented to the spec and QA makes a pass on it before we sign of on something as being “DONE”

         

        Has anyone had this kind of experience?  I can see a big drawback with non GUI related stuff and the backend programming… but what are you fellow-scrummers doing when SCRUM goes bad?

         


        Mike Borozdin // IBE Corporation
        office:    425.990.4545
        cell:       206.850.3294
        msft:      425.705.6754

        web:      ibe-us.com

        The content of this e-mail is created only for viewing by the parties in the "To" and "CC" line.  The rights to forward or copy the text or attachment are explicitly withheld. The message is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use of provided information.

        (c) 2003 International Business Engineering Corporation. All rights reserved.

         

         

         

        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      • Mike Cohn
        In general I don$B!G(Bt know that I like the idea of signing things off-that always delays things as people are reluctant to put their name on a dotted line.
        Message 3 of 25 , Apr 25, 2003
        • 0 Attachment

          In general I don’t know that I like the idea of signing things off—that always delays things as people are reluctant to put their name on a dotted line.

           

          Could you instead gather the equivalent information during the daily scrum? For example,

           

          “Great, Mary. I’m glad to hear you finished the XYZ task. Do we have tests for it? Are they part of the test suite we run on the nightly build?”

           

          If there are No answers to any of that, add a task to the sprint backlog task list. Add the end if you still have “Test XYZ” as a task you know that programming XYZ isn’t really done either. (Programming can never be done till the testing is done.)

           

          -Mike

           

          -----Original Message-----
          From: Mike [mailto:ezxs@...]
          Sent: Friday, April 25, 2003 6:55 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] monitoring bad SCRUM

           

          Ok, great, so what I am hearing is that the extension of this log to have a tester and the PM sign off on the feature completion seems like a good addition.

           

          This problem is obviously not SCRUM specific, Waterfall approaches have a lot more loopholes where people can inadvertently (or not J ) misrepresent their progress.  However I think SCRUM might offer an opportunity to address this problem a lot better due to the binary state of the tasks.

           

          The components obviously do not have to be GUI.  The backend components should have unit tests in which case the GUI is the JUnit or cutest J.

           

          Regards,

                      Mike.

           

          -----Original Message-----
          From: Mike Cohn [mailto:mike@...]
          Sent: Friday, April 25, 2003 5:30 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] monitoring bad SCRUM

           

          Mike—

          At the worst case a sprint review meeting (held once a month at the end of the sprint) would uncover functionality that you thought was delivered but wasn’t. Even if the functionality isn’t of UI work it can still be demonstrated at a Sprint Review. There may be details that aren’t visible in any way but not that many per sprint. I was in a sprint review earlier this week that demonstrated new functionality for users to import bulk data into the database. There was no UI yet we still demo’d that part of the back-end system. Additionally, even if one deceptive programmer lies in the daily scrum meetings the lies should be caught by a tester on the team. If the developer and tester collude to lie there’s nothing you can do until the sprint review but you will find out then.

           

          -Mike

           

          -----Original Message-----
          From: Mike [mailto:ezxs@...]
          Sent: Friday, April 25, 2003 1:51 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] monitoring bad SCRUM

           

          I have an interesting problem with SCRUM.   We do international project management and last year after persuasive talks by Dan Rawsthorne we have started using SCRUM.  It has been working out amazingly well.

           

          The last project we have started was handled by a new project manager and has had some bad results.  When we did a little analysis of why things went wrong we realized that it was mostly because we have learnt to just trust developer feedback on what has been done and what hasn’t been done.  When that feedback is accurate SCRUM works great, however when that feedback is misleading the backlog becomes worthless.

           

          In the meantime I have added other fields to the backlog:

           

          id

          Task description

          Original Effort Est.

          Left over effort estimate

          Dev (alias)

          PM (verified/unverified)

          QA (alias + status)

          1122

          Implement login dialog

          2

          0

          Ruben

          Roscoe: verified

          Sureva: Done with test pass

          1112

          Implement print functionality

          2

          2

          Ruben

          Roscoe:

          Sureva:

           

           

           

           

           

           

           

           

          Basically all we are trying to do it to make sure that PMs see that the feature is implemented to the spec and QA makes a pass on it before we sign of on something as being “DONE”

           

          Has anyone had this kind of experience?  I can see a big drawback with non GUI related stuff and the backend programming… but what are you fellow-scrummers doing when SCRUM goes bad?

           


          Mike Borozdin // IBE Corporation
          office:    425.990.4545
          cell:       206.850.3294
          msft:      425.705.6754

          web:      ibe-us.com

          The content of this e-mail is created only for viewing by the parties in the "To" and "CC" line.  The rights to forward or copy the text or attachment are explicitly withheld. The message is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use of provided information.

          (c) 2003 International Business Engineering Corporation. All rights reserved.

           

           

           

          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

          Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


          Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


          Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
        • Clarke Ching
          Hi Mike, Why do you think the developers gave incorrect feedback (or lied)? Did they not trust the new PM? Clarke Ching Scotland ... From: Mike
          Message 4 of 25 , Apr 25, 2003
          • 0 Attachment
            Hi Mike,
             
            Why do you think the developers gave incorrect feedback (or lied)? 
             
            Did they not trust the new PM? 
             
            Clarke Ching
            Scotland
            -----Original Message-----
            From: Mike [mailto:ezxs@...]
            Sent: 25 April 2003 20:51
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] monitoring bad SCRUM

            I have an interesting problem with SCRUM.   We do international project management and last year after persuasive talks by Dan Rawsthorne we have started using SCRUM.  It has been working out amazingly well.

             

            The last project we have started was handled by a new project manager and has had some bad results.  When we did a little analysis of why things went wrong we realized that it was mostly because we have learnt to just trust developer feedback on what has been done and what hasn’t been done.  When that feedback is accurate SCRUM works great, however when that feedback is misleading the backlog becomes worthless.

             

            In the meantime I have added other fields to the backlog:

             

            id

            Task description

            Original Effort Est.

            Left over effort estimate

            Dev (alias)

            PM (verified/unverified)

            QA (alias + status)

            1122

            Implement login dialog

            2

            0

            Ruben

            Roscoe: verified

            Sureva: Done with test pass

            1112

            Implement print functionality

            2

            2

            Ruben

            Roscoe:

            Sureva:

             

             

             

             

             

             

             

             

            Basically all we are trying to do it to make sure that PMs see that the feature is implemented to the spec and QA makes a pass on it before we sign of on something as being “DONE”

             

            Has anyone had this kind of experience?  I can see a big drawback with non GUI related stuff and the backend programming… but what are you fellow-scrummers doing when SCRUM goes bad?

             


            Mike Borozdin // IBE Corporation
            office:    425.990.4545
            cell:       206.850.3294
            msft:      425.705.6754

            web:      ibe-us.com

            The content of this e-mail is created only for viewing by the parties in the "To" and "CC" line.  The rights to forward or copy the text or attachment are explicitly withheld. The message is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use of provided information.

            (c) 2003 International Business Engineering Corporation. All rights reserved.

             

             



            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          • Mike
            I don t really know why people gave incorrect feedback. I don t believe anyone purposefully plans on lying. There could be several reasons for it: sometimes
            Message 5 of 25 , Apr 26, 2003
            • 0 Attachment

              I don’t really know why people gave incorrect feedback.  I don’t believe anyone purposefully plans on lying.  There could be several reasons for it: sometimes people feel pressured to show progress, sometimes they just feel like they are so close to completion of a certain feature set that they say “I am done” at the SCRUM meeting, some people just don’t go to the level of detail of implementation as they are supposed to.  For example if you have to have a login dialog with a help tool tip the developer might say: “yeah it’s done”, but the tooltip isn’t there.

               

              Different cultures treat bad results very differently too.  In US speaking out about your roadblocks is encouraged.  When we deal with some of our Asian partners we have to literally extract the bad information out of the personnel.  I don’t know if there are any grounds/justification for generalizations, so I am not going to make them.  That was just my experience so far.

               

                          Mike.

               

              -----Original Message-----
              From: Clarke Ching [mailto:clarke.ching@...]
              Sent
              :
              Friday, April 25, 2003 11:54 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: RE: [scrumdevelopment] monitoring bad SCRUM

               

              Hi Mike,

               

              Why do you think the developers gave incorrect feedback (or lied)? 

               

              Did they not trust the new PM? 

               

              Clarke Ching

              Scotland

              -----Original Message-----
              From: Mike [mailto:ezxs@...]
              Sent:
              25 April 2003 20:51
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] monitoring bad SCRUM

              I have an interesting problem with SCRUM.   We do international project management and last year after persuasive talks by Dan Rawsthorne we have started using SCRUM.  It has been working out amazingly well.

               

              The last project we have started was handled by a new project manager and has had some bad results.  When we did a little analysis of why things went wrong we realized that it was mostly because we have learnt to just trust developer feedback on what has been done and what hasn’t been done.  When that feedback is accurate SCRUM works great, however when that feedback is misleading the backlog becomes worthless.

               

              In the meantime I have added other fields to the backlog:

               

              id

              Task description

              Original Effort Est.

              Left over effort estimate

              Dev (alias)

              PM (verified/unverified)

              QA (alias + status)

              1122

              Implement login dialog

              2

              0

              Ruben

              Roscoe: verified

              Sureva: Done with test pass

              1112

              Implement print functionality

              2

              2

              Ruben

              Roscoe:

              Sureva:

               

               

               

               

               

               

               

               

              Basically all we are trying to do it to make sure that PMs see that the feature is implemented to the spec and QA makes a pass on it before we sign of on something as being “DONE”

               

              Has anyone had this kind of experience?  I can see a big drawback with non GUI related stuff and the backend programming… but what are you fellow-scrummers doing when SCRUM goes bad?

               


              Mike Borozdin // IBE Corporation
              office:    425.990.4545
              cell:       206.850.3294
              msft:      425.705.6754

              web:      ibe-us.com

              The content of this e-mail is created only for viewing by the parties in the "To" and "CC" line.  The rights to forward or copy the text or attachment are explicitly withheld. The message is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use of provided information.

              (c) 2003 International Business Engineering Corporation. All rights reserved.

               

               



              To Post a message, send it to:   scrumdevelopment@...
              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



              To Post a message, send it to:   scrumdevelopment@...
              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            • Deb
              I have seen this also: colleagues who have the hardest time to raise a red flag when problems cause delays. In my experience they are also, often, among the
              Message 6 of 25 , Apr 27, 2003
              • 0 Attachment
                I have seen this also: colleagues who have the hardest time to "raise
                a red flag" when problems cause delays. In my experience they are
                also, often, among the most diligent and quality-conscious workers on
                the team.

                Now I'm of the loud-mouth variety, and it's easy for me to say "I've
                uncovered a problem, and I need another half day". But I'm wondering
                if there are any people reading this who find the declaration of
                roadblocks difficult, and if they could tell us how this feels from
                their point of view?

                Does Scrum depend on a team's acceptance/adoption of a communication
                paradigm that is uncomfortable for some personalities or cultures? If
                so, is there a way to adapt it so all can participate fruitfully?
                Those with good experiences in this area: your comments would be
                helpful to us.

                OK, you quiet people, now is your chance to tell the loud people your
                side of things!

                deb

                --- In scrumdevelopment@yahoogroups.com, "Mike" <ezxs@f...> wrote:
                > I don't really know why people gave incorrect feedback. I don't
                believe
                > anyone purposefully plans on lying. There could be several reasons
                for
                > it: sometimes people feel pressured to show progress, sometimes they
                > just feel like they are so close to completion of a certain feature
                set
                > that they say "I am done" at the SCRUM meeting, some people just
                don't
                > go to the level of detail of implementation as they are supposed to.
                > For example if you have to have a login dialog with a help tool tip
                the
                > developer might say: "yeah it's done", but the tooltip isn't there.
                >
                > Different cultures treat bad results very differently too. In US
                > speaking out about your roadblocks is encouraged. When we deal with
                > some of our Asian partners we have to literally extract the bad
                > information out of the personnel. I don't know if there are any
                > grounds/justification for generalizations, so I am not going to make
                > them. That was just my experience so far.
                >
                > Mike.
                >
                > -----Original Message-----
                > From: Clarke Ching [mailto:clarke.ching@f...]
                > Sent: Friday, April 25, 2003 11:54 PM
                > To: scrumdevelopment@yahoogroups.com
                > Subject: RE: [scrumdevelopment] monitoring bad SCRUM
                >
                > Hi Mike,
                >
                > Why do you think the developers gave incorrect feedback (or lied)?
                >
                > Did they not trust the new PM?
                >
                > Clarke Ching
                > Scotland
                > -----Original Message-----
                > From: Mike [mailto:ezxs@f...]
                > Sent: 25 April 2003 20:51
                > To: scrumdevelopment@yahoogroups.com
                > Subject: [scrumdevelopment] monitoring bad SCRUM
                > I have an interesting problem with SCRUM. We do international
                project
                > management and last year after persuasive talks by Dan Rawsthorne we
                > have started using SCRUM. It has been working out amazingly well.
                >
                > The last project we have started was handled by a new project
                manager
                > and has had some bad results. When we did a little analysis of why
                > things went wrong we realized that it was mostly because we have
                learnt
                > to just trust developer feedback on what has been done and what
                hasn't
                > been done. When that feedback is accurate SCRUM works great,
                however
                > when that feedback is misleading the backlog becomes worthless.
                >
                > In the meantime I have added other fields to the backlog:
                >
                >
                > id
                > Task description
                > Original Effort Est.
                > Left over effort estimate
                > Dev (alias)
                > PM (verified/unverified)
                > QA (alias + status)
                >
                > 1122
                > Implement login dialog
                > 2
                > 0
                > Ruben
                > Roscoe: verified
                > Sureva: Done with test pass
                >
                > 1112
                > Implement print functionality
                > 2
                > 2
                > Ruben
                > Roscoe:
                > Sureva:
                >
                >
                >
                >
                >
                >
                >
                >
                >
                > Basically all we are trying to do it to make sure that PMs see that
                the
                > feature is implemented to the spec and QA makes a pass on it before
                we
                > sign of on something as being "DONE"
                >
                > Has anyone had this kind of experience? I can see a big drawback
                with
                > non GUI related stuff and the backend programming. but what are you
                > fellow-scrummers doing when SCRUM goes bad?
                >
                >
                > _____
                >
                > Mike Borozdin // IBE Corporation
                > office: 425.990.4545
                > cell: 206.850.3294
                > msft: 425.705.6754
                > web: <http://ibe-us.com> ibe-us.com
                > The content of this e-mail is created only for viewing by the
                parties in
                > the "To" and "CC" line. The rights to forward or copy the text or
                > attachment are explicitly withheld. The message is provided "AS IS"
                with
                > no warranties, and confers no rights. You assume all risk for your
                use
                > of provided information.
                > (c) 2003 International Business Engineering Corporation. All rights
                > reserved.
                >
                >
                >
                >
                > To Post a message, send it to: scrumdevelopment@e...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@e...
                >
                > Your use of Yahoo! Groups is subject to the Yahoo!
                > <http://docs.yahoo.com/info/terms/> Terms of Service.
                >
                >
                >
                >
                > Yahoo! Groups Sponsor
                >
                >
                >
                >
                >
                <http://rd.yahoo.com/M=247865.3003379.4507215.2595810/D=egroupweb/S=17
                07
                > 209021:HM/A=1482387/R=0/*http:/ads.x10.com/?
                bHlhaG9vaG0xLmRhd=1051340044
                > %
                3eM=247865.3003379.4507215.2595810/D=egroupweb/S=1707209021:HM/A=14823
                8
                > 7/R=1=1051340044%
                3eM=247865.3003379.4507215.2595810/D=egroupweb/S=170720
                > 9021:HM/A=1482387/R=2>
                >
                >
                > <http://us.adserver.yahoo.com/l?
                M=247865.3003379.4507215.2595810/D=egrou
                > pmail/S=:HM/A=1482387/rand=956146690>
                >
                > To Post a message, send it to: scrumdevelopment@e...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@e...
                >
                > Your use of Yahoo! Groups is subject to the Yahoo!
                > <http://docs.yahoo.com/info/terms/> Terms of Service.
              • Mike Cohn
                The daily scrum helps protect against this. Even if I don t want to admit I m having troubles with task A it is hard for me to hide that for long. a) Either I
                Message 7 of 25 , Apr 27, 2003
                • 0 Attachment
                  The daily scrum helps protect against this. Even if I don't want to admit
                  I'm having troubles with task A it is hard for me to hide that for long.

                  a) Either I stay on it for a long time and someone in a Scrum meeting asks,
                  "Weren't you supposed to be done with that 3 weeks ago?"
                  b) Or, I move onto other tasks, leaving task A unfinished but telling the
                  team it's done. Whoever is on the team doing testing will notice this or it
                  will come up at the sprint review.
                  c) Or, I code something that works in 95% of the cases and is good enough to
                  pass tests but as soon as a real user gets it they'll start to find all the
                  problems and fixing them will be a major effort.

                  Option (c) can happen with any process. If the result of the sprint is given
                  to users to at least experiment with then they'll find it at the end of the
                  sprint so it goes undetected for 30 days or so at most. The built-in
                  inspection processes of Scrum will help with help identify (a) or (b) if
                  they're tried.

                  -Mike

                  -----Original Message-----
                  From: Deb [mailto:deborah@...]
                  Sent: Sunday, April 27, 2003 1:46 PM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: [scrumdevelopment] Culture clash - was - Re: monitoring bad SCRUM

                  I have seen this also: colleagues who have the hardest time to "raise
                  a red flag" when problems cause delays. In my experience they are
                  also, often, among the most diligent and quality-conscious workers on
                  the team.

                  Now I'm of the loud-mouth variety, and it's easy for me to say "I've
                  uncovered a problem, and I need another half day". But I'm wondering
                  if there are any people reading this who find the declaration of
                  roadblocks difficult, and if they could tell us how this feels from
                  their point of view?

                  Does Scrum depend on a team's acceptance/adoption of a communication
                  paradigm that is uncomfortable for some personalities or cultures? If
                  so, is there a way to adapt it so all can participate fruitfully?
                  Those with good experiences in this area: your comments would be
                  helpful to us.

                  OK, you quiet people, now is your chance to tell the loud people your
                  side of things!

                  deb

                  --- In scrumdevelopment@yahoogroups.com, "Mike" <ezxs@f...> wrote:
                  > I don't really know why people gave incorrect feedback. I don't
                  believe
                  > anyone purposefully plans on lying. There could be several reasons
                  for
                  > it: sometimes people feel pressured to show progress, sometimes they
                  > just feel like they are so close to completion of a certain feature
                  set
                  > that they say "I am done" at the SCRUM meeting, some people just
                  don't
                  > go to the level of detail of implementation as they are supposed to.
                  > For example if you have to have a login dialog with a help tool tip
                  the
                  > developer might say: "yeah it's done", but the tooltip isn't there.
                  >
                  > Different cultures treat bad results very differently too. In US
                  > speaking out about your roadblocks is encouraged. When we deal with
                  > some of our Asian partners we have to literally extract the bad
                  > information out of the personnel. I don't know if there are any
                  > grounds/justification for generalizations, so I am not going to make
                  > them. That was just my experience so far.
                  >
                  > Mike.
                  >
                  > -----Original Message-----
                  > From: Clarke Ching [mailto:clarke.ching@f...]
                  > Sent: Friday, April 25, 2003 11:54 PM
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: RE: [scrumdevelopment] monitoring bad SCRUM
                  >
                  > Hi Mike,
                  >
                  > Why do you think the developers gave incorrect feedback (or lied)?
                  >
                  > Did they not trust the new PM?
                  >
                  > Clarke Ching
                  > Scotland
                  > -----Original Message-----
                  > From: Mike [mailto:ezxs@f...]
                  > Sent: 25 April 2003 20:51
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: [scrumdevelopment] monitoring bad SCRUM
                  > I have an interesting problem with SCRUM. We do international
                  project
                  > management and last year after persuasive talks by Dan Rawsthorne we
                  > have started using SCRUM. It has been working out amazingly well.
                  >
                  > The last project we have started was handled by a new project
                  manager
                  > and has had some bad results. When we did a little analysis of why
                  > things went wrong we realized that it was mostly because we have
                  learnt
                  > to just trust developer feedback on what has been done and what
                  hasn't
                  > been done. When that feedback is accurate SCRUM works great,
                  however
                  > when that feedback is misleading the backlog becomes worthless.
                  >
                  > In the meantime I have added other fields to the backlog:
                  >
                  >
                  > id
                  > Task description
                  > Original Effort Est.
                  > Left over effort estimate
                  > Dev (alias)
                  > PM (verified/unverified)
                  > QA (alias + status)
                  >
                  > 1122
                  > Implement login dialog
                  > 2
                  > 0
                  > Ruben
                  > Roscoe: verified
                  > Sureva: Done with test pass
                  >
                  > 1112
                  > Implement print functionality
                  > 2
                  > 2
                  > Ruben
                  > Roscoe:
                  > Sureva:
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  > Basically all we are trying to do it to make sure that PMs see that
                  the
                  > feature is implemented to the spec and QA makes a pass on it before
                  we
                  > sign of on something as being "DONE"
                  >
                  > Has anyone had this kind of experience? I can see a big drawback
                  with
                  > non GUI related stuff and the backend programming. but what are you
                  > fellow-scrummers doing when SCRUM goes bad?
                  >
                  >
                  > _____
                  >
                  > Mike Borozdin // IBE Corporation
                  > office: 425.990.4545
                  > cell: 206.850.3294
                  > msft: 425.705.6754
                  > web: <http://ibe-us.com> ibe-us.com
                  > The content of this e-mail is created only for viewing by the
                  parties in
                  > the "To" and "CC" line. The rights to forward or copy the text or
                  > attachment are explicitly withheld. The message is provided "AS IS"
                  with
                  > no warranties, and confers no rights. You assume all risk for your
                  use
                  > of provided information.
                  > (c) 2003 International Business Engineering Corporation. All rights
                  > reserved.
                  >
                  >
                  >
                  >
                  > To Post a message, send it to: scrumdevelopment@e...
                  > To Unsubscribe, send a blank message to:
                  > scrumdevelopment-unsubscribe@e...
                  >
                  > Your use of Yahoo! Groups is subject to the Yahoo!
                  > <http://docs.yahoo.com/info/terms/> Terms of Service.
                  >
                  >
                  >
                  >
                  > Yahoo! Groups Sponsor
                  >
                  >
                  >
                  >
                  >
                  <http://rd.yahoo.com/M=247865.3003379.4507215.2595810/D=egroupweb/S=17
                  07
                  > 209021:HM/A=1482387/R=0/*http:/ads.x10.com/?
                  bHlhaG9vaG0xLmRhd=1051340044
                  > %
                  3eM=247865.3003379.4507215.2595810/D=egroupweb/S=1707209021:HM/A=14823
                  8
                  > 7/R=1=1051340044%
                  3eM=247865.3003379.4507215.2595810/D=egroupweb/S=170720
                  > 9021:HM/A=1482387/R=2>
                  >
                  >
                  > <http://us.adserver.yahoo.com/l?
                  M=247865.3003379.4507215.2595810/D=egrou
                  > pmail/S=:HM/A=1482387/rand=956146690>
                  >
                  > To Post a message, send it to: scrumdevelopment@e...
                  > To Unsubscribe, send a blank message to:
                  > scrumdevelopment-unsubscribe@e...
                  >
                  > Your use of Yahoo! Groups is subject to the Yahoo!
                  > <http://docs.yahoo.com/info/terms/> Terms of Service.



                  To Post a message, send it to: scrumdevelopment@...
                  To Unsubscribe, send a blank message to:
                  scrumdevelopment-unsubscribe@...

                  Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                • Dean Goodmanson
                  ... workers ... In light of Seek help only when you ve exhausted all your resources , that statement was something I m glad to see articulated. Mike Cohn s
                  Message 8 of 25 , Apr 28, 2003
                  • 0 Attachment
                    > I have seen this also: colleagues who have the
                    > hardest time to "raise a red flag" when problems
                    > cause delays. In my experience they are also, often,

                    > among the most diligent and quality-conscious
                    workers
                    > on the team.

                    In light of "Seek help only when you've exhausted all
                    your resources", that statement was something I'm glad
                    to see articulated.

                    Mike Cohn's response sums up my hopes for Scrum
                    improving this situation. Few want to risk be
                    perceived as a nay-sayer or chicken little, and Scrums
                    discussion opening Scrum meeting mixed with intense
                    team work seems like it would reduce the amount of
                    cave time for developers and support communication.
                    As the daily meetings are stand-up and not a weekly
                    status meeting, working out questions and problems in
                    a seperate 2-3 person meeting should also help the
                    person feel off-the-spot. The remainder of the team
                    can then truly expect "no [immediate] news is good
                    news" and a follow-up at tomorows meeting.

                    - Dean
                    http://sqr.pycs.net

                    --- Deb <deborah@...> wrote:
                    > I have seen this also: colleagues who have the
                    > hardest time to "raise
                    > a red flag" when problems cause delays. In my
                    > experience they are
                    > also, often, among the most diligent and
                    > quality-conscious workers on
                    > the team.
                    >
                    > Now I'm of the loud-mouth variety, and it's easy for
                    > me to say "I've
                    > uncovered a problem, and I need another half day".
                    > But I'm wondering
                    > if there are any people reading this who find the
                    > declaration of
                    > roadblocks difficult, and if they could tell us how
                    > this feels from
                    > their point of view?
                    >
                    > Does Scrum depend on a team's acceptance/adoption of
                    > a communication
                    > paradigm that is uncomfortable for some
                    > personalities or cultures? If
                    > so, is there a way to adapt it so all can
                    > participate fruitfully?
                    > Those with good experiences in this area: your
                    > comments would be
                    > helpful to us.
                    >
                    > OK, you quiet people, now is your chance to tell the
                    > loud people your
                    > side of things!
                    >
                    > deb
                    >
                    > --- In scrumdevelopment@yahoogroups.com, "Mike"
                    > <ezxs@f...> wrote:
                    > > I don't really know why people gave incorrect
                    > feedback. I don't
                    > believe
                    > > anyone purposefully plans on lying. There could
                    > be several reasons
                    > for
                    > > it: sometimes people feel pressured to show
                    > progress, sometimes they
                    > > just feel like they are so close to completion of
                    > a certain feature
                    > set
                    > > that they say "I am done" at the SCRUM meeting,
                    > some people just
                    > don't
                    > > go to the level of detail of implementation as
                    > they are supposed to.
                    > > For example if you have to have a login dialog
                    > with a help tool tip
                    > the
                    > > developer might say: "yeah it's done", but the
                    > tooltip isn't there.
                    > >
                    > > Different cultures treat bad results very
                    > differently too. In US
                    > > speaking out about your roadblocks is encouraged.
                    > When we deal with
                    > > some of our Asian partners we have to literally
                    > extract the bad
                    > > information out of the personnel. I don't know if
                    > there are any
                    > > grounds/justification for generalizations, so I am
                    > not going to make
                    > > them. That was just my experience so far.
                    > >
                    > > Mike.
                    > >
                    > > -----Original Message-----
                    > > From: Clarke Ching [mailto:clarke.ching@f...]
                    > > Sent: Friday, April 25, 2003 11:54 PM
                    > > To: scrumdevelopment@yahoogroups.com
                    > > Subject: RE: [scrumdevelopment] monitoring bad
                    > SCRUM
                    > >
                    > > Hi Mike,
                    > >
                    > > Why do you think the developers gave incorrect
                    > feedback (or lied)?
                    > >
                    > > Did they not trust the new PM?
                    > >
                    > > Clarke Ching
                    > > Scotland
                    > > -----Original Message-----
                    > > From: Mike [mailto:ezxs@f...]
                    > > Sent: 25 April 2003 20:51
                    > > To: scrumdevelopment@yahoogroups.com
                    > > Subject: [scrumdevelopment] monitoring bad SCRUM
                    > > I have an interesting problem with SCRUM. We do
                    > international
                    > project
                    > > management and last year after persuasive talks by
                    > Dan Rawsthorne we
                    > > have started using SCRUM. It has been working out
                    > amazingly well.
                    > >
                    > > The last project we have started was handled by a
                    > new project
                    > manager
                    > > and has had some bad results. When we did a
                    > little analysis of why
                    > > things went wrong we realized that it was mostly
                    > because we have
                    > learnt
                    > > to just trust developer feedback on what has been
                    > done and what
                    > hasn't
                    > > been done. When that feedback is accurate SCRUM
                    > works great,
                    > however
                    > > when that feedback is misleading the backlog
                    > becomes worthless.
                    > >
                    > > In the meantime I have added other fields to the
                    > backlog:
                    > >
                    > >
                    > > id
                    > > Task description
                    > > Original Effort Est.
                    > > Left over effort estimate
                    > > Dev (alias)
                    > > PM (verified/unverified)
                    > > QA (alias + status)
                    > >
                    > > 1122
                    > > Implement login dialog
                    > > 2
                    > > 0
                    > > Ruben
                    > > Roscoe: verified
                    > > Sureva: Done with test pass
                    > >
                    > > 1112
                    > > Implement print functionality
                    > > 2
                    > > 2
                    > > Ruben
                    > > Roscoe:
                    > > Sureva:
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > > Basically all we are trying to do it to make sure
                    > that PMs see that
                    > the
                    > > feature is implemented to the spec and QA makes a
                    > pass on it before
                    > we
                    > > sign of on something as being "DONE"
                    > >
                    > > Has anyone had this kind of experience? I can see
                    > a big drawback
                    > with
                    > > non GUI related stuff and the backend programming.
                    > but what are you
                    > > fellow-scrummers doing when SCRUM goes bad?
                    > >
                    > >
                    > > _____
                    > >
                    > > Mike Borozdin // IBE Corporation
                    > > office: 425.990.4545
                    > > cell: 206.850.3294
                    > > msft: 425.705.6754
                    > > web: <http://ibe-us.com> ibe-us.com
                    > > The content of this e-mail is created only for
                    > viewing by the
                    > parties in
                    > > the "To" and "CC" line. The rights to forward or
                    > copy the text or
                    > > attachment are explicitly withheld. The message is
                    > provided "AS IS"
                    > with
                    > > no warranties, and confers no rights. You assume
                    > all risk for your
                    > use
                    > > of provided information.
                    > > (c) 2003 International Business Engineering
                    > Corporation. All rights
                    > > reserved.
                    > >
                    > >
                    > >
                    > >
                    > > To Post a message, send it to:
                    > scrumdevelopment@e...
                    > > To Unsubscribe, send a blank message to:
                    > > scrumdevelopment-unsubscribe@e...
                    > >
                    >
                    === message truncated ===


                    __________________________________
                    Do you Yahoo!?
                    The New Yahoo! Search - Faster. Easier. Bingo.
                    http://search.yahoo.com
                  • Hal Macomber
                    I m wondering about the experience people have with pair programming. I would guess there would be less of a problem raising the flag . First, with two
                    Message 9 of 25 , Apr 28, 2003
                    • 0 Attachment

                      I'm wondering about the experience people have with pair programming.  I would guess there would be less of a problem 'raising the flag'.  First, with two people on a task they would be more likely to work through the problem.  Second, with two people each individual is already getting help.  Asking for some more time or more help looks like a small step for the pair to take.  What is your experience?? 

                       Dean Goodmanson <goodmansond@...> wrote:

                      > I have seen this also: colleagues who have the
                      > hardest time to "raise a red flag" when problems
                      > cause delays. In my experience they are also, often,

                      > among the most diligent and quality-conscious
                      workers
                      > on the team.

                      In light of "Seek help only when you've exhausted all
                      your resources", that statement was something I'm glad
                      to see articulated.

                      Mike Cohn's response sums up my hopes for Scrum
                      improving this situation.  Few want to risk be
                      perceived as a nay-sayer or chicken little, and Scrums
                      discussion opening Scrum meeting mixed with intense
                      team work seems like it would reduce the amount of
                      cave time for developers and support communication. 
                      As the daily meetings are stand-up and not a weekly
                      status meeting, working out questions and problems in
                      a seperate 2-3 person meeting should also help the
                      person feel off-the-spot.  The remainder of the team
                      can then truly expect "no [immediate] news is good
                      news" and a follow-up at tomorows meeting.

                      - Dean
                      http://sqr.pycs.net

                      --- Deb <deborah@...> wrote:
                      > I have seen this also: colleagues who have the
                      > hardest time to "raise
                      > a red flag" when problems cause delays. In my
                      > experience they are
                      > also, often, among the most diligent and
                      > quality-conscious workers on
                      > the team.
                      >
                      > Now I'm of the loud-mouth variety, and it's easy for
                      > me to say "I've
                      > uncovered a problem, and I need another half day".
                      > But I'm wondering
                      > if there are any people reading this who find the
                      > declaration of
                      > roadblocks difficult, and if they could tell us how
                      > this feels from
                      > their point of view?
                      >
                      > Does Scrum depend on a team's acceptance/adoption of
                      > a communication
                      > paradigm that is uncomfortable for some
                      > personalities or cultures? If
                      > so, is there a way to adapt it so all can
                      > participate fruitfully?
                      > Those with good experiences in this area: your
                      > comments would be
                      > helpful to us.
                      >
                      > OK, you quiet people, now is your chance to tell the
                      > loud people your
                      > side of things!
                      >
                      > deb
                      >
                      > --- In scrumdevelopment@yahoogroups.com, "Mike"
                      > <ezxs@f...> wrote:
                      > > I don't really know why people gave incorrect
                      > feedback.  I don't
                      > believe
                      > > anyone purposefully plans on lying.  There could
                      > be several reasons
                      > for
                      > > it: sometimes people feel pressured to show
                      > progress, sometimes they
                      > > just feel like they are so close to completion of
                      > a certain feature
                      > set
                      > > that they say "I am done" at the SCRUM meeting,
                      > some people just
                      > don't
                      > > go to the level of detail of implementation as
                      > they are supposed to.
                      > > For example if you have to have a login dialog
                      > with a help tool tip
                      > the
                      > > developer might say: "yeah it's done", but the
                      > tooltip isn't there.
                      > > 
                      > > Different cultures treat bad results very
                      > differently too.  In US
                      > > speaking out about your roadblocks is encouraged.
                      > When we deal with
                      > > some of our Asian partners we have to literally
                      > extract the bad
                      > > information out of the personnel.  I don't know if
                      > there are any
                      > > grounds/justification for generalizations, so I am
                      > not going to make
                      > > them.  That was just my experience so far.
                      > > 
                      > >             Mike.
                      > >


                      Subscribe to Reforming Project Management
                      Enter your email address:

                      Don't miss a posting! Forward to a friend.
                    • Ron Jeffries
                      ... I wonder whether seek help the moment it might improve your situation would be a better rule to live by. Ron Jeffries www.XProgramming.com It is a bad
                      Message 10 of 25 , Apr 28, 2003
                      • 0 Attachment
                        On Monday, April 28, 2003, at 8:18:59 AM, Dean Goodmanson wrote:

                        > In light of "Seek help only when you've exhausted all
                        > your resources", that statement was something I'm glad
                        > to see articulated.

                        I wonder whether "seek help the moment it might improve your situation"
                        would be a better rule to live by.

                        Ron Jeffries
                        www.XProgramming.com
                        It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
                      • Ron Jeffries
                        ... As I become more and more familiar with a particular pair, I m more and more ready to express confusion or ignorance the moment I notice it. I get more and
                        Message 11 of 25 , Apr 28, 2003
                        • 0 Attachment
                          On Monday, April 28, 2003, at 8:48:41 AM, Hal Macomber wrote:

                          > I'm wondering about the experience people have with pair programming. I would guess there
                          > would be less of a problem 'raising the flag'. First, with two people on a task they would
                          > be more likely to work through the problem. Second, with two people each individual is
                          > already getting help. Asking for some more time or more help looks like a small step for the
                          > pair to take. What is your experience??

                          As I become more and more familiar with a particular pair, I'm more and
                          more ready to express confusion or ignorance the moment I notice it. I get
                          more and more used to his gentle reminders "semicolon", or "do we need a
                          test".

                          And I get more and more comfortable expressing my confusion and ignorance
                          even with a new pair. And even in other places where I might feel the need
                          to seem like I know everything. <humor type="dubious">Of course, since I do
                          know /nearly/ everything, this skill is of limited use, but I was thinking
                          that for actual mortals, it could be really good.</humor>

                          But seriously. Help is good. The more I get, the more I give, the better I
                          do.

                          Ron Jeffries
                          www.XProgramming.com
                          No one expects the Spanish Inquisition ...
                        • Mike Beedle
                          ... True, but I would argue that the combination of Daily Scrums, Pairing, Continuous Integration, Daily Build, Unit Tests, and Acceptance Tests, make it
                          Message 12 of 25 , Apr 28, 2003
                          • 0 Attachment
                            --- Mike Cohn <mike@...> wrote:
                            > The daily scrum helps protect against this. Even
                            > if I don't want to admit I'm having troubles
                            > with task A it is hard for me to hide that for long.

                            True, but I would argue that the combination of
                            Daily Scrums, Pairing, Continuous Integration,
                            Daily Build, Unit Tests, and Acceptance Tests,
                            make it _impossible_ to hide any troubles whatsoever.


                            --- Mike Cohn <mike@...> wrote:
                            > a) Either I stay on it for a long time and
                            > someone in a Scrum meeting asks, "Weren't you
                            > supposed to be done with that 3 weeks ago?"

                            In Scrum you can't lie. If you say you were
                            supposed to be done 3 weeks ago, the team will
                            notice within the first 24 hrs. and the team
                            will react _immediately_ to it because your pair
                            will notice that you didn't work on this, your
                            unit tests won't pass, the build won't have the
                            functionality, the customer will notice he/she
                            can't acceptance test it, etc.

                            So it will be _very hard_ to go unnoticed.

                            But that's the whole premise of Scrum -- nothing
                            will go unmonitored for extended periods of time
                            i.e. (> t 24).

                            --- Mike Cohn <mike@...> wrote:
                            > b) Or, I move onto other tasks, leaving task A
                            > unfinished but telling the team it's done.

                            This will not happen in Scrum because _everyone_
                            will notice the expected functionality:

                            * is not passing unit tests
                            * is not in configuration management
                            * is not in the build
                            * can't be acceptance tested
                            * etc.

                            _even_ if it is reported as done in the Daily Scrums.



                            --- Mike Cohn <mike@...> wrote:
                            > Whoever is on the team doing testing will
                            > notice this or it will come up at the sprint
                            > review.

                            In Scrum _everyone_ will be doing testing every
                            day:

                            - the developers will be doing unit testing
                            - the developers will be doing automated
                            acceptance testing
                            - the customer/stakeholders will be doing automated/
                            non-automated acceptance testing and giving
                            continuous feedback

                            --- Mike Cohn <mike@...> wrote:
                            > c) Or, I code something that works in 95% of
                            > the cases and is good enough to pass tests ..

                            Hopefully something working at 95% won't pass
                            100% of the tests ;-) -- or else we might have the
                            wrong tests.

                            --- Mike Cohn <mike@...> wrote:
                            > but as soon as a real user gets it they'll
                            > start to find all the problems and fixing them
                            > will be a major effort.

                            --- Mike Cohn <mike@...> wrote:
                            > If the result of the sprint is given
                            > to users to at least experiment with then
                            > they'll find it at the end of the
                            > sprint so it goes undetected for 30 days or
                            > so at most.

                            I would say that the Scrum practices will ensure
                            that none of the above _ever_ happens,

                            -Mike
                          • Mike Cohn
                            I disagree but only in the subtle cases. If I m charged with writing a piece of code and work with a pair to do it we may get it to a certain point that my
                            Message 13 of 25 , Apr 28, 2003
                            • 0 Attachment
                              I disagree but only in the subtle cases. If I'm charged with writing a piece
                              of code and work with a pair to do it we may get it to a certain point that
                              my pair thinks it's done and it appears done because it passes QA's tests.
                              Yet, I'm aware of some subtle times when it will fail and I don't bring them
                              up because I don't want to rewrite that area. For example, long ago I
                              remember writing code for an interactive voice response system and there
                              were lots of intricate rules about when to add various elements to the phone
                              number (country code, area, 1+0, etc.). Most international numbers followed
                              the same rules. I don't remember the specifics but there were a few
                              occasions where international dialing was a little different. If I had been
                              pairing with someone I could have hidden my knowledge of that and QA
                              wouldn't have found it either. It is possible to hide some unfinished work.
                              I don't think any process can prevent this type of behavior.

                              -Mike

                              -----Original Message-----
                              From: Mike Beedle [mailto:beedlem@...]
                              Sent: Monday, April 28, 2003 8:40 AM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: RE: [scrumdevelopment] Culture clash - was - Re: monitoring bad
                              SCRUM


                              --- Mike Cohn <mike@...> wrote:
                              > The daily scrum helps protect against this. Even
                              > if I don't want to admit I'm having troubles
                              > with task A it is hard for me to hide that for long.

                              True, but I would argue that the combination of
                              Daily Scrums, Pairing, Continuous Integration,
                              Daily Build, Unit Tests, and Acceptance Tests,
                              make it _impossible_ to hide any troubles whatsoever.


                              --- Mike Cohn <mike@...> wrote:
                              > a) Either I stay on it for a long time and
                              > someone in a Scrum meeting asks, "Weren't you
                              > supposed to be done with that 3 weeks ago?"

                              In Scrum you can't lie. If you say you were
                              supposed to be done 3 weeks ago, the team will
                              notice within the first 24 hrs. and the team
                              will react _immediately_ to it because your pair
                              will notice that you didn't work on this, your
                              unit tests won't pass, the build won't have the
                              functionality, the customer will notice he/she
                              can't acceptance test it, etc.

                              So it will be _very hard_ to go unnoticed.

                              But that's the whole premise of Scrum -- nothing
                              will go unmonitored for extended periods of time
                              i.e. (> t 24).

                              --- Mike Cohn <mike@...> wrote:
                              > b) Or, I move onto other tasks, leaving task A
                              > unfinished but telling the team it's done.

                              This will not happen in Scrum because _everyone_
                              will notice the expected functionality:

                              * is not passing unit tests
                              * is not in configuration management
                              * is not in the build
                              * can't be acceptance tested
                              * etc.

                              _even_ if it is reported as done in the Daily Scrums.



                              --- Mike Cohn <mike@...> wrote:
                              > Whoever is on the team doing testing will
                              > notice this or it will come up at the sprint
                              > review.

                              In Scrum _everyone_ will be doing testing every
                              day:

                              - the developers will be doing unit testing
                              - the developers will be doing automated
                              acceptance testing
                              - the customer/stakeholders will be doing automated/
                              non-automated acceptance testing and giving
                              continuous feedback

                              --- Mike Cohn <mike@...> wrote:
                              > c) Or, I code something that works in 95% of
                              > the cases and is good enough to pass tests ..

                              Hopefully something working at 95% won't pass
                              100% of the tests ;-) -- or else we might have the
                              wrong tests.

                              --- Mike Cohn <mike@...> wrote:
                              > but as soon as a real user gets it they'll
                              > start to find all the problems and fixing them
                              > will be a major effort.

                              --- Mike Cohn <mike@...> wrote:
                              > If the result of the sprint is given
                              > to users to at least experiment with then
                              > they'll find it at the end of the
                              > sprint so it goes undetected for 30 days or
                              > so at most.

                              I would say that the Scrum practices will ensure
                              that none of the above _ever_ happens,

                              -Mike




                              To Post a message, send it to: scrumdevelopment@...
                              To Unsubscribe, send a blank message to:
                              scrumdevelopment-unsubscribe@...

                              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                            • Mike
                              Mike, While SCRUM makes misrepresentation of progress A LOT harder then any other project management methodology it can happen (or at least did happen to me
                              Message 14 of 25 , Apr 28, 2003
                              • 0 Attachment

                                Mike,

                                 

                                While SCRUM makes misrepresentation of progress A LOT harder then any other project management methodology it can happen (or at least did happen to me J).  If you refer to my previous e-mail I’d say that the problem is mostly the lack of detail or a binary state for a non-binary task i.e. a solution that makes 95% of the testcases pass.

                                 

                                Pairing would make things like that a lot harder to hide because in paired programming there is already a peer that sees the same problem as you do.  That makes it easier to voice the problem at the daily SCRUM.

                                 

                                A SCRUM master particular to detail and technically savvy is another way those situations are made less likely.  As a SCRUM master master unfortunately I am at their mercy a lot of times L.

                                 

                                I am going to see what additional fields to the backlog do and post the success/failure results to the list.

                                 

                                Regards,

                                            Mike.

                                 

                                -----Original Message-----
                                From: Mike Beedle [mailto:beedlem@...]
                                Sent
                                :
                                Monday, April 28, 2003 7:40 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] Culture clash - was - Re: monitoring bad SCRUM

                                 


                                --- Mike Cohn <mike@...> wrote:
                                > The daily scrum helps protect against this. Even
                                > if I don't want to admit I'm having troubles
                                > with task A it is hard for me to hide that for long.

                                True, but I would argue that the combination of
                                Daily Scrums, Pairing, Continuous Integration,
                                Daily Build, Unit Tests, and Acceptance Tests,
                                make it _impossible_ to hide any troubles whatsoever.


                                --- Mike Cohn <mike@...> wrote:
                                > a) Either I stay on it for a long time and
                                > someone in a Scrum meeting asks, "Weren't you
                                > supposed to be done with that 3 weeks ago?"

                                In Scrum you can't lie.  If you say you were
                                supposed to be done 3 weeks ago, the team will
                                notice within the first 24 hrs. and the team
                                will react _immediately_ to it because your pair
                                will notice that you didn't work on this, your
                                unit tests won't pass, the build won't have the
                                functionality, the customer will notice he/she
                                can't acceptance test it, etc. 

                                So it will be _very hard_ to go unnoticed.

                                But that's the whole premise of Scrum -- nothing
                                will go unmonitored for extended periods of time
                                i.e. (> t  24).

                                --- Mike Cohn <mike@...> wrote:
                                > b) Or, I move onto other tasks, leaving task A
                                > unfinished but telling the team it's done.

                                This will not happen in Scrum because _everyone_
                                will notice the expected functionality:

                                * is not passing unit tests
                                * is not in configuration management
                                * is not in the build
                                * can't be acceptance tested
                                * etc.

                                _even_ if it is reported as done in the Daily Scrums.



                                --- Mike Cohn <mike@...> wrote:
                                > Whoever is on the team doing testing will
                                > notice this or it will come up at the sprint
                                > review.

                                In Scrum _everyone_ will be doing testing every
                                day:

                                  - the developers will be doing unit testing
                                  - the developers will be doing automated
                                    acceptance testing
                                  - the customer/stakeholders will be doing automated/
                                    non-automated acceptance testing and giving
                                    continuous feedback

                                --- Mike Cohn <mike@...> wrote:
                                > c) Or, I code something that works in 95% of
                                > the cases and is good enough to pass tests ..

                                Hopefully something working at 95% won't pass
                                100% of the tests ;-) -- or else we might have the
                                wrong tests.

                                --- Mike Cohn <mike@...> wrote:
                                > but as soon as a real user gets it they'll
                                > start to find all the problems and fixing them
                                > will be a major effort.

                                --- Mike Cohn <mike@...> wrote:
                                > If the result of the sprint is given
                                > to users to at least experiment with then
                                > they'll find it at the end of the
                                > sprint so it goes undetected for 30 days or
                                > so at most.

                                I would say that the Scrum practices will ensure
                                that none of the above _ever_ happens,

                                -Mike




                                To Post a message, send it to:   scrumdevelopment@...
                                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


                                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                              • Hal Macomber
                                So all of what you say seems possible -- for some period of time. And it is true that people lie, shade the truth, and leave out important details. If we are
                                Message 15 of 25 , Apr 28, 2003
                                • 0 Attachment

                                  So all of what you say seems possible -- for some period of time.  And it is true that people lie, shade the truth, and leave out important details.  If we are talking about criminal behavior -- intent to deceive for some personal gain -- then we know what to do: get rid of the team member.  But I have found people behave this way out of frustration that work isn't proceeding the way they want, embarassment that they can't perform as expected, resignation with some aspect of the project, etc.  The only thing I've seen to overcome the power of those moods is having ownership in the successful outcome of the project.

                                  Some people argue that of course my team members are committed to the success of the project.   However the behaviors described in this thread are all too familiar.  We can't say that people demonstrating these behaviors take full ownership in success.  It is the project leader's responsibility to continue to engage team members as owners of the promise to the customer.  I say 'continue to engage' because the nature of our lives is that other things are always coming up -- the school play, the soccer match, our spouse's birthday, a more challenging assignment, a redirection of the project, abandonning code, etc. -- competing with the big commitments we've made.   Without explict acts of re-engaging ownership individuals and the team will eventually drift from their commitment.

                                  I've been directly involved with 30-40 software projects.  None were done on an agile basis.  For the last 4 years I have managed and consulted to organizations doing projects on a lean basis.  It seems to me the combination of Scrum practices with ongoing care for ownership will allow teams to avoid the isues identified.

                                   Mike Cohn <mike@...> wrote:

                                  I disagree but only in the subtle cases. If I'm charged with writing a piece
                                  of code and work with a pair to do it we may get it to a certain point that
                                  my pair thinks it's done and it appears done because it passes QA's tests.
                                  Yet, I'm aware of some subtle times when it will fail and I don't bring them
                                  up because I don't want to rewrite that area. For example, long ago I
                                  remember writing code for an interactive voice response system and there
                                  were lots of intricate rules about when to add various elements to the phone
                                  number (country code, area, 1+0, etc.). Most international numbers followed
                                  the same rules. I don't remember the specifics but there were a few
                                  occasions where international dialing was a little different. If I had been
                                  pairing with someone I could have hidden my knowledge of that and QA
                                  wouldn't have found it either. It is possible to hide some unfinished work.
                                  I don't think any process can prevent this type of behavior.

                                  -Mike

                                  -----Original Message-----
                                  From: Mike Beedle [mailto:beedlem@...]
                                  Sent: Monday, April 28, 2003 8:40 AM
                                  To: scrumdevelopment@yahoogroups.com
                                  Subject: RE: [scrumdevelopment] Culture clash - was - Re: monitoring bad
                                  SCRUM


                                  --- Mike Cohn <mike@...> wrote:
                                  > The daily scrum helps protect against this. Even
                                  > if I don't want to admit I'm having troubles
                                  > with task A it is hard for me to hide that for long.

                                  True, but I would argue that the combination of
                                  Daily Scrums, Pairing, Continuous Integration,
                                  Daily Build, Unit Tests, and Acceptance Tests,
                                  make it _impossible_ to hide any troubles whatsoever.


                                  --- Mike Cohn <mike@...> wrote:
                                  > a) Either I stay on it for a long time and
                                  > someone in a Scrum meeting asks, "Weren't you
                                  > supposed to be done with that 3 weeks ago?"

                                  In Scrum you can't lie.  If you say you were
                                  supposed to be done 3 weeks ago, the team will
                                  notice within the first 24 hrs. and the team
                                  will react _immediately_ to it because your pair
                                  will notice that you didn't work on this, your
                                  unit tests won't pass, the build won't have the
                                  functionality, the customer will notice he/she
                                  can't acceptance test it, etc. 

                                  So it will be _very hard_ to go unnoticed.

                                  But that's the whole premise of Scrum -- nothing
                                  will go unmonitored for extended periods of time
                                  i.e. (> t  24).

                                  --- Mike Cohn <mike@...> wrote:
                                  > b) Or, I move onto other tasks, leaving task A
                                  > unfinished but telling the team it's done.

                                  This will not happen in Scrum because _everyone_
                                  will notice the expected functionality:

                                  * is not passing unit tests
                                  * is not in configuration management
                                  * is not in the build
                                  * can't be acceptance tested
                                  * etc.

                                  _even_ if it is reported as done in the Daily Scrums.



                                  --- Mike Cohn <mike@...> wrote:
                                  > Whoever is on the team doing testing will
                                  > notice this or it will come up at the sprint
                                  > review.

                                  In Scrum _everyone_ will be doing testing every
                                  day:

                                    - the developers will be doing unit testing
                                    - the developers will be doing automated
                                      acceptance testing
                                    - the customer/stakeholders will be doing automated/
                                      non-automated acceptance testing and giving
                                      continuous feedback

                                  --- Mike Cohn <mike@...> wrote:
                                  > c) Or, I code something that works in 95% of
                                  > the cases and is good enough to pass tests ..

                                  Hopefully something working at 95% won't pass
                                  100% of the tests ;-) -- or else we might have the
                                  wrong tests.

                                  --- Mike Cohn <mike@...> wrote:
                                  > but as soon as a real user gets it they'll
                                  > start to find all the problems and fixing them
                                  > will be a major effort.

                                  --- Mike Cohn <mike@...> wrote:
                                  > If the result of the sprint is given
                                  > to users to at least experiment with then
                                  > they'll find it at the end of the
                                  > sprint so it goes undetected for 30 days or
                                  > so at most.

                                  I would say that the Scrum practices will ensure
                                  that none of the above _ever_ happens,

                                  -Mike


                                  Subscribe to Reforming Project Management
                                  Enter your email address:

                                  Don't miss a posting! Forward to a friend.
                                • Mike Cohn
                                  Good points, Hal. I think Scrum and XP do a better job of bringing these types of things to light than anything else I ve read about, seen or tried. I just
                                  Message 16 of 25 , Apr 28, 2003
                                  • 0 Attachment

                                    Good points, Hal.

                                     

                                    I think Scrum and XP do a better job of bringing these types of things to light than anything else I’ve read about, seen or tried. I just wanted to make the point that I can always hide some deficiency for a little while—either because I’m destructive or just embarrassed to bring it up.

                                     

                                    You’re point about “continue to engage” is a good one. I think a lot of agile projects overlook the role of a project manager in keeping a team motivated, having ownership and moving forward. One of my favorite books is “Teamwork” by Larson and LaFasto. They identify 8 things necessary to having a successful team, based on their research into all sorts of successful teams from a variety of domains. Number one on their list is a “clear, elevating goal.” The goal has to be something easily understood (“clear”) but also has to be motivating—“finish by June 30 or I’ll fire you” doesn’t qualify. An obvious clear, elevating goal was Kennedy’s “a man on the moon by the end of the decade.”  From the projects I’ve worked on I’d say that the lack of a clear, elevating goal is probably the best indicator that a project will fail. If the goal is clear and elevating teams will take the ownership you describe and move mountains. Unfortunately, I’d say the majority of projects (at least that I’ve seen, and maybe I’m just cursed) do not have clear, elevating goals.

                                     

                                    -Mike

                                     

                                    -----Original Message-----
                                    From: Hal Macomber [mailto:hal@...]
                                    Sent: Monday, April 28, 2003 9:23 AM
                                    To: scrumdevelopment@yahoogroups.com
                                    Subject: RE: [scrumdevelopment] Culture clash - was - Re: monitoring bad SCRUM

                                     

                                    So all of what you say seems possible -- for some period of time.  And it is true that people lie, shade the truth, and leave out important details.  If we are talking about criminal behavior -- intent to deceive for some personal gain -- then we know what to do: get rid of the team member.  But I have found people behave this way out of frustration that work isn't proceeding the way they want, embarassment that they can't perform as expected, resignation with some aspect of the project, etc.  The only thing I've seen to overcome the power of those moods is having ownership in the successful outcome of the project.

                                    Some people argue that of course my team members are committed to the success of the project.   However the behaviors described in this thread are all too familiar.  We can't say that people demonstrating these behaviors take full ownership in success.  It is the project leader's responsibility to continue to engage team members as owners of the promise to the customer.  I say 'continue to engage' because the nature of our lives is that other things are always coming up -- the school play, the soccer match, our spouse's birthday, a more challenging assignment, a redirection of the project, abandonning code, etc. -- competing with the big commitments we've made.   Without explict acts of re-engaging ownership individuals and the team will eventually drift from their commitment.

                                    I've been directly involved with 30-40 software projects.  None were done on an agile basis.  For the last 4 years I have managed and consulted to organizations doing projects on a lean basis.  It seems to me the combination of Scrum practices with ongoing care for ownership will allow teams to avoid the isues identified.

                                     Mike Cohn <mike@...> wrote:

                                    I disagree but only in the subtle cases. If I'm charged with writing a piece
                                    of code and work with a pair to do it we may get it to a certain point that
                                    my pair thinks it's done and it appears done because it passes QA's tests.
                                    Yet, I'm aware of some subtle times when it will fail and I don't bring them
                                    up because I don't want to rewrite that area. For example, long ago I
                                    remember writing code for an interactive voice response system and there
                                    were lots of intricate rules about when to add various elements to the phone
                                    number (country code, area, 1+0, etc.). Most international numbers followed
                                    the same rules. I don't remember the specifics but there were a few
                                    occasions where international dialing was a little different. If I had been
                                    pairing with someone I could have hidden my knowledge of that and QA
                                    wouldn't have found it either. It is possible to hide some unfinished work.
                                    I don't think any process can prevent this type of behavior.

                                    -Mike

                                    -----Original Message-----
                                    From: Mike Beedle [mailto:beedlem@...]
                                    Sent: Monday, April 28, 2003 8:40 AM
                                    To: scrumdevelopment@yahoogroups.com
                                    Subject: RE: [scrumdevelopment] Culture clash - was - Re: monitoring bad
                                    SCRUM


                                    --- Mike Cohn <mike@...> wrote:
                                    > The daily scrum helps protect against this. Even
                                    > if I don't want to admit I'm having troubles
                                    > with task A it is hard for me to hide that for long.

                                    True, but I would argue that the combination of
                                    Daily Scrums, Pairing, Continuous Integration,
                                    Daily Build, Unit Tests, and Acceptance Tests,
                                    make it _impossible_ to hide any troubles whatsoever.


                                    --- Mike Cohn <mike@...> wrote:
                                    > a) Either I stay on it for a long time and
                                    > someone in a Scrum meeting asks, "Weren't you
                                    > supposed to be done with that 3 weeks ago?"

                                    In Scr um you can't lie.  If you say you were
                                    supposed to be done 3 weeks ago, the team will
                                    notice within the first 24 hrs. and the team
                                    will react _immediately_ to it because your pair
                                    will notice that you didn't work on this, your
                                    unit tests won't pass, the build won't have the
                                    functionality, the customer will notice he/she
                                    can't acceptance test it, etc. 

                                    So it will be _very hard_ to go unnoticed.

                                    But that's the whole premise of Scrum -- nothing
                                    will go unmonitored for extended periods of time
                                    i.e. (> t  24).

                                    --- Mike Cohn <mike@...> wrote:
                                    > b) Or, I move onto other tasks, leaving task A
                                    > unfinished but telling the team it's done.

                                    This will not happen in Scrum because _everyone_
                                    will notice the expected functionality:

                                    * is not passing unit tests
                                    * is not in configuration management
                                    * is not in the build
                                    * can't be acceptance tested
                                    * etc.

                                    _even_ if it is reported as done in the Daily Scrums.



                                    --- Mike Cohn <mike@...> wrote:
                                    > Whoever is on the team doing testing will
                                    > notice this or it will come up at the sprint
                                    > review.

                                    In Scrum _everyone_ will be doing testing every
                                    day:

                                      - the developers will be doing unit testing
                                      - the developers will be doing automated
                                        acceptance testing
                                      - the customer/stakeholders will be doing automated/
                                        non-automated acceptance testing and giving
                                        continuous feedback

                                    --- Mike Cohn <mike@...> wrote:
                                    > c) Or, I code something that works in 95% of
                                    > the cases and is good enough to pass tests ..

                                    Hopefully something working at 95% won't pass
                                    100% of the tests ;-) -- or else we might have the
                                    wrong tests.

                                    --- Mike Cohn <mike@...> wrote:
                                    > but as soon as a real user gets it they'll
                                    & gt; start to find all the problems and fixing them
                                    > will be a major effort.

                                    --- Mike Cohn <mike@...> wrote:
                                    > If the result of the sprint is given
                                    > to users to at least experiment with then
                                    > they'll find it at the end of the
                                    > sprint so it goes undetected for 30 days or
                                    > so at most.

                                    I would say that the Scrum practices will ensure
                                    that none of the above _ever_ happens,

                                    -Mike

                                     

                                    Subscribe to Reforming Project Management
                                    Enter your email address:

                                    Don't miss a posting! Forward to a friend.



                                    To Post a message, send it to:   scrumdevelopment@...
                                    To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


                                    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                  • Hal Macomber
                                    I like Ron s articulation of the rule, Seek help the moment it might improve your situation. I ve written about my frustration with a programmer who
                                    Message 17 of 25 , Apr 28, 2003
                                    • 0 Attachment

                                      I like Ron's articulation of the rule, "Seek help the moment it might improve your situation."  I've written about my frustration with a programmer who operated to the rule "Seek help only after you've consumed all the time budgeted."  He would say he wanted a 'fair shot' at solving the problem.  He wasn't nearly as smart as he thought he was, consequently he repeatedly introduced delays (and costs) in the project when he didn't check-in his code as expected or when his function wasn't ready for others.  The team eventually turned this guy around when they got him to understand he put the whole project at risk.  They were not able to express the rule as cleanly as stated below.  Their rule was "Seek help when your promise is at risk."  Of course that took making the assessment of risk.  I like this one better.

                                       Ron Jeffries <ronjeffries@...> wrote:

                                      On Monday, April 28, 2003, at 8:18:59 AM, Dean Goodmanson wrote:

                                      > In light of "Seek help only when you've exhausted all
                                      > your resources", that statement was something I'm glad
                                      > to see articulated.

                                      I wonder whether "seek help the moment it might improve your situation"
                                      would be a better rule to live by.

                                      Ron Jeffries
                                      www.XProgramming.com
                                      It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)


                                      Subscribe to Reforming Project Management
                                      Enter your email address:

                                      Don't miss a posting! Forward to a friend.
                                    • Mike Cohn
                                      It undoubtedly would but that is so hard to get people to do. I try to encourage people to get to the point where they feel they ve asked for help too early as
                                      Message 18 of 25 , Apr 28, 2003
                                      • 0 Attachment
                                        It undoubtedly would but that is so hard to get people to do. I try to
                                        encourage people to get to the point where they feel they've asked for help
                                        too early as often as they ask for help too late. (Rather than 1% too early,
                                        99% too late, which is more common for too many developers.)

                                        -Mike

                                        -----Original Message-----
                                        From: Ron Jeffries [mailto:ronjeffries@...]
                                        Sent: Monday, April 28, 2003 8:00 AM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: Re: [scrumdevelopment] Culture clash - was - Re: monitoring bad
                                        SCRUM

                                        On Monday, April 28, 2003, at 8:18:59 AM, Dean Goodmanson wrote:

                                        > In light of "Seek help only when you've exhausted all
                                        > your resources", that statement was something I'm glad
                                        > to see articulated.

                                        I wonder whether "seek help the moment it might improve your situation"
                                        would be a better rule to live by.

                                        Ron Jeffries
                                        www.XProgramming.com
                                        It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42
                                        BCE)



                                        To Post a message, send it to: scrumdevelopment@...
                                        To Unsubscribe, send a blank message to:
                                        scrumdevelopment-unsubscribe@...

                                        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                      • Mike Cohn
                                        Ron-- I m surprised and disappointed by the nearly. That shakes my whole worldview. :) -Mike ... From: Ron Jeffries [mailto:ronjeffries@acm.org] Sent:
                                        Message 19 of 25 , Apr 28, 2003
                                        • 0 Attachment
                                          Ron--
                                          I'm surprised and disappointed by the "nearly." That shakes my whole
                                          worldview. :)

                                          -Mike

                                          -----Original Message-----
                                          From: Ron Jeffries [mailto:ronjeffries@...]
                                          Sent: Monday, April 28, 2003 8:04 AM
                                          To: scrumdevelopment@yahoogroups.com
                                          Subject: Re: [scrumdevelopment] Culture clash - was - Re: monitoring bad
                                          SCRUM

                                          On Monday, April 28, 2003, at 8:48:41 AM, Hal Macomber wrote:

                                          > I'm wondering about the experience people have with pair programming. I
                                          would guess there
                                          > would be less of a problem 'raising the flag'. First, with two people on
                                          a task they would
                                          > be more likely to work through the problem. Second, with two people each
                                          individual is
                                          > already getting help. Asking for some more time or more help looks like a
                                          small step for the
                                          > pair to take. What is your experience??

                                          As I become more and more familiar with a particular pair, I'm more and
                                          more ready to express confusion or ignorance the moment I notice it. I get
                                          more and more used to his gentle reminders "semicolon", or "do we need a
                                          test".

                                          And I get more and more comfortable expressing my confusion and ignorance
                                          even with a new pair. And even in other places where I might feel the need
                                          to seem like I know everything. <humor type="dubious">Of course, since I do
                                          know /nearly/ everything, this skill is of limited use, but I was thinking
                                          that for actual mortals, it could be really good.</humor>

                                          But seriously. Help is good. The more I get, the more I give, the better I
                                          do.

                                          Ron Jeffries
                                          www.XProgramming.com
                                          No one expects the Spanish Inquisition ...



                                          To Post a message, send it to: scrumdevelopment@...
                                          To Unsubscribe, send a blank message to:
                                          scrumdevelopment-unsubscribe@...

                                          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                        • Hal Macomber
                                          This pair programming thing has tremendous potential as a model for design and engineering work of all types. As we near deadlines my partner and I default to
                                          Message 20 of 25 , Apr 28, 2003
                                          • 0 Attachment

                                            This pair programming thing has tremendous potential as a model for design and engineering work of all types.  As we near deadlines my partner and I default to it as we prepare proposals to clients.  I see architects skip the usual draw > redline >  re-draw process for a paired approach when they are in the field working out an issue of constructability.

                                            There may be an opportunity for the project coach.  <humor type="sarcasm">If they would just do what I know is good for them, then the project would be successful.</humor>  Pair coaching team members might uncover what could work.

                                            Hal

                                             Ron Jeffries <ronjeffries@...> wrote:

                                            On Monday, April 28, 2003, at 8:48:41 AM, Hal Macomber wrote:

                                            > I'm wondering about the experience people have with pair programming.  I would guess there
                                            > would be less of a problem 'raising the flag'.  First, with two people on a task they would
                                            > be more likely to work through the problem.  Second, with two people each individual is
                                            > already getting help.  Asking for some more time or more help looks like a small step for the
                                            > pair to take.  What is your experience??

                                            As I become more and more familiar with a particular pair, I'm more and
                                            more ready to express confusion or ignorance the moment I notice it. I get
                                            more and more used to his gentle reminders "semicolon", or "do we need a
                                            test".

                                            And I get more and more comfortable expressing my confusion and ignorance
                                            even with a new pair. And even in other places where I might feel the need
                                            to seem like I know everything. <humor type="dubious">Of course, since I do
                                            know /nearly/ everything, this skill is of limited use, but I was thinking
                                            that for actual mortals, it could be really good.</humor>

                                            But seriously. Help is good. The more I get, the more I give, the better I
                                            do.

                                            Ron Jeffries
                                            www.XProgramming.com
                                            No one expects the Spanish Inquisition ...


                                            Subscribe to Reforming Project Management
                                            Enter your email address:

                                            Don't miss a posting! Forward to a friend.
                                          • John Gilman
                                            Musings - What are some of the things that lead a developer to not seek help the moment it might improve the situation? 1. Poor sprint/project goal
                                            Message 21 of 25 , Apr 28, 2003
                                            • 0 Attachment
                                              Musings -

                                              What are some of the things that lead a developer to not "seek help
                                              the moment it might improve the situation?"

                                              1. Poor sprint/project goal alignment - This is the thing I struggle
                                              with more than anyother. Some developers want to build the perfect
                                              system. I don't want them to. I want them to build a very solid
                                              system as quickly as possible. It is stunningly hard to get everyone
                                              aligned. It is possible for someone to spend too much time trying to
                                              solve a problem because they are working with their head down, just
                                              trying to solve the problem and not seeing the bigger picture.

                                              2. Incompetence - There is only one solution.

                                              3. Fear - Big problem. Cultural issues can really effect this. If
                                              I tell a team, give me what you can by Date X and I can live with
                                              that, they often struggle with fear that on Date X they will get
                                              blasted for not getting everything done. Consequently, they work to
                                              hard on low value, hard problems. Only time and consistant
                                              management values can solve this.

                                              4. Inxeperience with seeking help early. Pair programming would
                                              probably help, but we don't do it. Daily standups do help. Having
                                              developers own tasks as a group as opposed to being assigned tasks by
                                              someone else may help.

                                              John



                                              --- In scrumdevelopment@yahoogroups.com, Hal Macomber <hal@h...>
                                              wrote:
                                              >
                                              > I like Ron's articulation of the rule, "Seek help the moment it
                                              might improve your situation." I've written about my frustration
                                              with a programmer who operated to the rule "Seek help only after
                                              you've consumed all the time budgeted." He would say he wanted
                                              a 'fair shot' at solving the problem. He wasn't nearly as smart as
                                              he thought he was, consequently he repeatedly introduced delays (and
                                              costs) in the project when he didn't check-in his code as expected or
                                              when his function wasn't ready for others. The team eventually
                                              turned this guy around when they got him to understand he put the
                                              whole project at risk. They were not able to express the rule as
                                              cleanly as stated below. Their rule was "Seek help when your promise
                                              is at risk." Of course that took making the assessment of risk. I
                                              like this one better.
                                              > Ron Jeffries <ronjeffries@a...> wrote:On Monday, April 28, 2003,
                                              at 8:18:59 AM, Dean Goodmanson wrote:
                                              >
                                              > > In light of "Seek help only when you've exhausted all
                                              > > your resources", that statement was something I'm glad
                                              > > to see articulated.
                                              >
                                              > I wonder whether "seek help the moment it might improve your
                                              situation"
                                              > would be a better rule to live by.
                                              >
                                              > Ron Jeffries
                                              > www.XProgramming.com
                                              > It is a bad plan that admits of no modifications. -- Publius Syrus
                                              (ca. 42 BCE)
                                              >
                                              > [input] Subscribe to Reforming Project Management
                                              > Enter your email address:
                                              > [input] [input]
                                              > Don't miss a posting! Forward to a friend.
                                            • Ron Jeffries
                                              ... Think how dull life would be if there were nothing else to learn. The road to Mastery is long -- especially from where I seem to be standing at the moment.
                                              Message 22 of 25 , Apr 28, 2003
                                              • 0 Attachment
                                                On Monday, April 28, 2003, at 12:57:19 PM, Mike Cohn wrote:

                                                > I'm surprised and disappointed by the "nearly." That shakes my whole
                                                > worldview. :)

                                                Think how dull life would be if there were nothing else to learn.

                                                The road to Mastery is long -- especially from where I seem to be standing
                                                at the moment. ;->

                                                Ron Jeffries
                                                www.XProgramming.com
                                                Knowledge must come through action;
                                                you can have no test which is not fanciful, save by trial. -- Sophocles
                                              • Mike Cohn
                                                On #1, it s been my experience that this is almost universal with recent college graduates. My theory is that they are used to every professor grading them
                                                Message 23 of 25 , Apr 28, 2003
                                                • 0 Attachment
                                                  On #1, it's been my experience that this is almost universal with recent
                                                  college graduates. My theory is that they are used to every professor
                                                  grading them independently. I can't go to my Physics prof and say "I was
                                                  busy with Chemistry homework all weekend and did a great job on that so
                                                  please factor that in when you grade me." Each professor evaluates them
                                                  independently so they are accustomed to having to do A quality work for
                                                  each. That carries over into how they view their work for a manager. But,
                                                  you're right--not every task on a project needs A-quality work. Some things
                                                  just need to be done. (They can't, perhaps, be done poorly; but doing them
                                                  overly well is unnecessary.) I used to work with someone who frequently
                                                  said, "The perfect is the enemy of the good," which is a good way to think
                                                  about it.

                                                  As for #3, the team will usually respond better (take more ownership) if
                                                  they pick what they do by the date, rather than it being told to them. But,
                                                  of course, that's fundamental to Scrum.

                                                  -Mike

                                                  -----Original Message-----
                                                  From: John Gilman [mailto:jpgilman@...]
                                                  Sent: Monday, April 28, 2003 11:02 AM
                                                  To: scrumdevelopment@yahoogroups.com
                                                  Subject: [scrumdevelopment] Culture clash - was - Re: monitoring bad SCRUM

                                                  Musings -

                                                  What are some of the things that lead a developer to not "seek help
                                                  the moment it might improve the situation?"

                                                  1. Poor sprint/project goal alignment - This is the thing I struggle
                                                  with more than anyother. Some developers want to build the perfect
                                                  system. I don't want them to. I want them to build a very solid
                                                  system as quickly as possible. It is stunningly hard to get everyone
                                                  aligned. It is possible for someone to spend too much time trying to
                                                  solve a problem because they are working with their head down, just
                                                  trying to solve the problem and not seeing the bigger picture.

                                                  2. Incompetence - There is only one solution.

                                                  3. Fear - Big problem. Cultural issues can really effect this. If
                                                  I tell a team, give me what you can by Date X and I can live with
                                                  that, they often struggle with fear that on Date X they will get
                                                  blasted for not getting everything done. Consequently, they work to
                                                  hard on low value, hard problems. Only time and consistant
                                                  management values can solve this.

                                                  4. Inxeperience with seeking help early. Pair programming would
                                                  probably help, but we don't do it. Daily standups do help. Having
                                                  developers own tasks as a group as opposed to being assigned tasks by
                                                  someone else may help.

                                                  John



                                                  --- In scrumdevelopment@yahoogroups.com, Hal Macomber <hal@h...>
                                                  wrote:
                                                  >
                                                  > I like Ron's articulation of the rule, "Seek help the moment it
                                                  might improve your situation." I've written about my frustration
                                                  with a programmer who operated to the rule "Seek help only after
                                                  you've consumed all the time budgeted." He would say he wanted
                                                  a 'fair shot' at solving the problem. He wasn't nearly as smart as
                                                  he thought he was, consequently he repeatedly introduced delays (and
                                                  costs) in the project when he didn't check-in his code as expected or
                                                  when his function wasn't ready for others. The team eventually
                                                  turned this guy around when they got him to understand he put the
                                                  whole project at risk. They were not able to express the rule as
                                                  cleanly as stated below. Their rule was "Seek help when your promise
                                                  is at risk." Of course that took making the assessment of risk. I
                                                  like this one better.
                                                  > Ron Jeffries <ronjeffries@a...> wrote:On Monday, April 28, 2003,
                                                  at 8:18:59 AM, Dean Goodmanson wrote:
                                                  >
                                                  > > In light of "Seek help only when you've exhausted all
                                                  > > your resources", that statement was something I'm glad
                                                  > > to see articulated.
                                                  >
                                                  > I wonder whether "seek help the moment it might improve your
                                                  situation"
                                                  > would be a better rule to live by.
                                                  >
                                                  > Ron Jeffries
                                                  > www.XProgramming.com
                                                  > It is a bad plan that admits of no modifications. -- Publius Syrus
                                                  (ca. 42 BCE)
                                                  >
                                                  > [input] Subscribe to Reforming Project Management
                                                  > Enter your email address:
                                                  > [input] [input]
                                                  > Don't miss a posting! Forward to a friend.



                                                  To Post a message, send it to: scrumdevelopment@...
                                                  To Unsubscribe, send a blank message to:
                                                  scrumdevelopment-unsubscribe@...

                                                  Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                                Your message has been successfully submitted and would be delivered to recipients shortly.