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

Re: [scrumdevelopment] Release Burndown chart in Excel

Expand Messages
  • Mike Cohn
    Hi Jeff-- I saw your later email saying you figured out how to create this type of burndown chart. But you can see how I do it via the link at the bottom of:
    Message 1 of 21 , Aug 1, 2007
    • 0 Attachment
      Hi Jeff--
      I saw your later email saying you figured out how to create this type of burndown chart. But you can see how I do it via the link at the bottom of:
      And if you don't know what this type of burndown bar chart looks like, it is described on that page which includes a link to an XLS file for creating them.
      Regards,
      Mike Cohn
      Author:
        Agile Estimating and Planning
        User Stories Applied
      www.mountaingoatsoftware.com


      On Aug 1, 2007, at 9:29 AM, Jeff Martin wrote:


      Does anyone have a template or example of how to create an alternative release burndown chart described by Mike Cohn at http://www.mountaingoatsoftware.com/alt_releaseburndown?
       
      I've written one using a charting component, but I'm trying to keep things simple and keeping it in Excel is the simplest path.
       
      Thanks,
       
      Jeff Martin
      Senior Developer
      Smith Seckman Reid, Inc.
      (615) 460-0528 Direct
      (615) 386-8469 Fax
      P Please do not print this e-mail unless necessary
       
      Notice: This message is confidential, is intended only for the named recipient(s) and may contain information that is privileged or exempt from disclosure under applicable law. If you are not the intended recipient(s), you are notified that the dissemination, distribution or copying of this message is strictly prohibited.  If you received this message and are not an intended recipient, please delete it from your computer.
       


    • Ilja Preuss
      ... In my experience, for those kinds of charts, manually drawn diagrams on flip chart paper, put on a wall for everyone to see, works even better. Cheers,
      Message 2 of 21 , Aug 4, 2007
      • 0 Attachment
        Jeff Martin wrote:
        > I've written one using a charting component, but I'm trying to keep
        > things simple and keeping it in Excel is the simplest path.

        In my experience, for those kinds of charts, manually drawn diagrams on
        flip chart paper, put on a wall for everyone to see, works even better.

        Cheers, Ilja
      • Marco Milone
        Until you start having people working from home or dispersed teams. Regards, Marco ________________________________ From: scrumdevelopment@yahoogroups.com
        Message 3 of 21 , Aug 6, 2007
        • 0 Attachment

          Until you start having people working from home or dispersed teams.

          Regards,

          Marco

           

           

           


          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ilja Preuss
          Sent: 04 August 2007 18:32
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Release Burndown chart in Excel

           

          Jeff Martin wrote:

          > I've written one using a charting component, but I'm trying to keep
          > things simple and keeping it in Excel is the simplest path.

          In my experience, for those kinds of charts, manually drawn diagrams on
          flip chart paper, put on a wall for everyone to see, works even better.

          Cheers, Ilja


          For the most important conference on Software testing and quality visit www.sqs-conferences.com

          This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

          SQS-UK: SQS Group Limited | Incorporated in England and Wales | Registered No. 2857864 | VAT No. 788 1795 61
          SQS-Ire: SQS Software Quality Systems (Ireland) Limited | Incorporated in Ireland | Registered No. 307763 | Vat No. IE6327763G
          SQS-SA: South African Branch office of SQS Group Limited | Registered in South Africa | Registered No. 2004/010639/10 | Vat No. 40602176781
        • Jeff Martin
          Except when the CFO emails you and asks you how the project is going, walk down to my office and look on the wall is not the answer he s looking for. Or
          Message 4 of 21 , Aug 6, 2007
          • 0 Attachment

            Except when the CFO emails you and asks you how the project is going, “walk down to my office and look on the wall” is not the answer he’s looking for.  Or when he wants to include the development status in his monthly board meeting, we are a small chart on a page with a lot of other charts and information.  I’m not going to ask him to drag in a giant piece of paper with my scribbled drawings on it. 

             

            Warning: small rant is ahead and this is in no way aimed at you Ilja, I value everyone’s advice on this mailing list.  I’ve done a significant amount of reading on agile and Scrum in particular and I read most of the messages that come through this mailing list.  There seems to be this contingent of the community that believe anything more than index cards and hand drawn charts are sacrilege.  Now, I agree that concentrating more on the tools than the actual development of the product is definitely not a good thing.  And the first value of agile is “Individuals and interactions over processes and tools.”  But it even states that there is value in the processes and tools, just more value in the individuals and interactions.  If the individuals involved prefer to track their tasks in a software tool rather than on an index card, then that’s what they should do.  If the product owner prefers to see the burndown as an Excel chart that can be printed, copied and pasted and emailed over a hand drawn chart, then that’s what should happen.  I don’t understand the aversion to using software in the process.  We spend our entire career telling companies that we can write software to improve their businesses and processes, but we’re saying we can’t improve our own?  That our process is better with index cards and cork boards?  It’s very true that most of the “agile” tools on the market are not agile and either have too much or not enough.  But that doesn’t mean that any use of software is A Bad Thing©.  

             

            Isn’t the entire point of agile development to do what works for your team?  This thought process that thinks you can’t be agile if you are using a software package to track tasks or you aren’t collocated or if you don’t follow the rules to the letter or you have fewer or more than 5-9 people on the team.  I’m calling bull on that.  Agile is about doing what works the best.  If we all follow the same rules, we’re no better off than we were before.  If we all do agile the right way, that probably means that we’ll all be doing things a little differently than each other.  One thing I will concede is that everyone should start off as simple as possible.  I am a firm believer in the concept of knowing why you are breaking the rules before you start breaking them. 

             

            Once again, this is not directed at you Ilja.  It’s just the result of a lot of different emails and blog posts. 

             

            jeff

             

             

            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ilja Preuss
            Sent: Saturday, August 04, 2007 12:32 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Release Burndown chart in Excel

             

            Jeff Martin wrote:

            > I've written one using a charting component, but I'm trying to keep
            > things simple and keeping it in Excel is the simplest path.

            In my experience, for those kinds of charts, manually drawn diagrams on
            flip chart paper, put on a wall for everyone to see, works even better.

            Cheers, Ilja

          • George Dinwiddie
            ... [rant against simple tools deleted] Jeff, could it be that your CFO might be looking for some report other than what s useful within the team? Might an
            Message 5 of 21 , Aug 6, 2007
            • 0 Attachment
              On Mon, August 6, 2007 12:47, Jeff Martin wrote:
              > Except when the CFO emails you and asks you how the project is going,
              > "walk down to my office and look on the wall" is not the answer he's
              > looking for. Or when he wants to include the development status in his
              > monthly board meeting, we are a small chart on a page with a lot of
              > other charts and information. I'm not going to ask him to drag in a
              > giant piece of paper with my scribbled drawings on it.

              [rant against simple tools deleted]

              Jeff, could it be that your CFO might be looking for some report other
              than what's useful within the team? Might an email summarizing how the
              project is going answer the question better than forwarding a copy of your
              tracking tool?

              I'm reminded of a project leader I once had who chastised several of the
              team for writing "ate some turkey" on their weekly status report one
              November. Apparently, he merely cut and pasted the contents of those
              reports into the one he sent to the CEO. Rather than be embarrassed at
              his lack of attention to the status and progress of the project, he was
              angry that those comments had made visible his lack of oversight.

              Now I'm not suggesting that you're not overseeing your project properly.
              I am asking, however, if you're presenting it in the best way to upper
              management. Perhaps you've settled for the easiest way, instead.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • Clay Ver Valen
              I d like to stay out of the pros and cons of this and just let the list know that I ve updated the Sprint Tracking Excel template available from the Scrum
              Message 6 of 21 , Aug 6, 2007
              • 0 Attachment

                I’d like to stay out of the pros and cons of this and just let the list know that I’ve updated the Sprint Tracking Excel template available from the Scrum Alliance web site.

                 

                This new version includes a new worksheet, “Release Burn Down”,  for easily creating the Release Burn Down chart as described in Mike Cohn’s earlier posting.  Basically, all you need do is fill in the Progress figures and the rest will just fill in for you with the chart legend automatically displaying what the anticipated release sprint indicated by the trendlines is.  I just sent the ZIP file to the webmaster so it should be up there within a couple days at http://www.scrumalliance.org/resources/18.

                 

                For anyone that can’t wait, please send me an email message off-list and I will email you back with the ZIP file attached.

                 

                -          Clay

                 

                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
                Sent: Monday, August 06, 2007 10:43 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: RE: [scrumdevelopment] Release Burndown chart in Excel

                 


                On Mon, August 6, 2007 12:47, Jeff Martin wrote:
                > Except when the CFO emails you and asks you how the project is going,
                > "walk down to my office and look on the wall" is not the answer he's
                > looking for. Or when he wants to include the development status in his
                > monthly board meeting, we are a small chart on a page with a lot of
                > other charts and information. I'm not going to ask him to drag in a
                > giant piece of paper with my scribbled drawings on it.

                [rant against simple tools deleted]

                Jeff, could it be that your CFO might be looking for some report other
                than what's useful within the team? Might an email summarizing how the
                project is going answer the question better than forwarding a copy of your
                tracking tool?

                I'm reminded of a project leader I once had who chastised several of the
                team for writing "ate some turkey" on their weekly status report one
                November. Apparently, he merely cut and pasted the contents of those
                reports into the one he sent to the CEO. Rather than be embarrassed at
                his lack of attention to the status and progress of the project, he was
                angry that those comments had made visible his lack of oversight.

                Now I'm not suggesting that you're not overseeing your project properly.
                I am asking, however, if you're presenting it in the best way to upper
                management. Perhaps you've settled for the easiest way, instead.

                - George

                --
                ----------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------

              • Jeff Martin
                That is a very good question and something I m still trying to answer. My company is not only new to scrum, but fairly new to software development as well.
                Message 7 of 21 , Aug 6, 2007
                • 0 Attachment

                  That is a very good question and something I’m still trying to answer.  My company is not only new to scrum, but fairly new to software development as well.  The company does engineering design and are used to set phases and a project being x% complete.  It’s funny to see that they are so precise on the % complete of a project, they will say a project is 56.8% complete.  And we all know there is no way to be that precise.  So, yes, I’m still looking for the best way of providing information up the ladder.  But I still need to provide the burndown chart to the CFO, as he is the product owner on most of our projects, so he is part of the team. 

                   

                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
                  Sent: Monday, August 06, 2007 12:43 PM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: RE: [scrumdevelopment] Release Burndown chart in Excel

                   


                  On Mon, August 6, 2007 12:47, Jeff Martin wrote:
                  > Except when the CFO emails you and asks you how the project is going,
                  > "walk down to my office and look on the wall" is not the answer he's
                  > looking for. Or when he wants to include the development status in his
                  > monthly board meeting, we are a small chart on a page with a lot of
                  > other charts and information. I'm not going to ask him to drag in a
                  > giant piece of paper with my scribbled drawings on it.

                  [rant against simple tools deleted]

                  Jeff, could it be that your CFO might be looking for some report other
                  than what's useful within the team? Might an email summarizing how the
                  project is going answer the question better than forwarding a copy of your
                  tracking tool?

                  I'm reminded of a project leader I once had who chastised several of the
                  team for writing "ate some turkey" on their weekly status report one
                  November. Apparently, he merely cut and pasted the contents of those
                  reports into the one he sent to the CEO. Rather than be embarrassed at
                  his lack of attention to the status and progress of the project, he was
                  angry that those comments had made visible his lack of oversight.

                  Now I'm not suggesting that you're not overseeing your project properly.
                  I am asking, however, if you're presenting it in the best way to upper
                  management. Perhaps you've settled for the easiest way, instead.

                  - George

                  --
                  ----------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------

                • George Dinwiddie
                  Jeff, You might want to look at Quality Software Management, vol 2 for some other ideas on how to measure and present software progress. - George ... -- ... *
                  Message 8 of 21 , Aug 6, 2007
                  • 0 Attachment
                    Jeff,

                    You might want to look at Quality Software Management, vol 2 for some
                    other ideas on how to measure and present software progress.

                    - George

                    On Mon, August 6, 2007 15:06, Jeff Martin wrote:
                    > That is a very good question and something I'm still trying to answer.
                    > My company is not only new to scrum, but fairly new to software
                    > development as well. The company does engineering design and are used
                    > to set phases and a project being x% complete. It's funny to see that
                    > they are so precise on the % complete of a project, they will say a
                    > project is 56.8% complete. And we all know there is no way to be that
                    > precise. So, yes, I'm still looking for the best way of providing
                    > information up the ladder. But I still need to provide the burndown
                    > chart to the CFO, as he is the product owner on most of our projects, so
                    > he is part of the team.
                    >
                    >
                    >
                    > From: scrumdevelopment@yahoogroups.com
                    > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
                    > Sent: Monday, August 06, 2007 12:43 PM
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: RE: [scrumdevelopment] Release Burndown chart in Excel
                    >
                    >
                    >
                    >
                    > On Mon, August 6, 2007 12:47, Jeff Martin wrote:
                    >> Except when the CFO emails you and asks you how the project is going,
                    >> "walk down to my office and look on the wall" is not the answer he's
                    >> looking for. Or when he wants to include the development status in his
                    >> monthly board meeting, we are a small chart on a page with a lot of
                    >> other charts and information. I'm not going to ask him to drag in a
                    >> giant piece of paper with my scribbled drawings on it.
                    >
                    > [rant against simple tools deleted]
                    >
                    > Jeff, could it be that your CFO might be looking for some report other
                    > than what's useful within the team? Might an email summarizing how the
                    > project is going answer the question better than forwarding a copy of
                    > your
                    > tracking tool?
                    >
                    > I'm reminded of a project leader I once had who chastised several of the
                    > team for writing "ate some turkey" on their weekly status report one
                    > November. Apparently, he merely cut and pasted the contents of those
                    > reports into the one he sent to the CEO. Rather than be embarrassed at
                    > his lack of attention to the status and progress of the project, he was
                    > angry that those comments had made visible his lack of oversight.
                    >
                    > Now I'm not suggesting that you're not overseeing your project properly.
                    >
                    > I am asking, however, if you're presenting it in the best way to upper
                    > management. Perhaps you've settled for the easiest way, instead.
                    >
                    > - George
                    >
                    > --
                    > ----------------------------------------------------------
                    > * George Dinwiddie * http://blog.gdinwiddie.com
                    > Software Development http://www.idiacomputing.com
                    > Consultant and Coach http://www.agilemaryland.org
                    > ----------------------------------------------------------
                    >
                    >
                    >
                    >


                    --
                    ----------------------------------------------------------------------
                    * George Dinwiddie * http://blog.gdinwiddie.com
                    Software Development http://www.idiacomputing.com
                    Consultant and Coach http://www.agilemaryland.org
                    ----------------------------------------------------------------------
                  • Mike Cohn
                    Fantastic, Clay. Thank you for providing this resource to us. Regards, Mike Cohn Author: Agile Estimating and Planning User Stories Applied
                    Message 9 of 21 , Aug 6, 2007
                    • 0 Attachment
                      Fantastic, Clay. Thank you for providing this resource to us.
                      Regards,
                      Mike Cohn
                      Author:
                        Agile Estimating and Planning
                        User Stories Applied
                      www.mountaingoatsoftware.com


                      On Aug 6, 2007, at 12:00 PM, Clay Ver Valen wrote:


                      I’d like to stay out of the pros and cons of this and just let the list know that I’ve updated the Sprint Tracking Excel template available from the Scrum Alliance web site.

                       

                      This new version includes a new worksheet, “Release Burn Down”,  for easily creating the Release Burn Down chart as described in Mike Cohn’s earlier posting.  Basically, all you need do is fill in the Progress figures and the rest will just fill in for you with the chart legend automatically displaying what the anticipated release sprint indicated by the trendlines is.  I just sent the ZIP file to the webmaster so it should be up there within a couple days at http://www.scrumalliance.org/resources/18.

                       

                      For anyone that can’t wait, please send me an email message off-list and I will email you back with the ZIP file attached.

                       

                      -          Clay

                       

                      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
                      Sent: Monday, August 06, 2007 10:43 AM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: RE: [scrumdevelopment] Release Burndown chart in Excel

                       


                      On Mon, August 6, 2007 12:47, Jeff Martin wrote:
                      > Except when the CFO emails you and asks you how the project is going,
                      > "walk down to my office and look on the wall" is not the answer he's
                      > looking for. Or when he wants to include the development status in his
                      > monthly board meeting, we are a small chart on a page with a lot of
                      > other charts and information. I'm not going to ask him to drag in a
                      > giant piece of paper with my scribbled drawings on it.

                      [rant against simple tools deleted]

                      Jeff, could it be that your CFO might be looking for some report other
                      than what's useful within the team? Might an email summarizing how the
                      project is going answer the question better than forwarding a copy of your
                      tracking tool?

                      I'm reminded of a project leader I once had who chastised several of the
                      team for writing "ate some turkey" on their weekly status report one
                      November. Apparently, he merely cut and pasted the contents of those
                      reports into the one he sent to the CEO. Rather than be embarrassed at
                      his lack of attention to the status and progress of the project, he was
                      angry that those comments had made visible his lack of oversight.

                      Now I'm not suggesting that you're not overseeing your project properly.
                      I am asking, however, if you're presenting it in the best way to upper
                      management. Perhaps you've settled for the easiest way, instead.

                      - George

                      --
                      ----------------------------------------------------------
                      * George Dinwiddie * http://blog.gdinwiddie.com
                      Software Development http://www.idiacomputing.com
                      Consultant and Coach http://www.agilemaryland.org
                      ----------------------------------------------------------



                    • matt gelbwaks
                      I am with you Jeff. We are a large Argentine IT Outsourcer working with clients on 4 continents. Some have never been to our HQ, never the less walked down to
                      Message 10 of 21 , Aug 6, 2007
                      • 0 Attachment
                        I am with you Jeff.
                        We are a large Argentine IT Outsourcer working with clients on 4 continents.  Some have never been to our HQ, never the less walked down to the PM's office to see a burndown.  It is funny to hear some of the rants people have against modifying Scrum or XP or Agile to suit your enterprise or organization.  It is also funny to hear people hold the line on these methodologies being meant for small collocated teams only and therefore you can't use software to automate certain aspects of the approach.  I get much mirth out of this last one because it so seems that people forget what we are doing - we are building software to automate tasks that people can no longer do without automation.  We are a global community now, IT is, so we need to automate certain aspects of it.  You are also quite correct in that we must understand all the deviations we make.  I am having this conversation right now with our internal and external assessors to teach them that, through moderation, we can be both Agile and CMMI.  And we can, and we will.  Just like you can have an excel spreadsheet for your burndown chart (with automated trend lines!!!!).
                        Ping me off list if you still need a template.

                        m

                        On 8/6/07, Jeff Martin <jmartin@...> wrote:

                        Except when the CFO emails you and asks you how the project is going, "walk down to my office and look on the wall" is not the answer he's looking for.  Or when he wants to include the development status in his monthly board meeting, we are a small chart on a page with a lot of other charts and information.  I'm not going to ask him to drag in a giant piece of paper with my scribbled drawings on it. 

                         

                        Warning: small rant is ahead and this is in no way aimed at you Ilja, I value everyone's advice on this mailing list.  I've done a significant amount of reading on agile and Scrum in particular and I read most of the messages that come through this mailing list.  There seems to be this contingent of the community that believe anything more than index cards and hand drawn charts are sacrilege.  Now, I agree that concentrating more on the tools than the actual development of the product is definitely not a good thing.  And the first value of agile is "Individuals and interactions over processes and tools."  But it even states that there is value in the processes and tools, just more value in the individuals and interactions.  If the individuals involved prefer to track their tasks in a software tool rather than on an index card, then that's what they should do.  If the product owner prefers to see the burndown as an Excel chart that can be printed, copied and pasted and emailed over a hand drawn chart, then that's what should happen.  I don't understand the aversion to using software in the process.  We spend our entire career telling companies that we can write software to improve their businesses and processes, but we're saying we can't improve our own?  That our process is better with index cards and cork boards?  It's very true that most of the "agile" tools on the market are not agile and either have too much or not enough.  But that doesn't mean that any use of software is A Bad Thing©.  

                         

                        Isn't the entire point of agile development to do what works for your team?  This thought process that thinks you can't be agile if you are using a software package to track tasks or you aren't collocated or if you don't follow the rules to the letter or you have fewer or more than 5-9 people on the team.  I'm calling bull on that.  Agile is about doing what works the best.  If we all follow the same rules, we're no better off than we were before.  If we all do agile the right way, that probably means that we'll all be doing things a little differently than each other.  One thing I will concede is that everyone should start off as simple as possible.  I am a firm believer in the concept of knowing why you are breaking the rules before you start breaking them. 

                         

                        Once again, this is not directed at you Ilja.  It's just the result of a lot of different emails and blog posts. 

                         

                        jeff

                         

                         

                        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroup s.com] On Behalf Of Ilja Preuss
                        Sent: Saturday, August 04, 2007 12:32 PM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: Re: [scrumdevelopment] Release Burndown chart in Excel

                         

                        Jeff Martin wrote:
                        > I've written one using a charting component, but I'm trying to keep
                        > things simple and keeping it in Excel is the simplest path.

                        In my experience, for those kinds of charts, manually drawn diagrams on
                        flip chart paper, put on a wall for everyone to see, works even better.

                        Cheers, Ilja



                      • Neeraj Deginal
                        I think people are sharing more of their experiences. Using software or doing it manually is purely individual/team s preference and requirement. SCRUM does
                        Message 11 of 21 , Aug 6, 2007
                        • 0 Attachment

                          I think people are sharing more of their experiences. Using software or doing it manually is purely individual/team’s preference and requirement. SCRUM does not define any rule as such. I agree that any methodology we use should help us get better results.

                           

                          Neeraj

                           

                          -----Original Message-----
                          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of matt gelbwaks
                          Sent: Tuesday, August 07, 2007 5:48 AM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: [SPAM] Re: [scrumdevelopment] Release Burndown chart in Excel
                          Importance: Low

                           

                          I am with you Jeff.
                          We are a large Argentine IT Outsourcer working with clients on 4 continents.  Some have never been to our HQ, never the less walked down to the PM's office to see a burndown.  It is funny to hear some of the rants people have against modifying Scrum or XP or Agile to suit your enterprise or organization.  It is also funny to hear people hold the line on these methodologies being meant for small collocated teams only and therefore you can't use software to automate certain aspects of the approach.  I get much mirth out of this last one because it so seems that people forget what we are doing - we are building software to automate tasks that people can no longer do without automation.  We are a global community now, IT is, so we need to automate certain aspects of it.  You are also quite correct in that we must understand all the deviations we make.  I am having this conversation right now with our internal and external assessors to teach them that, through moderation, we can be both Agile and CMMI.  And we can, and we will.  Just like you can have an excel spreadsheet for your burndown chart (with automated trend lines!!!!).
                          Ping me off list if you still need a template.

                          m

                          On 8/6/07, Jeff Martin <jmartin@ssr- inc.com> wrote:

                          Except when the CFO emails you and asks you how the project is going, "walk down to my office and look on the wall" is not the answer he's looking for.  Or when he wants to include the development status in his monthly board meeting, we are a small chart on a page with a lot of other charts and information.  I'm not going to ask him to drag in a giant piece of paper with my scribbled drawings on it. 

                           

                          Warning: small rant is ahead and this is in no way aimed at you Ilja, I value everyone's advice on this mailing list.  I've done a significant amount of reading on agile and Scrum in particular and I read most of the messages that come through this mailing list.  There seems to be this contingent of the community that believe anything more than index cards and hand drawn charts are sacrilege.  Now, I agree that concentrating more on the tools than the actual development of the product is definitely not a good thing.  And the first value of agile is "Individuals and interactions over processes and tools."  But it even states that there is value in the processes and tools, just more value in the individuals and interactions.  If the individuals involved prefer to track their tasks in a software tool rather than on an index card, then that's what they should do.  If the product owner prefers to see the burndown as an Excel chart that can be printed, copied and pasted and emailed over a hand drawn chart, then that's what should happen.  I don't understand the aversion to using software in the process.  We spend our entire career telling companies that we can write software to improve their businesses and processes, but we're saying we can't improve our own?  That our process is better with index cards and cork boards?  It's very true that most of the "agile" tools on the market are not agile and either have too much or not enough.  But that doesn't mean that any use of software is A Bad Thing©.  

                           

                          Isn't the entire point of agile development to do what works for your team?  This thought process that thinks you can't be agile if you are using a software package to track tasks or you aren't collocated or if you don't follow the rules to the letter or you have fewer or more than 5-9 people on the team.  I'm calling bull on that.  Agile is about doing what works the best.  If we all follow the same rules, we're no better off than we were before.  If we all do agile the right way, that probably means that we'll all be doing things a little differently than each other.  One thing I will concede is that everyone should start off as simple as possible.  I am a firm believer in the concept of knowing why you are breaking the rules before you start breaking them. 

                           

                          Once again, this is not directed at you Ilja.  It's just the result of a lot of different emails and blog posts. 

                           

                          jeff

                           

                           

                          From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelopment@yahoogroup s.com] On Behalf Of Ilja Preuss
                          Sent: Saturday, August 04, 2007 12:32 PM
                          To: scrumdevelopment@ yahoogroups. com
                          Subject: Re: [scrumdevelopment] Release Burndown chart in Excel

                           

                          Jeff Martin wrote:

                          > I've written one using a charting component, but I'm trying to keep
                          > things simple and keeping it in Excel is the simplest path.

                          In my experience, for those kinds of charts, manually drawn diagrams on
                          flip chart paper, put on a wall for everyone to see, works even better.

                          Cheers, Ilja


                           

                        • Petri Heiramo
                          I agree with what Jeff said. ... Every project has stakeholders whose needs it must satisfy. I wouldn t call that a general requirement, but an environmental
                          Message 12 of 21 , Aug 7, 2007
                          • 0 Attachment
                            I agree with what Jeff said.

                            > Except when the CFO emails you and asks you how the project is going,
                            > "walk down to my office and look on the wall" is not the answer he's
                            > looking for. Or when he wants to include the development status in his
                            > monthly board meeting, we are a small chart on a page with a lot of
                            > other charts and information. I'm not going to ask him to drag in a
                            > giant piece of paper with my scribbled drawings on it.

                            Every project has stakeholders whose needs it must satisfy. I wouldn't
                            call that a general requirement, but an environmental variable that
                            favors using tools that do provide the needed information in desired
                            format. I'm sure the team would understand that, and take the effort
                            to use the necessary tools (I mean, wow, the CEO is taking interest in
                            our progress!).

                            > Warning: small rant is ahead and this is in no way aimed at you Ilja, I
                            > value everyone's advice on this mailing list. I've done a significant
                            > amount of reading on agile and Scrum in particular and I read most of
                            > the messages that come through this mailing list. There seems to be
                            > this contingent of the community that believe anything more than index
                            > cards and hand drawn charts are sacrilege. Now, I agree that
                            > concentrating more on the tools than the actual development of the
                            > product is definitely not a good thing. And the first value of agile is
                            > "Individuals and interactions over processes and tools." But it even
                            > states that there is value in the processes and tools, just more value
                            > in the individuals and interactions. If the individuals involved prefer
                            > to track their tasks in a software tool rather than on an index card,
                            > then that's what they should do. If the product owner prefers to see
                            > the burndown as an Excel chart that can be printed, copied and pasted
                            > and emailed over a hand drawn chart, then that's what should happen. I
                            > don't understand the aversion to using software in the process. We
                            > spend our entire career telling companies that we can write software to
                            > improve their businesses and processes, but we're saying we can't
                            > improve our own? That our process is better with index cards and cork
                            > boards? It's very true that most of the "agile" tools on the market are
                            > not agile and either have too much or not enough. But that doesn't mean
                            > that any use of software is A Bad Thing(c).

                            Long quote, but that's exactly what I've seen happen in our projects.
                            There are teams that prefer the visual wall boards and teams that like
                            to use some tool, even when all those teams are co-located. Dispersed
                            teams are a different matter, obviously. Tools are often necessary;
                            e.g. you can't automate testing without appropriate and effective tools.

                            > Isn't the entire point of agile development to do what works for your
                            > team? This thought process that thinks you can't be agile if you are
                            > using a software package to track tasks or you aren't collocated or if
                            > you don't follow the rules to the letter or you have fewer or more than
                            > 5-9 people on the team. I'm calling bull on that. Agile is about doing
                            > what works the best.

                            Exactly, but that doesn't stop me from recommending every collocated
                            team to test out the wall chart technique. Of course I say that there
                            are also tools, which they can then try out if the manual technique
                            doesn't suit them. Even then I've seen teams go to tools immediately
                            :), which is fine of course.


                            Petri Heiramo
                            Process Improvement Manager
                            SYSOPENDIGIA Plc., Finland
                          • Ilja Preuss
                            ... Then don t answer that. The team (assuming that it s colocated) still needs it on the wall, in my experience. ... Then he should somehow get that small
                            Message 13 of 21 , Aug 8, 2007
                            • 0 Attachment
                              Jeff Martin wrote:
                              > Except when the CFO emails you and asks you how the project is going,
                              > “walk down to my office and look on the wall” is not the answer he’s
                              > looking for.

                              Then don't answer that. The team (assuming that it's colocated) still
                              needs it on the wall, in my experience.

                              > Or when he wants to include the development status in his
                              > monthly board meeting, we are a small chart on a page with a lot of
                              > other charts and information.

                              Then he should somehow get that small chart on the page. Which just
                              means that he simply can't use the chart the team is using as-is.

                              > I’m not going to ask him to drag in a
                              > giant piece of paper with my scribbled drawings on it.

                              Agreed. I don't know anyone who suggested it.


                              > There seems to be
                              > this contingent of the community that believe anything more than index
                              > cards and hand drawn charts are sacrilege.

                              My impression is that that contingent is *very* small, and that it often
                              gets confused with those who believe that people who never have tried
                              index cards and hand drawn charts for a significant amount of time are
                              in a bad position to assess their importance.

                              > Now, I agree that
                              > concentrating more on the tools than the actual development of the
                              > product is definitely not a good thing. And the first value of agile is
                              > “Individuals and interactions over processes and tools.” But it even
                              > states that there is value in the processes and tools, just more value
                              > in the individuals and interactions. If the individuals involved prefer
                              > to track their tasks in a software tool rather than on an index card,
                              > then that’s what they should do.

                              That's tricky, because there actually is a lot of evidence that software
                              tools really don't support individuals *and their interactions* as well
                              as more low tech tools do.

                              Still, if the individuals have tried the low tech way for a reasonable
                              amount of time, have seriously tried to make them work, and still prefer
                              software tools, more power to them. Many that prefer software tools
                              don't seem to do it out of that much experience, but rather out of what
                              they imagine how low tech tools would work.

                              > If the product owner prefers to see
                              > the burndown as an Excel chart that can be printed, copied and pasted
                              > and emailed over a hand drawn chart, then that’s what should happen.

                              If my product owner would prefer that, I would still do a low tech
                              version for the team, because that's what the team needs to be
                              effective. The product owner, of course, would have the option to
                              request a high fidelity chart - and he would know exactly what that
                              costs him, so that he can make the decision sensibly.

                              > I
                              > don’t understand the aversion to using software in the process. We
                              > spend our entire career telling companies that we can write software to
                              > improve their businesses and processes, but we’re saying we can’t
                              > improve our own? That our process is better with index cards and cork
                              > boards? It’s very true that most of the “agile” tools on the market are
                              > not agile and either have too much or not enough. But that doesn’t mean
                              > that any use of software is A Bad Thing©.

                              I'm using a lot of software: compiler, IDE, debugger, profiler, version
                              control, email, wiki, blog, webbrowser etc. pp. Not using those tools
                              would be unprofessional.

                              It's important to note, though, that not for every problem the best
                              solution is a software solution. Insisting on using a software tool in
                              those cases, would be as unprofessional.


                              > Isn’t the entire point of agile development to do what works for your
                              > team?

                              No, I don't think that's the entire point of Agile.

                              > I am a firm believer in the concept of knowing
                              > why you are breaking the rules before you start breaking them.

                              I'm a firm believer of trying *very* hard to not break the rules, even
                              if at first sight it seems like I have to. I think that way I learn much
                              more about what the boundaries really are...


                              > Once again, this is not directed at you Ilja. It’s just the result of a
                              > lot of different emails and blog posts.

                              Understood. Ditto here... ;)


                              No hard feelings,

                              Ilja
                            • Ilja Preuss
                              ... Part of that is coming from experience with people who modify the approach without understanding how the original works - see
                              Message 14 of 21 , Aug 8, 2007
                              • 0 Attachment
                                matt gelbwaks wrote:
                                > It is funny to hear some of the
                                > rants people have against modifying Scrum or XP or Agile to suit your
                                > enterprise or organization.

                                Part of that is coming from experience with people who modify the
                                approach without understanding how the original works - see
                                http://www.xprogramming.com/xpmag/jatBaseball.htm for a humorous take on it.

                                Of course there are also valid reasons for modifying the game - if you
                                were playing on the moon, for example, you probably had to apply heavy
                                modifications to make it work at all. I wouldn't be surprised if
                                baseball fans would be kind of upset if the resulting game still would
                                be called baseball.



                                > It is also funny to hear people hold the
                                > line on these methodologies being meant for small collocated teams only

                                What's funny about that???

                                > and therefore you can't use software to automate certain aspects of the
                                > approach.

                                I have never seen the reasoning that way.

                                It's certainly true, though, that to the extent that your team being big
                                or distributed forces you to use software tools, you simply can't be as
                                Agile as smaller, colocated teams. Does that thought trouble you?

                                > I get much mirth out of this last one because it so seems
                                > that people forget what we are doing - we are building software to
                                > automate tasks that people can no longer do without automation.

                                I'm not forgetting that at all. Does that mean that we should blindly
                                use software to automate everything, whithout caring about whether it
                                seems to be effective or not? Or what else are you getting at here?

                                > We are
                                > a global community now, IT is, so we need to automate certain aspects of
                                > it.

                                All Agile proponents are saying, as far as I can tell, is that being
                                distributed will invariably make you less effective - partly because you
                                will have to use software tools instead of more direct forms of
                                communication and collaboration.

                                Is that something you disagree with?

                                > Just like you
                                > can have an excel spreadsheet for your burndown chart (with automated
                                > trend lines!!!!).

                                Sure you can. I deem it to be interesting to talk about the pros and
                                cons of doing so, but that might just be me.

                                Cheers, Ilja
                              • Ilja Preuss
                                Well, I simply don t have experience with such teams; and it doesn t seem to fit my for everyone to see constraint - unless you are using a webcam, an
                                Message 15 of 21 , Aug 8, 2007
                                • 0 Attachment
                                  Well, I simply don't have experience with such teams; and it doesn't
                                  seem to fit my "for everyone to see" constraint - unless you are using a
                                  webcam, an electronic whiteboard, or something similar, in which case I
                                  could imagine it to actually work again...

                                  Marco Milone wrote:
                                  > Until you start having people working from home or dispersed teams.
                                  >
                                  > Regards,
                                  >
                                  > Marco
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  > ------------------------------------------------------------------------
                                  >
                                  > *From:* scrumdevelopment@yahoogroups.com
                                  > [mailto:scrumdevelopment@yahoogroups.com] *On Behalf Of *Ilja Preuss
                                  > *Sent:* 04 August 2007 18:32
                                  > *To:* scrumdevelopment@yahoogroups.com
                                  > *Subject:* Re: [scrumdevelopment] Release Burndown chart in Excel
                                  >
                                  >
                                  >
                                  > Jeff Martin wrote:
                                  >> I've written one using a charting component, but I'm trying to keep
                                  >> things simple and keeping it in Excel is the simplest path.
                                  >
                                  > In my experience, for those kinds of charts, manually drawn diagrams on
                                  > flip chart paper, put on a wall for everyone to see, works even better.
                                  >
                                  > Cheers, Ilja
                                  >
                                  >
                                  > For the most important conference on Software testing and quality visit
                                  > www.sqs-conferences.com
                                  >
                                  > This e-mail may contain confidential and/or privileged information. If
                                  > you are not the intended recipient (or have received this e-mail in
                                  > error) please notify the sender immediately and destroy this e-mail. Any
                                  > unauthorised copying, disclosure or distribution of the material in this
                                  > e-mail is strictly forbidden.
                                  >
                                  > SQS-UK: SQS Group Limited | Incorporated in England and Wales |
                                  > Registered No. 2857864 | VAT No. 788 1795 61
                                  > SQS-Ire: SQS Software Quality Systems (Ireland) Limited | Incorporated
                                  > in Ireland | Registered No. 307763 | Vat No. IE6327763G
                                  > SQS-SA: South African Branch office of SQS Group Limited | Registered in
                                  > South Africa | Registered No. 2004/010639/10 | Vat No. 40602176781
                                  >
                                • matt gelbwaks
                                  This type of conversation/argument is easier in person, as simple misunderstandings of emphasis are easily clarified. I certainly agree with you on most of
                                  Message 16 of 21 , Aug 8, 2007
                                  • 0 Attachment
                                    This type of conversation/argument is easier in person, as simple misunderstandings of emphasis are easily clarified. 

                                    I certainly agree with you on most of your points, as you seem to be agreeing and accentuating mine.

                                    One point I would like to clarify, though: there are no absolutes in any business where people are involved.  You state

                                    to the extent that your team being big
                                    or distributed forces you to use software tools, you simply can't be as
                                    Agile as smaller, colocated teams.






                                    I have worked with both functional and disfunctional teams, large and small.  Many improved for my presence (though not all).  Some big teams had stunning thoughput with low overhead.  Some small teams were so poorly gelled and motivated that their through put  was nearly non-existent.  This doesn't trouble me.  I always say that a good coach has enough experience to be able to look at any team and quickly make some changes to increase their throughput.  In some cases it may be automating software, in others, it maybe some exercises to increase trust or understanding.  But in no case, does the thought bother me.  I never try to achieve the theoretical maximum - I just want to see the team go far enough up the curve so that their productivity is on the level part of the asymptote. 


                                    Your last point:

                                    All Agile proponents are saying, as far as I can tell, is that being
                                    distributed will invariably make you less effective - partly because you
                                    will have to use software tools instead of more direct forms of
                                    communication and collaboration.




                                     


                                    is very valid, though I would point out merely that it is "tools" not "software tools" that you must use (phones, video links, web meetings, as well as spreadsheets, tracking tools, etc).


                                    m

                                  • Roy Morien
                                    I am sometimes amazed, and sometimes puzzled, and sometimes amused at the discussions that occur here. However, the participants are clearly seekers after
                                    Message 17 of 21 , Aug 8, 2007
                                    • 0 Attachment
                                      I am sometimes amazed, and sometimes puzzled, and sometimes amused at the discussions that occur here. However, the participants are clearly 'seekers after knowledge' and that is good.
                                       
                                      But there does seem to be a lot of obsessing about things, unnecessarily.
                                       
                                      Take this discussion about the use of project management, or project reporting software.
                                       
                                      In all my reading about agile development and lean development, I have never seen anything that is essentially anti-automation, or anti-software use. What I have seen is a clear warning against becoming too enmeshed in the use of apparently sophisticated software packages, when a non-technical, or simple solution is useful. One good example of this is the discussion in various places about the use of sophisticated MRP software, versus simple 'flags' or visual signals indicating the need to replenish the component bin at a workstation, or to inform people of some thing or another.
                                       
                                      One of the problems of using 'sophisticated' software packages (maybe read 'complex' packages) is that it is the ability to use the package, and the amount of time and effort needed to keep the package information up to date, that becomes the most important issue, or the most time consuming activity. Some people love the package because it provides lots of reports that make them appear important because of the size of the stack of output that they routinely receive. And that can imply an enormous effort to 'feed the beast' with data that is necessary for those reports.
                                       
                                      So it really is a matter of "what works, use", for your environment. Answering a viewpoint that paper wall charts are all that is necessary for small teams, by talking about the needs of large teams that are distributed around the globe in different time zones is just not relevant.





                                      To: scrumdevelopment@yahoogroups.com
                                      From: it@...
                                      Date: Wed, 8 Aug 2007 21:31:25 +0200
                                      Subject: Re: [scrumdevelopment] Release Burndown chart in Excel

                                      matt gelbwaks wrote:
                                      > It is funny to hear some of the
                                      > rants people have against modifying Scrum or XP or Agile to suit your
                                      > enterprise or organization.

                                      Part of that is coming from experience with people who modify the
                                      approach without understanding how the original works - see
                                      http://www.xprogram ming.com/ xpmag/jatBasebal l.htm for a humorous take on it.

                                      Of course there are also valid reasons for modifying the game - if you
                                      were playing on the moon, for example, you probably had to apply heavy
                                      modifications to make it work at all. I wouldn't be surprised if
                                      baseball fans would be kind of upset if the resulting game still would
                                      be called baseball.

                                      > It is also funny to hear people hold the
                                      > line on these methodologies being meant for small collocated teams only

                                      What's funny about that???

                                      > and therefore you can't use software to automate certain aspects of the
                                      > approach.

                                      I have never seen the reasoning that way.

                                      It's certainly true, though, that to the extent that your team being big
                                      or distributed forces you to use software tools, you simply can't be as
                                      Agile as smaller, colocated teams. Does that thought trouble you?

                                      > I get much mirth out of this last one because it so seems
                                      > that people forget what we are doing - we are building software to
                                      > automate tasks that people can no longer do without automation.

                                      I'm not forgetting that at all. Does that mean that we should blindly
                                      use software to automate everything, whithout caring about whether it
                                      seems to be effective or not? Or what else are you getting at here?

                                      > We are
                                      > a global community now, IT is, so we need to automate certain aspects of
                                      > it.

                                      All Agile proponents are saying, as far as I can tell, is that being
                                      distributed will invariably make you less effective - partly because you
                                      will have to use software tools instead of more direct forms of
                                      communication and collaboration.

                                      Is that something you disagree with?

                                      > Just like you
                                      > can have an excel spreadsheet for your burndown chart (with automated
                                      > trend lines!!!!).

                                      Sure you can. I deem it to be interesting to talk about the pros and
                                      cons of doing so, but that might just be me.

                                      Cheers, Ilja



                                      Discover the new Windows Vista Learn more!
                                    • Ilja Preuss
                                      ... So true! ... Ok. ... I totally agree. I can t imagine that you would typically improve a dysfunctional team by adding people (although just the right
                                      Message 18 of 21 , Aug 19, 2007
                                      • 0 Attachment
                                        matt gelbwaks wrote:
                                        > This type of conversation/argument is easier in person, as simple
                                        > misunderstandings of emphasis are easily clarified.

                                        So true!

                                        > I certainly agree with you on most of your points, as you seem to be
                                        > agreeing and accentuating mine.

                                        Ok.

                                        > One point I would like to clarify, though: there are no absolutes in any
                                        > business where people are involved. You state
                                        >
                                        > to the extent that your team being big
                                        > or distributed forces you to use software tools, you simply can't be as
                                        > Agile as smaller, colocated teams.
                                        >
                                        > I have worked with both functional and disfunctional teams, large and
                                        > small. Many improved for my presence (though not all). Some big teams
                                        > had stunning thoughput with low overhead. Some small teams were so
                                        > poorly gelled and motivated that their through put was nearly
                                        > non-existent. This doesn't trouble me. I always say that a good coach
                                        > has enough experience to be able to look at any team and quickly make
                                        > some changes to increase their throughput. In some cases it may be
                                        > automating software, in others, it maybe some exercises to increase
                                        > trust or understanding. But in no case, does the thought bother me. I
                                        > never try to achieve the theoretical maximum - I just want to see the
                                        > team go far enough up the curve so that their productivity is on the
                                        > level part of the asymptote.

                                        I totally agree. I can't imagine that you would typically improve a
                                        dysfunctional team by adding people (although just the right person
                                        might actually work), or by distributing the team members, though. I can
                                        imagine the opposite.

                                        > Your last point:
                                        >
                                        > All Agile proponents are saying, as far as I can tell, is that being
                                        > distributed will invariably make you less effective - partly because
                                        > you
                                        > will have to use software tools instead of more direct forms of
                                        > communication and collaboration.
                                        >
                                        > is very valid, though I would point out merely that it is "tools" not
                                        > "software tools" that you must use (phones, video links, web meetings,
                                        > as well as spreadsheets, tracking tools, etc).

                                        "Software tools" wasn't meant exclusively, of course.

                                        Cheers, Ilja
                                      • Ilja Preuss
                                        ... obsession, noun: a persistent disturbing preoccupation with an often unreasonable idea or feeling I d suggest that, as long as you label an idea that
                                        Message 19 of 21 , Aug 19, 2007
                                        • 0 Attachment
                                          Roy Morien wrote:

                                          > But there does seem to be a lot of obsessing about things, unnecessarily.

                                          "obsession, noun: a persistent disturbing preoccupation with an often
                                          unreasonable idea or feeling"

                                          I'd suggest that, as long as you label an idea that comes up in a
                                          discussion as an obsession, you are unlikely to learn much about the
                                          real motivations of the other side.

                                          > Take this discussion about the use of project management, or project
                                          > reporting software.
                                          >
                                          > In all my reading about agile development and lean development, I have
                                          > never seen anything that is essentially anti-automation, or
                                          > anti-software use.

                                          Not anti, certainly not. But there is this "people over tools" thing in
                                          the manifesto...

                                          > What I have seen is a clear warning against becoming
                                          > too enmeshed in the use of apparently sophisticated software packages,
                                          > when a non-technical, or simple solution is useful.

                                          I don't think that cards are just useful. I think in many cases, they
                                          have significant benefits (besides just being simple).

                                          > One of the problems of using 'sophisticated' software packages (maybe
                                          > read 'complex' packages) is that it is the ability to use the package,
                                          > and the amount of time and effort needed to keep the package information
                                          > up to date, that becomes the most important issue, or the most time
                                          > consuming activity.

                                          That is certainly one problem, but actually not the one I'd worry most
                                          about.

                                          > Some people love the package because it provides
                                          > lots of reports that make them appear important because of the size of
                                          > the stack of output that they routinely receive. And that can imply an
                                          > enormous effort to 'feed the beast' with data that is necessary for
                                          > those reports.

                                          Let's face it - most of us are geeks - we just love technology. So when
                                          we see some, we want to try it.

                                          A software developers primary job (and probably what he gets his job
                                          satisfaction from) is making a machine do the work. So they naturally
                                          shy away from doing something manually when there is software that is
                                          supposed to do it.

                                          Still, there are problems for which non-software-solutations are best.
                                          In my experience, most software people won't believe that *their*
                                          problem is one of those, until they've tried the non-software solution
                                          for some time.

                                          > So it really is a matter of "what works, use", for your environment.

                                          To me, that doesn't suffice. I want to find out what works *better* than
                                          what we are currently doing. And in my experience, that includes trying
                                          low-tech solutions - even if sometimes it seems counterintuitive at
                                          first sight.

                                          > Answering a viewpoint that paper wall charts are all that is necessary
                                          > for small teams, by talking about the needs of large teams that are
                                          > distributed around the globe in different time zones is just not relevant.

                                          Most often, the discussion actually seems to work this way:

                                          A: What tools are best for X? (No mention of a distributed team at all.)
                                          B: Software Y is great!
                                          C: In my experience, index cards work best.
                                          D: But you can't use index cards with distributed teams!

                                          That's what's puzzling *me*...

                                          Cheers, Ilja
                                        Your message has been successfully submitted and would be delivered to recipients shortly.