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

RE: [scrumdevelopment] Release Burndown chart in Excel

Expand Messages
  • Jeff Martin
    Nevermind, I figured out how to do it in Excel. If anyone is interested, email me and I will send you the file. ________________________________ From:
    Message 1 of 21 , Aug 1, 2007
    • 0 Attachment
      Nevermind, I figured out how to do it in Excel.  If anyone is interested, email me and I will send you the file.


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Jeff Martin
      Sent: Wednesday, August 01, 2007 10:29 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Release Burndown chart in Excel

      Does anyone have a template or example of how to create an alternative release burndown chart described by Mike Cohn at http://www.mountain goatsoftware. com/alt_releaseb urndown?
       
      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.
       

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