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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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.