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

Why are you in favor of hand drawn burndown chart in a distributed world?

Expand Messages
  • Andrew Pham
    Hi Ron, I don t know if my reply to your question came through or not but just wonder why you guys are so against using a tool to store team info and generate
    Message 1 of 25 , Apr 3 11:29 AM
    • 0 Attachment
      Hi Ron,

      I don't know if my reply to your question came through or not but just wonder why you guys are so against using a tool to store team info and generate burndown charts for teams?

      I had drawn simple burndown chart a few years back but with software development becoming so distributed, either because of telecommuting or because of off-shoring, I wonder how practical this old practice is still after so many changes in the software development world?

      Is Agile or Scrum not about adapting to change itself?

      Regards,

      Andrew Pham
      Agile and Lean Coach, Author of Scrum in Action
      http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1

      On Sun, Apr 3, 2011 at 11:06 AM, <ronjeffries@...> wrote:
       

      Hello, Andrew,

      On Apr 3, 2011, at 11:16 AM, you wrote:

      > Rather than hand drawing the burndown chart, it will be best to get a cheap tool such as Greenhopper to have the chart automatically updated whenever you or your team log the time you spend working on your stories.
      >
      > Naturally if the project team is very small and everyone is located in the same room, then hand drawing is fine but having access to a tool is recommended since it more accurate and automatic.
      >
      > Just some suggestions from my coaching experience.

      What advantages do you see to this practice, which seems in conflict with the advice of other coaches? In particular, I'm interested in it's effect on team and individual engagement.

      R


    • Andrew Pham
      Ron, So if you are brought into a company as an Agile coach, like myself, and they say that their team members are distributed around the USA or the world, how
      Message 2 of 25 , Apr 3 12:08 PM
      • 0 Attachment
        Ron,

        So if you are brought into a company as an Agile coach, like myself, and they say that their team members are distributed around the USA or the world, how would you suggest to create the burndown chart for a project team? To have it drawn by hand? How then would you share it or have it updated by the team?

        Andrew Pham
        Agile and Lean Coach, Author of Scrum in Action
        http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1

        On Sun, Apr 3, 2011 at 1:49 PM, <ronjeffriesacm@...> wrote:

        As I see it, Scrum is about improving performance through improving practice, thus changing the situation, not about adapting to fit existing situations.

        R

        On Apr 3, 2011, at 2:29 PM, Andrew Pham <andrewpham74@...> wrote:

        > Is Agile or Scrum not about adapting to change itself?

      • Andrew Pham
        All the companies I have been coaching are distributed, whether is is all in the USA or around the world, but they are very much interested in Agile... Even
        Message 3 of 25 , Apr 3 1:04 PM
        • 0 Attachment
          All the companies I have been coaching are distributed, whether is is all in the USA or around the world, but they are very much interested in Agile...

          Even after we break the larger team into smaller teams, some of the team members are still not in the same location but the way we do thing (for instance, by using tool to create the burwndown chart, Agile and Scrum is still working and produce the expected results...

          Andrew Pham
          Agile and Lean Coach, Author of Scrum in Action
          http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1


          On Sun, Apr 3, 2011 at 2:48 PM, Ron Jeffries <ronjeffries@...> wrote:
          Hello, Andrew.  On Sunday, April 3, 2011, at 3:08:06 PM, you wrote:

          > So if you are brought into a company as an Agile coach, like myself, and
          > they say that their team members are distributed around the USA or the
          > world, how would you suggest to create the burndown chart for a project
          > team? To have it drawn by hand? How then would you share it or have it
          > updated by the team?

          First of all, a company that works that way is, in my experience,
          not very interested in doing anything Agile. So I might well prefer
          to spend my time elsewhere.

          That said, are all their programmers each in a different place? Or
          are they in small teams?

          Ron Jeffries
          www.XProgramming.com
          Do only what is necessary. Keep only what you need.


        • Charles Bradley - Scrum Coach CSM PSM I
          ... Draw Burndown by hand + Cameraphone + Email +1 to what George and Ron have said. ... Charles Bradley, CSM, PSM I Experienced Scrum Coach My blog:
          Message 4 of 25 , Apr 3 4:35 PM
          • 0 Attachment
            > they say that their team members are distributed around the USA or the
            world, how would you suggest to create the
            > burndown chart for a project
            team? To have it drawn by hand? How then would you share it or have it
            > updated by the team?

            Draw Burndown by hand + Cameraphone + Email

            +1 to what George and Ron have said.
             
            -------
            Charles Bradley, CSM, PSM I
            Experienced Scrum Coach
            My blog: http://scrumcrazy.wordpress.com/


          • George Dinwiddie
            ... Another option is to draw it in each location. It s a nice ceremony to end the daily standup. - George -- ... * George Dinwiddie *
            Message 5 of 25 , Apr 3 6:42 PM
            • 0 Attachment
              On 4/3/11 7:35 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:
              >
              >
              > > they say that their team members are distributed around the USA or
              > the world, how would you suggest to create the
              > > burndown chart for a project team? To have it drawn by hand? How then
              > would you share it or have it
              > > updated by the team?
              >
              > Draw Burndown by hand + Cameraphone + Email

              Another option is to draw it in each location. It's a nice ceremony to
              end the daily standup.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • Jack Milunsky
              The benefit of doing everything on the whiteboard is that everyone gets to see and interact as a team during the daily scrum as the burndown gets updated and
              Message 6 of 25 , Apr 3 7:10 PM
              • 0 Attachment
                The benefit of doing everything on the whiteboard is that everyone gets to see and interact as a team during the daily scrum as the burndown gets updated and the tasks/stories move. However if it's working for you using a tool go for it. There are many very successful teams using software tools.

                But I'd at least recommend that you start out doing things manually till you're really good at it.

                Jack
                blog.agilebuddy.com

                On Sun, Apr 3, 2011 at 2:29 PM, Andrew Pham <andrewpham74@...> wrote:
                 

                Hi Ron,

                I don't know if my reply to your question came through or not but just wonder why you guys are so against using a tool to store team info and generate burndown charts for teams?

                I had drawn simple burndown chart a few years back but with software development becoming so distributed, either because of telecommuting or because of off-shoring, I wonder how practical this old practice is still after so many changes in the software development world?

                Is Agile or Scrum not about adapting to change itself?

                Regards,

                Andrew Pham
                Agile and Lean Coach, Author of Scrum in Action
                http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1

                On Sun, Apr 3, 2011 at 11:06 AM, <ronjeffries@...> wrote:
                 

                Hello, Andrew,

                On Apr 3, 2011, at 11:16 AM, you wrote:

                > Rather than hand drawing the burndown chart, it will be best to get a cheap tool such as Greenhopper to have the chart automatically updated whenever you or your team log the time you spend working on your stories.
                >
                > Naturally if the project team is very small and everyone is located in the same room, then hand drawing is fine but having access to a tool is recommended since it more accurate and automatic.
                >
                > Just some suggestions from my coaching experience.

                What advantages do you see to this practice, which seems in conflict with the advice of other coaches? In particular, I'm interested in it's effect on team and individual engagement.

                R





                --
                Jack Milunsky
                Agilebuddy.com

                Cell: +1.416.302.5937
                E-mail: jack@...
                Web Site: www.agilebuddy.com
                Blog: blog.agilebuddy.com
                Twitter: twitter.com/agilebuddy

              • Silvana Wasitova
                Hi Andrew, Additional benefits of a physical taskboard (for co-located teams): 1. any team member can update the burndown, reduces dependency on ScrumMaster or
                Message 7 of 25 , Apr 4 3:09 AM
                • 0 Attachment
                  Hi Andrew,
                   
                  Additional benefits of a physical taskboard (for co-located teams):
                  1. any team member can update the burndown, reduces dependency on ScrumMaster or "the person holding the pen/tool".
                  2. during task estimation: task breakdown and writing can be done by several team members in parallel, then discussed, ordered and estimated one at a time by the Team.
                   
                  It is not that I am against use of tools, but as others have said:
                  it's good practice to first manually do that which later on you may wish to automate, so as to fully understand the process.
                   
                  And yes, when it comes to distributed teams, tools become a necessity to facilitate information sharing,
                  though even then, the "ideal solutions" vary from one team to another.
                   
                  Cheers,

                  --
                  Silvana Wasitova |  wasitova@... | Lausanne, Switzerland




                  From: Jack Milunsky <jack@...>
                   

                  The benefit of doing everything on the whiteboard is that everyone gets to see and interact as a team during the daily scrum as the burndown gets updated and the tasks/stories move. However if it's working for you using a tool go for it. There are many very successful teams using software tools.


                  But I'd at least recommend that you start out doing things manually till you're really good at it.

                  Jack
                  blog.agilebuddy.com

                  On Sun, Apr 3, 2011 at 2:29 PM, Andrew Pham <andrewpham74@...> wrote:
                   

                  Hi Ron,

                  I don't know if my reply to your question came through or not but just wonder why you guys are so against using a tool to store team info and generate burndown charts for teams?

                  I had drawn simple burndown chart a few years back but with software development becoming so distributed, either because of telecommuting or because of off-shoring, I wonder how practical this old practice is still after so many changes in the software development world?

                  Is Agile or Scrum not about adapting to change itself?

                  Regards,

                  Andrew Pham
                  Agile and Lean Coach, Author of Scrum in Action
                  http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1

                   
                • Stephen Palmer
                  The use of a tool can actually harm visibility; the need to open a tool or browse to a web-page to see a burn-down chart vs. seeing it on the wall every time
                  Message 8 of 25 , Apr 4 3:20 AM
                  • 0 Attachment
                    The use of a tool can actually harm visibility; the need to open a tool or browse to a web-page to see a burn-down chart vs. seeing it on the wall every time you walk to the coffee machine. Also, it is visible to people outside the project that may not have access to the tool/web-page. By all means, use a tool to produce the thing if that helps, but then print it out and post it up in each geographic location.


                    best

                    Steve

                    Stephen R. Palmer
                    Certified Scrum Practitioner 2009, FDD Associate, Coad-Certified Mentor


                    On 4 Apr 2011, at 11:09, Silvana Wasitova wrote:

                     

                    Hi Andrew,
                     
                    Additional benefits of a physical taskboard (for co-located teams):
                    1. any team member can update the burndown, reduces dependency on ScrumMaster or "the person holding the pen/tool".
                    2. during task estimation: task breakdown and writing can be done by several team members in parallel, then discussed, ordered and estimated one at a time by the Team.
                     
                    It is not that I am against use of tools, but as others have said:
                    it's good practice to first manually do that which later on you may wish to automate, so as to fully understand the process.
                     
                    And yes, when it comes to distributed teams, tools become a necessity to facilitate information sharing,
                    though even then, the "ideal solutions" vary from one team to another.
                     
                    Cheers,

                    --
                    Silvana Wasitova |  wasitova@... | Lausanne, Switzerland




                    From: Jack Milunsky <jack@...>
                     

                    The benefit of doing everything on the whiteboard is that everyone gets to see and interact as a team during the daily scrum as the burndown gets updated and the tasks/stories move. However if it's working for you using a tool go for it. There are many very successful teams using software tools.


                    But I'd at least recommend that you start out doing things manually till you're really good at it.

                    Jack
                    blog.agilebuddy.com

                    On Sun, Apr 3, 2011 at 2:29 PM, Andrew Pham <andrewpham74@...> wrote:
                     

                    Hi Ron,

                    I don't know if my reply to your question came through or not but just wonder why you guys are so against using a tool to store team info and generate burndown charts for teams?

                    I had drawn simple burndown chart a few years back but with software development becoming so distributed, either because of telecommuting or because of off-shoring, I wonder how practical this old practice is still after so many changes in the software development world?

                    Is Agile or Scrum not about adapting to change itself?

                    Regards,

                    Andrew Pham
                    Agile and Lean Coach, Author of Scrum in Action
                    http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1

                     


                  • Andrew Pham
                    Hi Silvana, Thank you for the nice feedback and thank you confirming that you also think that when it comes to distributed teams, tools become a necessity to
                    Message 9 of 25 , Apr 4 9:49 AM
                    • 0 Attachment
                      Hi Silvana,

                      Thank you for the nice feedback and thank you confirming that you also think that when it comes to distributed teams, tools become a necessity to facilitate information sharing...
                       
                      Regards,

                      Andrew Pham
                      Agile and Lean Coach, Author of Scrum in Action
                      http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1

                      On Mon, Apr 4, 2011 at 5:09 AM, Silvana Wasitova <wasitova@...> wrote:
                      Hi Andrew,
                       
                      Additional benefits of a physical taskboard (for co-located teams):
                      1. any team member can update the burndown, reduces dependency on ScrumMaster or "the person holding the pen/tool".
                      2. during task estimation: task breakdown and writing can be done by several team members in parallel, then discussed, ordered and estimated one at a time by the Team.
                       
                      It is not that I am against use of tools, but as others have said:
                      it's good practice to first manually do that which later on you may wish to automate, so as to fully understand the process.
                       
                      And yes, when it comes to distributed teams, tools become a necessity to facilitate information sharing,
                      though even then, the "ideal solutions" vary from one team to another.
                       
                      Cheers,

                      --
                      Silvana Wasitova |  wasitova@... | Lausanne, Switzerland




                      From: Jack Milunsky <jack@...>
                       

                      The benefit of doing everything on the whiteboard is that everyone gets to see and interact as a team during the daily scrum as the burndown gets updated and the tasks/stories move. However if it's working for you using a tool go for it. There are many very successful teams using software tools.


                      But I'd at least recommend that you start out doing things manually till you're really good at it.

                      Jack
                      blog.agilebuddy.com

                      On Sun, Apr 3, 2011 at 2:29 PM, Andrew Pham <andrewpham74@...> wrote:
                       

                      Hi Ron,

                      I don't know if my reply to your question came through or not but just wonder why you guys are so against using a tool to store team info and generate burndown charts for teams?

                      I had drawn simple burndown chart a few years back but with software development becoming so distributed, either because of telecommuting or because of off-shoring, I wonder how practical this old practice is still after so many changes in the software development world?

                      Is Agile or Scrum not about adapting to change itself?

                      Regards,

                      Andrew Pham
                      Agile and Lean Coach, Author of Scrum in Action
                      http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1

                       

                    • Charles Bradley - Scrum Coach CSM PSM I
                      ... This is a minor point, and while I don t consider it a bad practice, I do consider it a bad smell(which means it may or may not be a material problem). I
                      Message 10 of 25 , Apr 4 10:35 AM
                      • 0 Attachment

                        > Another option is to draw it[the burndown] in each location.  It's a nice ceremony to end the daily standup.

                        > The benefit of doing everything on the whiteboard is that everyone gets
                        to see and interact as a team during the daily scrum as the burndown gets updated and the tasks/stories move.

                        This is a minor point, and while I don't consider it a bad practice, I do consider it a bad smell(which means it may or may not be a material problem).

                        I believe that the tasks and burndown should be updated before the Daily Scrum.  The Scrum Guide does not prescribe a solution, other than to say that the task estimates be updated daily and that the burndown must be updated daily as well.  I have found that waiting to update the burndown and tasks until the daily Scrum usually creates waste.  (Same goes with obstacle identification -- waiting until the Daily Scrum to identify creates waste)

                        (Note:  [In brackets] are my own edits to the article that I'm including here inline)
                        <snip from my article: "Bad Smells of the Sprint Backlog" >

                        Bad Smell: Tasks change status in Daily Scrum

                        If developers move their tasks to “Done” during the daily Scrum, then obviously the burndown chart is now out of date.  If many developers do this, then the problem is multiplied.  It’s ok to point to tasks and stories on the board, but try to get your team to make a habit to either a) ALWAYS update tasks as SOON as they are complete, or at least b) ALWAYS update tasks 30 minutes prior to the Daily Scrum (That way the burndown is updated with fresh data just in time for the Daily Scrum[, so that the team can inspect and adapt).  Another reason to make sure tasks are updated immediately upon their completion is that it helps prevent waste( "goldplating", "thumb twiddling-while waiting until the Daily Scrum to pick a new task", and, "people waiting on a predecessor dependent task to be complete")


                        -------
                        Charles Bradley, CSM, PSM I
                        Experienced Scrum Coach
                        My blog: http://scrumcrazy.wordpress.com/


                      • Ron Jeffries
                        Hello, Charles. On Monday, April 4, 2011, at 1:35:01 PM, you ... I very much disagree with updating before the Scrum. The little ritual of having each person
                        Message 11 of 25 , Apr 4 10:49 AM
                        • 0 Attachment
                          Hello, Charles. On Monday, April 4, 2011, at 1:35:01 PM, you
                          wrote:

                          > This is a minor point, and while I don't consider it a bad practice, I do
                          > consider it a bad smell(which means it may or may not be a material problem).

                          > I believe that the tasks and burndown should be updated before the Daily Scrum.
                          > The Scrum Guide does not prescribe a solution, other than to say that the task
                          > estimates be updated daily and that the burndown must be updated daily as well.
                          > I have found that waiting to update the burndown and tasks until the daily Scrum
                          > usually creates waste. (Same goes with obstacle identification -- waiting until
                          > the Daily Scrum to identify creates waste)

                          I very much disagree with updating before the Scrum. The little
                          ritual of having each person move his own markers if a lovely way to
                          share success and provides exactly the right moment for each one to
                          talk.

                          I've done this both ways with the same team, and self-updating was
                          much better as a team practice.

                          Ron Jeffries
                          www.XProgramming.com
                          To tolerate a problem is to insist on it. -- Software for Your Head
                        • Charles Bradley - Scrum Coach CSM PSM I
                          Part of what Ron may be getting at here is that he believes you might be violating: http://agilemanifesto.org/ ... http://agilemanifesto.org/principles.html
                          Message 12 of 25 , Apr 4 11:02 AM
                          • 0 Attachment
                            Part of what Ron may be getting at here is that he believes you might be violating:

                            http://agilemanifesto.org/
                            > Individuals and interactions over processes and tools
                            http://agilemanifesto.org/principles.html
                            > The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
                             

                            -------
                            Charles Bradley, CSM, PSM I
                            Experienced Scrum Coach
                            My blog: http://scrumcrazy.wordpress.com/



                            From: Andrew Pham <andrewpham74@...>
                            To: Ron Jeffries <ronjeffries@...>; scrumdevelopment@yahoogroups.com
                            Sent: Sun, April 3, 2011 2:04:51 PM
                            Subject: [scrumdevelopment] Re: Why are you in favor of hand drawn burndown chart in a distributed world?



                            All the companies I have been coaching are distributed, whether is is all in the USA or around the world, but they are very much interested in Agile...

                            Even after we break the larger team into smaller teams, some of the team members are still not in the same location but the way we do thing (for instance, by using tool to create the burwndown chart, Agile and Scrum is still working and produce the expected results...

                            Andrew Pham
                            Agile and Lean Coach, Author of Scrum in Action
                            http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1


                            On Sun, Apr 3, 2011 at 2:48 PM, Ron Jeffries <ronjeffries@...> wrote:
                            Hello, Andrew.  On Sunday, April 3, 2011, at 3:08:06 PM, you wrote:

                            > So if you are brought into a company as an Agile coach, like myself, and
                            > they say that their team members are distributed around the USA or the
                            > world, how would you suggest to create the burndown chart for a project
                            > team? To have it drawn by hand? How then would you share it or have it
                            > updated by the team?

                            First of all, a company that works that way is, in my experience,
                            not very interested in doing anything Agile. So I might well prefer
                            to spend my time elsewhere.

                            That said, are all their programmers each in a different place? Or
                            are they in small teams?

                            Ron Jeffries
                            www.XProgramming.com
                            Do only what is necessary. Keep only what you need.




                          • Charles Bradley - Scrum Coach CSM PSM I
                            ... And I ve also done this both ways with multiple teams and we found that updating as soon as the task was complete increased efficiency(for the main reasons
                            Message 13 of 25 , Apr 4 11:13 AM
                            • 0 Attachment
                              > I've done this both ways with the same team, and self-updating was much better as a team practice.

                              And I've also done this both ways with multiple teams and we found that updating as soon as the task was complete increased efficiency(for the main reasons I suggested before), transparency, and the accuracy of the Scrum board and burndown.  I tend to encourage the teams that I coach to focus on more on optimizing their efficiency and getting PO acceptance sooner on stories as their main measure and feeling of success. 

                              To each his own, I guess.

                              -------
                              Charles Bradley, CSM, PSM I
                              Experienced Scrum Coach
                              My blog: http://scrumcrazy.wordpress.com/




                            • Andrew Pham
                              Jack, Glad to hear you confirm that you know of many successful Agile teams that use software tools to generate their burndown chart and what not... Not every
                              Message 14 of 25 , Apr 4 11:34 AM
                              • 0 Attachment
                                Jack,

                                Glad to hear you confirm that you know of many successful Agile teams that use software tools to generate their burndown chart and what not...

                                Not every tool is good for every project team or organization but refusing to use a tool which could make things easier for the project teams, especially the ones that are not co-located in one room, is against common sense and incomprehensible...

                                Andrew Pham
                                Agile and Lean Coach, Author of Scrum in Action
                                http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1

                                On Sun, Apr 3, 2011 at 9:10 PM, Jack Milunsky <jack@...> wrote:
                                 

                                The benefit of doing everything on the whiteboard is that everyone gets to see and interact as a team during the daily scrum as the burndown gets updated and the tasks/stories move. However if it's working for you using a tool go for it. There are many very successful teams using software tools.


                                But I'd at least recommend that you start out doing things manually till you're really good at it.

                                Jack
                                blog.agilebuddy.com


                                On Sun, Apr 3, 2011 at 2:29 PM, Andrew Pham <andrewpham74@...> wrote:
                                 

                                Hi Ron,

                                I don't know if my reply to your question came through or not but just wonder why you guys are so against using a tool to store team info and generate burndown charts for teams?

                                I had drawn simple burndown chart a few years back but with software development becoming so distributed, either because of telecommuting or because of off-shoring, I wonder how practical this old practice is still after so many changes in the software development world?

                                Is Agile or Scrum not about adapting to change itself?

                                Regards,

                                Andrew Pham
                                Agile and Lean Coach, Author of Scrum in Action
                                http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1

                                On Sun, Apr 3, 2011 at 11:06 AM, <ronjeffries@...> wrote:
                                 

                                Hello, Andrew,

                                On Apr 3, 2011, at 11:16 AM, you wrote:

                                > Rather than hand drawing the burndown chart, it will be best to get a cheap tool such as Greenhopper to have the chart automatically updated whenever you or your team log the time you spend working on your stories.
                                >
                                > Naturally if the project team is very small and everyone is located in the same room, then hand drawing is fine but having access to a tool is recommended since it more accurate and automatic.
                                >
                                > Just some suggestions from my coaching experience.

                                What advantages do you see to this practice, which seems in conflict with the advice of other coaches? In particular, I'm interested in it's effect on team and individual engagement.

                                R





                                --
                                Jack Milunsky
                                Agilebuddy.com

                                Cell: +1.416.302.5937
                                E-mail: jack@...
                                Web Site: www.agilebuddy.com
                                Blog: blog.agilebuddy.com
                                Twitter: twitter.com/agilebuddy


                              • Dan Rawsthorne
                                +1, completely agree... Dan ;-)
                                Message 15 of 25 , Apr 4 12:38 PM
                                • 0 Attachment
                                  +1, completely agree... Dan  ;-)
                                  On 4/4/2011 10:49 AM, Ron Jeffries wrote:
                                   

                                  Hello, Charles. On Monday, April 4, 2011, at 1:35:01 PM, you
                                  wrote:

                                  > This is a minor point, and while I don't consider it a bad practice, I do
                                  > consider it a bad smell(which means it may or may not be a material problem).

                                  > I believe that the tasks and burndown should be updated before the Daily Scrum.
                                  > The Scrum Guide does not prescribe a solution, other than to say that the task
                                  > estimates be updated daily and that the burndown must be updated daily as well.
                                  > I have found that waiting to update the burndown and tasks until the daily Scrum
                                  > usually creates waste. (Same goes with obstacle identification -- waiting until
                                  > the Daily Scrum to identify creates waste)

                                  I very much disagree with updating before the Scrum. The little
                                  ritual of having each person move his own markers if a lovely way to
                                  share success and provides exactly the right moment for each one to
                                  talk.

                                  I've done this both ways with the same team, and self-updating was
                                  much better as a team practice.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  To tolerate a problem is to insist on it. -- Software for Your Head

                                • Ron Jeffries
                                  ... Tools are somewhat good for communicating /between/ rooms and /between/ individuals not in the same room. So if the entire team were distributed, one might
                                  Message 16 of 25 , Apr 4 2:46 PM
                                  • 0 Attachment
                                    Hello, Andrew. On Monday, April 4, 2011, at 2:34:43 PM, you wrote:

                                    > Not every tool is good for every project team or organization but refusing
                                    > to use a tool which could make things easier for the project teams,
                                    > especially the ones that are not co-located in one room, is against common
                                    > sense and incomprehensible...

                                    Tools are somewhat good for communicating /between/ rooms and
                                    /between/ individuals not in the same room. So if the entire team
                                    were distributed, one might surely use some kind of tool to hep them
                                    track.

                                    Inside the same room, no tool that I know of works as well as a
                                    simple chart on the wall and a task board on the wall. The reasons
                                    include:

                                    the walls "radiate" information while the tools generally require
                                    pull;

                                    the tools generally require a single person's engagement, while
                                    the wall can be a team project;

                                    the walls bring managers and business owners into the room for
                                    greater engagement;

                                    the team can gather around the wall, while seldom does the team
                                    ever gather around a computer monitor.

                                    It is possible to do a decent job of software development in a
                                    distributed fashion. It is very difficult to do a decent job of
                                    /team/ development in a distributed fashion. Whenever I have found
                                    an organization trying to track and manage a project with a tool, I
                                    have found a relatively weak level of team engagement.

                                    Sometimes that's all that you can get. It is unwise to start there
                                    if you do not have to, and very unwise to start there if you have
                                    never had the experience of working with a team with everything in
                                    their room and on their walls.

                                    I trust that people who have worked extensively "in the room" can
                                    make good decisions in situations where the room is not available. I
                                    would not start a beginning organization out with tools because they
                                    are in danger of never learning that together is better.

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Some things are impossible. And some things people say are
                                    impossible are impossible because they don't know how to do them.
                                    -- Ron Loyd
                                  • Alan Dayley
                                    Devil s advocate question here, not to attack, but to learn. If the team updates task and story state immediately upon a state change or does such updates at
                                    Message 17 of 25 , Apr 4 2:56 PM
                                    • 0 Attachment
                                      Devil's advocate question here, not to attack, but to learn.

                                      If the team updates task and story state immediately upon a state change or does such updates at least 30 minutes before the daily meeting:

                                      - What is the purpose of the daily meeting?
                                      - What does the team talk about in the meeting?
                                      - In other words, doesn't that make the daily meeting redundant and, therefore, waste?

                                      Alan

                                      On Mon, Apr 4, 2011 at 10:35 AM, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                                       


                                      > Another option is to draw it[the burndown] in each location.  It's a nice ceremony to end the daily standup.


                                      > The benefit of doing everything on the whiteboard is that everyone gets to see and interact as a team during the daily scrum as the burndown gets updated and the tasks/stories move.

                                      This is a minor point, and while I don't consider it a bad practice, I do consider it a bad smell(which means it may or may not be a material problem).

                                      I believe that the tasks and burndown should be updated before the Daily Scrum.  The Scrum Guide does not prescribe a solution, other than to say that the task estimates be updated daily and that the burndown must be updated daily as well.  I have found that waiting to update the burndown and tasks until the daily Scrum usually creates waste.  (Same goes with obstacle identification -- waiting until the Daily Scrum to identify creates waste)

                                      (Note:  [In brackets] are my own edits to the article that I'm including here inline)
                                      <snip from my article: "Bad Smells of the Sprint Backlog" >

                                      Bad Smell: Tasks change status in Daily Scrum

                                      If developers move their tasks to “Done” during the daily Scrum, then obviously the burndown chart is now out of date.  If many developers do this, then the problem is multiplied.  It’s ok to point to tasks and stories on the board, but try to get your team to make a habit to either a) ALWAYS update tasks as SOON as they are complete, or at least b) ALWAYS update tasks 30 minutes prior to the Daily Scrum (That way the burndown is updated with fresh data just in time for the Daily Scrum[, so that the team can inspect and adapt).  Another reason to make sure tasks are updated immediately upon their completion is that it helps prevent waste( "goldplating", "thumb twiddling-while waiting until the Daily Scrum to pick a new task", and, "people waiting on a predecessor dependent task to be complete")


                                      -------
                                      Charles Bradley, CSM, PSM I
                                      Experienced Scrum Coach
                                      My blog: http://scrumcrazy.wordpress.com/



                                    • Adam Sroka
                                      Echoing what Ron said, somewhat: the biggest problem with the tool is that it has a number of unintended consequences for the co-located folks. Unfortunately,
                                      Message 18 of 25 , Apr 4 3:05 PM
                                      • 0 Attachment
                                        Echoing what Ron said, somewhat: the biggest problem with the tool is that it has a number of unintended consequences for the co-located folks. Unfortunately, most teams never learn about this because they go straight to the tool. Coaches who are experienced with highly collaborative teams can see the difference, but to the teams (particularly the ones who come from tool heavy traditions like RUP) it seems like an improvement. 

                                        There is a lot of research going back a few decades about the impact that environment has on the way we work together. It is visceral the effect that projecting the tool on the wall has. Everyone turns away from each other and stares at the screen. The more ADD among us actually tune out completely (Perhaps dissolving into our own laptop screens, smart phones, or shiny new iPads.) 

                                        The old school XP approach of sprawling a deck of cards across the table has the opposite effect. It turns everyone inward so that we are noticeably sharing the same space. If you and I are looking at the same card at the same time we almost can't help but talk about it. 

                                        The tools aren't going anywhere, and neither are the mostly erroneous beliefs that distributed teams save money or amplify effectiveness. However, those of us who have performed and witnessed both approaches aren't going to start praising the tools any time soon. 
                                      • Alan Dayley
                                        +1 to Ron and +1 to Adam s excellent expansion. Alan
                                        Message 19 of 25 , Apr 4 3:08 PM
                                        • 0 Attachment
                                          +1 to Ron and +1 to Adam's excellent expansion.

                                          Alan

                                          On Mon, Apr 4, 2011 at 3:05 PM, Adam Sroka <adam.sroka@...> wrote:
                                           

                                          Echoing what Ron said, somewhat: the biggest problem with the tool is that it has a number of unintended consequences for the co-located folks. Unfortunately, most teams never learn about this because they go straight to the tool. Coaches who are experienced with highly collaborative teams can see the difference, but to the teams (particularly the ones who come from tool heavy traditions like RUP) it seems like an improvement. 


                                          There is a lot of research going back a few decades about the impact that environment has on the way we work together. It is visceral the effect that projecting the tool on the wall has. Everyone turns away from each other and stares at the screen. The more ADD among us actually tune out completely (Perhaps dissolving into our own laptop screens, smart phones, or shiny new iPads.) 

                                          The old school XP approach of sprawling a deck of cards across the table has the opposite effect. It turns everyone inward so that we are noticeably sharing the same space. If you and I are looking at the same card at the same time we almost can't help but talk about it. 

                                          The tools aren't going anywhere, and neither are the mostly erroneous beliefs that distributed teams save money or amplify effectiveness. However, those of us who have performed and witnessed both approaches aren't going to start praising the tools any time soon. 


                                        • Adam Sroka
                                          Assuming all of the information that every team member needs is in the tool then it would be entirely wasteful to set aside time to communicate it in another
                                          Message 20 of 25 , Apr 4 3:11 PM
                                          • 0 Attachment
                                            Assuming all of the information that every team member needs is in the tool then it would be entirely wasteful to set aside time to communicate it in another format. However, even with the best uses of tools that I have seen not nearly all of the information is captured in the tool. Plus, as is the case with nearly all written communication, the content in the tool can be easily misinterpreted. The best use of the tool is to act as a placeholder for conversations in the same way that physical cards do in XP (e.g. I finished this task, and Alan is working on that related task. I should talk to Alan to see how I can help get this story finished.) 

                                            On Mon, Apr 4, 2011 at 2:56 PM, Alan Dayley <alandd@...> wrote:
                                             

                                            Devil's advocate question here, not to attack, but to learn.


                                            If the team updates task and story state immediately upon a state change or does such updates at least 30 minutes before the daily meeting:

                                            - What is the purpose of the daily meeting?
                                            - What does the team talk about in the meeting?
                                            - In other words, doesn't that make the daily meeting redundant and, therefore, waste?

                                            Alan

                                            On Mon, Apr 4, 2011 at 10:35 AM, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                                             


                                            > Another option is to draw it[the burndown] in each location.  It's a nice ceremony to end the daily standup.


                                            > The benefit of doing everything on the whiteboard is that everyone gets to see and interact as a team during the daily scrum as the burndown gets updated and the tasks/stories move.

                                            This is a minor point, and while I don't consider it a bad practice, I do consider it a bad smell(which means it may or may not be a material problem).

                                            I believe that the tasks and burndown should be updated before the Daily Scrum.  The Scrum Guide does not prescribe a solution, other than to say that the task estimates be updated daily and that the burndown must be updated daily as well.  I have found that waiting to update the burndown and tasks until the daily Scrum usually creates waste.  (Same goes with obstacle identification -- waiting until the Daily Scrum to identify creates waste)

                                            (Note:  [In brackets] are my own edits to the article that I'm including here inline)
                                            <snip from my article: "Bad Smells of the Sprint Backlog" >

                                            Bad Smell: Tasks change status in Daily Scrum

                                            If developers move their tasks to “Done” during the daily Scrum, then obviously the burndown chart is now out of date.  If many developers do this, then the problem is multiplied.  It’s ok to point to tasks and stories on the board, but try to get your team to make a habit to either a) ALWAYS update tasks as SOON as they are complete, or at least b) ALWAYS update tasks 30 minutes prior to the Daily Scrum (That way the burndown is updated with fresh data just in time for the Daily Scrum[, so that the team can inspect and adapt).  Another reason to make sure tasks are updated immediately upon their completion is that it helps prevent waste( "goldplating", "thumb twiddling-while waiting until the Daily Scrum to pick a new task", and, "people waiting on a predecessor dependent task to be complete")


                                            -------
                                            Charles Bradley, CSM, PSM I
                                            Experienced Scrum Coach
                                            My blog: http://scrumcrazy.wordpress.com/




                                          • Ron Jeffries
                                            ... Same as always: to ensure that everyone is synched up. ... The standard questions three. ... Not likely, because the little meeting spawns others. However,
                                            Message 21 of 25 , Apr 4 4:05 PM
                                            • 0 Attachment
                                              Hello, Alan. On Monday, April 4, 2011, at 5:56:57 PM, you wrote:

                                              > Devil's advocate question here, not to attack, but to learn.

                                              > If the team updates task and story state immediately upon a state change or
                                              > does such updates at least 30 minutes before the daily meeting:

                                              > - What is the purpose of the daily meeting?

                                              Same as always: to ensure that everyone is synched up.

                                              > - What does the team talk about in the meeting?

                                              The standard questions three.

                                              > - In other words, doesn't that make the daily meeting redundant and,
                                              > therefore, waste?

                                              Not likely, because the little meeting spawns others. However, it is
                                              entirely possible that for a sufficiently integrated team, the daily
                                              meeting is redundant and waste.

                                              The most integrated team I ever worked with didn't think so,
                                              however: they found it a good moment to come together, make sure
                                              they were on track, spawn any other needed work, decide who was
                                              going to work with whom, and return to the day.

                                              Ron Jeffries
                                              www.XProgramming.com
                                              You don't want to sell me waterfall.
                                              You want to go home and rethink your life.
                                            • Mark Graybill
                                              I agree with Ron. At my last company we tried the other way first. The standup seemed like a mere formality to disseminate data rather than a task the team
                                              Message 22 of 25 , Apr 4 7:32 PM
                                              • 0 Attachment

                                                I agree with Ron.  At my last company we tried the other way first.  The standup seemed like a mere formality to disseminate data rather than a task the team did together.   Such subtle concepts and their significance are I think the hardest Scrum concepts to understand.

                                                 

                                                Also, with the first method, I noticed that with a couple of members, they examined the burn down chart right away before we started.  I never told them (I think) but as a social experiment I fudged the burn down to show we were slightly ahead (for a week I think) and then the opposite for another week. 

                                                 

                                                It seemed when we were ahead that some members slacked off (due to their reports, we adjusted more of their stories to show they require more effort).  This is consistent with the research literature.

                                                 

                                                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                                                Sent: Monday, April 04, 2011 12:50 PM
                                                To: scrumdevelopment@yahoogroups.com
                                                Subject: Re: [scrumdevelopment] Why are you in favor of hand drawn burndown chart in a distributed world?

                                                 

                                                 

                                                Hello, Charles. On Monday, April 4, 2011, at 1:35:01 PM, you
                                                wrote:

                                                > This is a minor point, and while I don't consider it a bad practice, I do
                                                > consider it a bad smell(which means it may or may not be a material problem).

                                                > I believe that the tasks and burndown should be updated before the Daily Scrum.
                                                > The Scrum Guide does not prescribe a solution, other than to say that the task
                                                > estimates be updated daily and that the burndown must be updated daily as well.
                                                > I have found that waiting to update the burndown and tasks until the daily Scrum
                                                > usually creates waste. (Same goes with obstacle identification -- waiting until
                                                > the Daily Scrum to identify creates waste)

                                                I very much disagree with updating before the Scrum. The little
                                                ritual of having each person move his own markers if a lovely way to
                                                share success and provides exactly the right moment for each one to
                                                talk.

                                                I've done this both ways with the same team, and self-updating was
                                                much better as a team practice.

                                                Ron Jeffries
                                                www.XProgramming.com
                                                To tolerate a problem is to insist on it. -- Software for Your Head

                                              • Mark Graybill
                                                Besides the obvious purposes, there is more purpose behind (or underneath) the scenes. Such purpose has as much or more of a tangible affect on productivity,
                                                Message 23 of 25 , Apr 4 7:39 PM
                                                • 0 Attachment
                                                  Besides the obvious purposes, there is more purpose behind (or underneath)
                                                  the scenes.

                                                  Such purpose has as much or more of a tangible affect on productivity,
                                                  product conceptual integrity and the project overall.

                                                  One general purpose is to maximize the social and conceptual integration,
                                                  and the cohesion, of a team. Such is critical in Agile, IMO.


                                                  -----Original Message-----
                                                  From: scrumdevelopment@yahoogroups.com
                                                  [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                                                  Sent: Monday, April 04, 2011 6:05 PM
                                                  To: scrumdevelopment@yahoogroups.com
                                                  Subject: Re: [scrumdevelopment] Why are you in favor of hand drawn burndown
                                                  chart in a distributed world?

                                                  Hello, Alan. On Monday, April 4, 2011, at 5:56:57 PM, you wrote:

                                                  > Devil's advocate question here, not to attack, but to learn.

                                                  > If the team updates task and story state immediately upon a state change
                                                  or
                                                  > does such updates at least 30 minutes before the daily meeting:

                                                  > - What is the purpose of the daily meeting?

                                                  Same as always: to ensure that everyone is synched up.

                                                  > - What does the team talk about in the meeting?

                                                  The standard questions three.

                                                  > - In other words, doesn't that make the daily meeting redundant and,
                                                  > therefore, waste?

                                                  Not likely, because the little meeting spawns others. However, it is
                                                  entirely possible that for a sufficiently integrated team, the daily
                                                  meeting is redundant and waste.

                                                  The most integrated team I ever worked with didn't think so,
                                                  however: they found it a good moment to come together, make sure
                                                  they were on track, spawn any other needed work, decide who was
                                                  going to work with whom, and return to the day.

                                                  Ron Jeffries
                                                  www.XProgramming.com
                                                  You don't want to sell me waterfall.
                                                  You want to go home and rethink your life.



                                                  ------------------------------------

                                                  To Post a message, send it to: scrumdevelopment@...
                                                  To Unsubscribe, send a blank message to:
                                                  scrumdevelopment-unsubscribe@...! Groups Links
                                                • Dave Smith
                                                  ... Or greater comfort. One team I worked with had a good record of producing features every iteration, but due possibly to some external factors, a few
                                                  Message 24 of 25 , Apr 4 9:18 PM
                                                  • 0 Attachment
                                                    On Mon, Apr 4, 2011 at 2:46 PM, Ron Jeffries <ronjeffries@...> wrote:

                                                     the walls bring managers and business owners into the room for
                                                     greater engagement;

                                                    Or greater comfort.

                                                    One team I worked with had a good record of producing features
                                                    every iteration, but due possibly to some external factors, a few
                                                    higher-ups were getting nervous. The team talked about it, and
                                                    put up a hand-drawn burn-up chart. People outside the team saw
                                                    the steady progress the team was making, and got less nervous.

                                                    We went with a burn up chart rather than a burn down chart for the
                                                    psychological goodness of chart lines going "up and to the right".
                                                    We went with hand drawn because it was easy. And oddly, hand-
                                                    drawn invited less scrutiny, and avoided scrutiny's sibling,
                                                    micromanagement.

                                                    The team itself pretty much ignored the chart, since there was really
                                                    nothing actionable there for anyone other than the team lead and
                                                    product owner, and they worked off of our card wall. The chart was
                                                    right next to the card wall, but we found that the card wall was a
                                                    poor information radiator to those unfamiliar with the tool. Rather
                                                    than trying to educated people into meeting us on our terms, the
                                                    chart was a way of reaching them on theirs.

                                                    After a few months, the nervousness subsided, we stopped putting
                                                    up the chart, and life went on.

                                                    Dave

                                                  • George Dinwiddie
                                                    Marvelous story, Dave. And very consistent with my observations with teams. ... -- ... * George Dinwiddie * http://blog.gdinwiddie.com
                                                    Message 25 of 25 , Apr 5 8:06 AM
                                                    • 0 Attachment
                                                      Marvelous story, Dave. And very consistent with my observations with teams.

                                                      On 4/5/11 12:18 AM, Dave Smith wrote:
                                                      >
                                                      >
                                                      > On Mon, Apr 4, 2011 at 2:46 PM, Ron Jeffries <ronjeffries@...
                                                      > <mailto:ronjeffries@...>> wrote:
                                                      >
                                                      >
                                                      > the walls bring managers and business owners into the room for
                                                      > greater engagement;
                                                      >
                                                      >
                                                      > Or greater comfort.
                                                      >
                                                      > One team I worked with had a good record of producing features
                                                      > every iteration, but due possibly to some external factors, a few
                                                      > higher-ups were getting nervous. The team talked about it, and
                                                      > put up a hand-drawn burn-up chart. People outside the team saw
                                                      > the steady progress the team was making, and got less nervous.
                                                      >
                                                      > We went with a burn up chart rather than a burn down chart for the
                                                      > psychological goodness of chart lines going "up and to the right".
                                                      > We went with hand drawn because it was easy. And oddly, hand-
                                                      > drawn invited less scrutiny, and avoided scrutiny's sibling,
                                                      > micromanagement.
                                                      >
                                                      > The team itself pretty much ignored the chart, since there was really
                                                      > nothing actionable there for anyone other than the team lead and
                                                      > product owner, and they worked off of our card wall. The chart was
                                                      > right next to the card wall, but we found that the card wall was a
                                                      > poor information radiator to those unfamiliar with the tool. Rather
                                                      > than trying to educated people into meeting us on our terms, the
                                                      > chart was a way of reaching them on theirs.
                                                      >
                                                      > After a few months, the nervousness subsided, we stopped putting
                                                      > up the chart, and life went on.
                                                      >
                                                      > Dave
                                                      >

                                                      --
                                                      ----------------------------------------------------------------------
                                                      * George Dinwiddie * http://blog.gdinwiddie.com
                                                      Software Development http://www.idiacomputing.com
                                                      Consultant and Coach http://www.agilemaryland.org
                                                      ----------------------------------------------------------------------
                                                    Your message has been successfully submitted and would be delivered to recipients shortly.