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

2009 Agile Practice Adoption Survey -- Chance to Win a Copy of "Stand Back and Deliver"

Expand Messages
  • Scott Ambler
    Mike Vizdos and I would like to invite you spend a few moments taking the 2009 Agile Practice Adoption survey at
    Message 1 of 14 , Jul 8, 2009
    • 0 Attachment
      Mike Vizdos and I would like to invite you spend a few moments taking the 2009 Agile Practice Adoption survey at http://www.surveymonkey.com/s.aspx?sm=3lZZ3fYRxvV3y6XsnXPDEw_3d_3d . The goal of this survey is to find out what practices agile practitioners find useful, which they're finding difficult to adopt, and which they're abandoning. There are 17 questions in this survey, although you may not be asked all of them, and it should take you at most 5 minutes to complete.

      To entice you to fill out the survey we'll be drawing for 10 copies of "Stand Back and Deliver: Accelerating Business Agility" by Pollyanna Pixton, Niel Nickolaisen, Todd Little, and Kent McDonald published in June 2009 by Addison Wesley. I've been reading through this book the past few days and I'm finding a lot of great insights in it. More information can be found at http://www.informit.com/store/product.aspx?isbn=0321572882

      The results of this survey will be summarized in my "Agile by the Numbers" presentation at Agile 2009 in Chicago (Aug 24-28). Furthermore, this is an open survey, so the source data (without identifying information to protect your privacy), a summary slide deck, and the original source questions will be posted at www.ambysoft.com/surveys/ so that others may analyze the data for their own purposes. Data from previous surveys have been used by university students and professors for their research papers, and hopefully the same will be true of the data from this survey. The results from several other surveys are already posted there, so please feel free to take advantage of this resource.

      We apologize if you've received several copies of this request.

      - Scott
      Scott W. Ambler
      Chief Methodologist/Agile, IBM Rational
      Agile at Scale: http://www.ibm.com/developerworks/blogs/page/ambler


      __________________________________________________________________
      Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
      http://ca.toolbar.yahoo.com
    • Scott Ambler
      I just wanted to thank those of you who participated in the survey. As I indicated earlier, the results of this survey will be included in my Agile by the
      Message 2 of 14 , Jul 20, 2009
      • 0 Attachment
        I just wanted to thank those of you who participated in the survey. As I indicated earlier, the results of this survey will be included in my "Agile by the Numbers" presentation at Agile 2009, see http://www.agile2009.org/node/263 . After the presentation the details from this survey will be posted at http://www.ambysoft.com/surveys/practices2009.html as I usually do.

        To give you a feel for the results of the survey, some of the findings (which I'll expand upon in August) include:
        1. The three practices which are seen as most effective were Continuous Integration (CI), Daily Stand Up Meetings, and Developer Test-Driven Development (TDD).
        2. The three practices which are seen as easiest to learn are Daily Stand Up Meeting, Continuous Integration (CI), and Iteration Planning.
        3. The three practices which are seen as hardest to learn are Developer TDD, Acceptance/Story TDD, and Pair Programming.
        4. The three practices which were most likely to be tried and then abandoned were Pair Programming, Burndown Tracking, and Potentially Shippable Software Each Iteration.
        5. The three practices which people want to adopt but have not yet done so were Acceptance TDD, Potentially Shippable Software Each Iteration, and Developer TDD.

        If you're thinking about running a survey, I've posted some thoughts at http://www.ambysoft.com/surveys/agileSurveys.html which might prove helpful. Feedback is always appreciated.

        Also, I've sent emails to the ten winners of "Stand Back and Deliver", so if you haven't recieved an email you haven't won. Better luck next time!

        - Scott
        Scott W. Ambler
        Chief Methodologist/Agile, IBM Rational
        Agile at Scale: http://www.ibm.com/developerworks/blogs/page/ambler
        --- In extremeprogramming@yahoogroups.com, Scott Ambler <scottwambler@...> wrote:
        >
        >
        > Mike Vizdos and I would like to invite you spend a few moments taking the 2009 Agile Practice Adoption survey at http://www.surveymonkey.com/s.aspx?sm=3lZZ3fYRxvV3y6XsnXPDEw_3d_3d . The goal of this survey is to find out what practices agile practitioners find useful, which they're finding difficult to adopt, and which they're abandoning. There are 17 questions in this survey, although you may not be asked all of them, and it should take you at most 5 minutes to complete.
        >
        > To entice you to fill out the survey we'll be drawing for 10 copies of "Stand Back and Deliver: Accelerating Business Agility" by Pollyanna Pixton, Niel Nickolaisen, Todd Little, and Kent McDonald published in June 2009 by Addison Wesley. I've been reading through this book the past few days and I'm finding a lot of great insights in it. More information can be found at http://www.informit.com/store/product.aspx?isbn=0321572882
        >
        > The results of this survey will be summarized in my "Agile by the Numbers" presentation at Agile 2009 in Chicago (Aug 24-28). Furthermore, this is an open survey, so the source data (without identifying information to protect your privacy), a summary slide deck, and the original source questions will be posted at www.ambysoft.com/surveys/ so that others may analyze the data for their own purposes. Data from previous surveys have been used by university students and professors for their research papers, and hopefully the same will be true of the data from this survey. The results from several other surveys are already posted there, so please feel free to take advantage of this resource.
        >
        >
      • David H.
        ... That seems top paint quite a sorry picture of the state the world of agile adoption is in. Oh well... -- Sent from gmail so do not trust this
        Message 3 of 14 , Jul 20, 2009
        • 0 Attachment
          > 4. The three practices which were most likely to be tried and then
          > abandoned were Pair Programming, Burndown Tracking, and Potentially
          > Shippable Software Each Iteration.


          That seems top paint quite a sorry picture of the state the world of agile
          adoption is in. Oh well...

          --
          Sent from gmail so do not trust this communication.
          Do not send me sensitive information here, ask for my none-gmail accounts.

          "Therefore the considerations of the intelligent always include both benefit
          and harm." - Sun Tzu


          [Non-text portions of this message have been removed]
        • Scott Ambler
          ... I see organizations abandon non-solo development strategies such as pair programming all the time. Too many people aren t willing to give it enough time
          Message 4 of 14 , Jul 20, 2009
          • 0 Attachment
            --- In extremeprogramming@yahoogroups.com, "David H." <dmalloc@...> wrote:
            >
            > > 4. The three practices which were most likely to be tried and then
            > > abandoned were Pair Programming, Burndown Tracking, and Potentially
            > > Shippable Software Each Iteration.
            >
            >
            > That seems top paint quite a sorry picture of the state the world of agile
            > adoption is in. Oh well...

            I see organizations abandon non-solo development strategies such as pair programming all the time. Too many people aren't willing to give it enough time to take hold, and too many people think that it reduces productivity.

            I was surprised by burndown tracking seeing as it's a fairly straightforward thing. Granted, it's part of the hidden bureaucracy in Scrum that people rarely talk about (in the situations where the burndown charts aren't being automatically generated by the tools that you're using at least) but perhaps the real issue is that many agile teams are finding other ways to achieve the same sort of goals.

            Potentially shippable software each iteration requires discipline on the part of the team. I can see how this is hard for a lot of teams to get their act together on, particularly when they're not been coached effectively (if at all).

            - Scott
          • woynam
            I believe the abandonment of burndowns is directly tied to the failure to deliver working software each iteration. Teams commit to too much, and fail to
            Message 5 of 14 , Jul 27, 2009
            • 0 Attachment
              I believe the abandonment of burndowns is directly tied to the failure to deliver working software each iteration.

              Teams commit to too much, and fail to deliver. The burndown stares you in the face every day telling you that you're not going to deliver what you promised.

              Rather than commit to less, the organization decides to shoot the messenger. We can't have that graph telling us every day what we can't do.

              Mark


              --- In extremeprogramming@yahoogroups.com, "Scott Ambler" <scottwambler@...> wrote:
              >
              > --- In extremeprogramming@yahoogroups.com, "David H." <dmalloc@> wrote:
              > >
              > > > 4. The three practices which were most likely to be tried and then
              > > > abandoned were Pair Programming, Burndown Tracking, and Potentially
              > > > Shippable Software Each Iteration.
              > >
              > >
              > > That seems top paint quite a sorry picture of the state the world of agile
              > > adoption is in. Oh well...
              >
              > I see organizations abandon non-solo development strategies such as pair programming all the time. Too many people aren't willing to give it enough time to take hold, and too many people think that it reduces productivity.
              >
              > I was surprised by burndown tracking seeing as it's a fairly straightforward thing. Granted, it's part of the hidden bureaucracy in Scrum that people rarely talk about (in the situations where the burndown charts aren't being automatically generated by the tools that you're using at least) but perhaps the real issue is that many agile teams are finding other ways to achieve the same sort of goals.
              >
              > Potentially shippable software each iteration requires discipline on the part of the team. I can see how this is hard for a lot of teams to get their act together on, particularly when they're not been coached effectively (if at all).
              >
              > - Scott
              >
            • jmilunsky
              The burndown for me is the single most important vehicle for success in Scrum in my opinion. If you don t have this and you won t ever get to a sustainable
              Message 6 of 14 , Jul 27, 2009
              • 0 Attachment
                The burndown for me is the single most important vehicle for success in Scrum in my opinion. If you don't have this and you won't ever get to a sustainable throughput and then everything starts to break down

                Jack
                www.agilebuddy.com
                blog.agilebuddy.com
                twitter.com/agilebuddy

                --- In extremeprogramming@yahoogroups.com, "woynam" <woyna@...> wrote:
                >
                >
                > I believe the abandonment of burndowns is directly tied to the failure to deliver working software each iteration.
                >
                > Teams commit to too much, and fail to deliver. The burndown stares you in the face every day telling you that you're not going to deliver what you promised.
                >
                > Rather than commit to less, the organization decides to shoot the messenger. We can't have that graph telling us every day what we can't do.
                >
                > Mark
                >
                >
                > --- In extremeprogramming@yahoogroups.com, "Scott Ambler" <scottwambler@> wrote:
                > >
                > > --- In extremeprogramming@yahoogroups.com, "David H." <dmalloc@> wrote:
                > > >
                > > > > 4. The three practices which were most likely to be tried and then
                > > > > abandoned were Pair Programming, Burndown Tracking, and Potentially
                > > > > Shippable Software Each Iteration.
                > > >
                > > >
                > > > That seems top paint quite a sorry picture of the state the world of agile
                > > > adoption is in. Oh well...
                > >
                > > I see organizations abandon non-solo development strategies such as pair programming all the time. Too many people aren't willing to give it enough time to take hold, and too many people think that it reduces productivity.
                > >
                > > I was surprised by burndown tracking seeing as it's a fairly straightforward thing. Granted, it's part of the hidden bureaucracy in Scrum that people rarely talk about (in the situations where the burndown charts aren't being automatically generated by the tools that you're using at least) but perhaps the real issue is that many agile teams are finding other ways to achieve the same sort of goals.
                > >
                > > Potentially shippable software each iteration requires discipline on the part of the team. I can see how this is hard for a lot of teams to get their act together on, particularly when they're not been coached effectively (if at all).
                > >
                > > - Scott
                > >
                >
              • Rob Park
                I find the comments in favor of burndowns interesting. To me, burndowns are only really necessary for multi-iteration releases... say for tracking the progress
                Message 7 of 14 , Jul 27, 2009
                • 0 Attachment
                  I find the comments in favor of burndowns interesting.
                  To me, burndowns are only really necessary for multi-iteration releases...
                  say for tracking the progress of a new feature initiative for a customer.

                  If they feel helpful in an iteration, then perhaps your iteration is too
                  long.
                  And generally, I'd question why your story board isn't telling you enough
                  already?

                  On Mon, Jul 27, 2009 at 8:40 AM, jmilunsky <jack@...> wrote:

                  > The burndown for me is the single most important vehicle for success in
                  > Scrum in my opinion. If you don't have this and you won't ever get to a
                  > sustainable throughput and then everything starts to break down
                  >
                  > Jack
                  > www.agilebuddy.com
                  > blog.agilebuddy.com
                  > twitter.com/agilebuddy
                  >
                  > --- In extremeprogramming@yahoogroups.com, "woynam" <woyna@...> wrote:
                  > >
                  > >
                  > > I believe the abandonment of burndowns is directly tied to the failure to
                  > deliver working software each iteration.
                  > >
                  > > Teams commit to too much, and fail to deliver. The burndown stares you in
                  > the face every day telling you that you're not going to deliver what you
                  > promised.
                  > >
                  > > Rather than commit to less, the organization decides to shoot the
                  > messenger. We can't have that graph telling us every day what we can't do.
                  > >
                  > > Mark
                  > >
                  > >
                  > > --- In extremeprogramming@yahoogroups.com, "Scott Ambler" <scottwambler@>
                  > wrote:
                  > > >
                  > > > --- In extremeprogramming@yahoogroups.com, "David H." <dmalloc@>
                  > wrote:
                  > > > >
                  > > > > > 4. The three practices which were most likely to be tried and then
                  > > > > > abandoned were Pair Programming, Burndown Tracking, and Potentially
                  > > > > > Shippable Software Each Iteration.
                  > > > >
                  > > > >
                  > > > > That seems top paint quite a sorry picture of the state the world of
                  > agile
                  > > > > adoption is in. Oh well...
                  > > >
                  > > > I see organizations abandon non-solo development strategies such as
                  > pair programming all the time. Too many people aren't willing to give it
                  > enough time to take hold, and too many people think that it reduces
                  > productivity.
                  > > >
                  > > > I was surprised by burndown tracking seeing as it's a fairly
                  > straightforward thing. Granted, it's part of the hidden bureaucracy in
                  > Scrum that people rarely talk about (in the situations where the burndown
                  > charts aren't being automatically generated by the tools that you're using
                  > at least) but perhaps the real issue is that many agile teams are finding
                  > other ways to achieve the same sort of goals.
                  > > >
                  > > > Potentially shippable software each iteration requires discipline on
                  > the part of the team. I can see how this is hard for a lot of teams to get
                  > their act together on, particularly when they're not been coached
                  > effectively (if at all).
                  > > >
                  > > > - Scott
                  > > >
                  > >
                  >
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to:
                  > extremeprogramming-unsubscribe@...
                  >
                  > ad-free courtesy of objectmentor.comYahoo! Groups Links
                  >
                  >
                  >
                  >


                  --
                  Rob
                  --
                  http://agileintention.blogspot.com
                  http://twitter.com/robpark


                  [Non-text portions of this message have been removed]
                • jmilunsky
                  in my entire career, I don t think i have ever had a single iteration release Jack www.agilebuddy.com blog.agilebuddy.com twitter.com/agilebuddy
                  Message 8 of 14 , Jul 27, 2009
                  • 0 Attachment
                    in my entire career, I don't think i have ever had a single iteration release

                    Jack
                    www.agilebuddy.com
                    blog.agilebuddy.com
                    twitter.com/agilebuddy

                    --- In extremeprogramming@yahoogroups.com, Rob Park <robert.d.park@...> wrote:
                    >
                    > I find the comments in favor of burndowns interesting.
                    > To me, burndowns are only really necessary for multi-iteration releases...
                    > say for tracking the progress of a new feature initiative for a customer.
                    >
                    > If they feel helpful in an iteration, then perhaps your iteration is too
                    > long.
                    > And generally, I'd question why your story board isn't telling you enough
                    > already?
                    >
                    > On Mon, Jul 27, 2009 at 8:40 AM, jmilunsky <jack@...> wrote:
                    >
                    > > The burndown for me is the single most important vehicle for success in
                    > > Scrum in my opinion. If you don't have this and you won't ever get to a
                    > > sustainable throughput and then everything starts to break down
                    > >
                    > > Jack
                    > > www.agilebuddy.com
                    > > blog.agilebuddy.com
                    > > twitter.com/agilebuddy
                    > >
                    > > --- In extremeprogramming@yahoogroups.com, "woynam" <woyna@> wrote:
                    > > >
                    > > >
                    > > > I believe the abandonment of burndowns is directly tied to the failure to
                    > > deliver working software each iteration.
                    > > >
                    > > > Teams commit to too much, and fail to deliver. The burndown stares you in
                    > > the face every day telling you that you're not going to deliver what you
                    > > promised.
                    > > >
                    > > > Rather than commit to less, the organization decides to shoot the
                    > > messenger. We can't have that graph telling us every day what we can't do.
                    > > >
                    > > > Mark
                    > > >
                    > > >
                    > > > --- In extremeprogramming@yahoogroups.com, "Scott Ambler" <scottwambler@>
                    > > wrote:
                    > > > >
                    > > > > --- In extremeprogramming@yahoogroups.com, "David H." <dmalloc@>
                    > > wrote:
                    > > > > >
                    > > > > > > 4. The three practices which were most likely to be tried and then
                    > > > > > > abandoned were Pair Programming, Burndown Tracking, and Potentially
                    > > > > > > Shippable Software Each Iteration.
                    > > > > >
                    > > > > >
                    > > > > > That seems top paint quite a sorry picture of the state the world of
                    > > agile
                    > > > > > adoption is in. Oh well...
                    > > > >
                    > > > > I see organizations abandon non-solo development strategies such as
                    > > pair programming all the time. Too many people aren't willing to give it
                    > > enough time to take hold, and too many people think that it reduces
                    > > productivity.
                    > > > >
                    > > > > I was surprised by burndown tracking seeing as it's a fairly
                    > > straightforward thing. Granted, it's part of the hidden bureaucracy in
                    > > Scrum that people rarely talk about (in the situations where the burndown
                    > > charts aren't being automatically generated by the tools that you're using
                    > > at least) but perhaps the real issue is that many agile teams are finding
                    > > other ways to achieve the same sort of goals.
                    > > > >
                    > > > > Potentially shippable software each iteration requires discipline on
                    > > the part of the team. I can see how this is hard for a lot of teams to get
                    > > their act together on, particularly when they're not been coached
                    > > effectively (if at all).
                    > > > >
                    > > > > - Scott
                    > > > >
                    > > >
                    > >
                    > >
                    > >
                    > >
                    > > ------------------------------------
                    > >
                    > > To Post a message, send it to: extremeprogramming@...
                    > >
                    > > To Unsubscribe, send a blank message to:
                    > > extremeprogramming-unsubscribe@...
                    > >
                    > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                    > >
                    > >
                    > >
                    > >
                    >
                    >
                    > --
                    > Rob
                    > --
                    > http://agileintention.blogspot.com
                    > http://twitter.com/robpark
                    >
                    >
                    > [Non-text portions of this message have been removed]
                    >
                  • Rob Park
                    And so do you burndown the release?Or each iteration (more Scrum-like)? ... -- Rob -- http://agileintention.blogspot.com http://twitter.com/robpark [Non-text
                    Message 9 of 14 , Jul 27, 2009
                    • 0 Attachment
                      And so do you burndown the release?Or each iteration (more Scrum-like)?

                      On Mon, Jul 27, 2009 at 11:04 AM, jmilunsky <jack@...> wrote:

                      > in my entire career, I don't think i have ever had a single iteration
                      > release
                      >
                      > Jack
                      > www.agilebuddy.com
                      > blog.agilebuddy.com
                      > twitter.com/agilebuddy
                      >
                      > --- In extremeprogramming@yahoogroups.com, Rob Park <robert.d.park@...>
                      > wrote:
                      > >
                      > > I find the comments in favor of burndowns interesting.
                      > > To me, burndowns are only really necessary for multi-iteration
                      > releases...
                      > > say for tracking the progress of a new feature initiative for a customer.
                      > >
                      > > If they feel helpful in an iteration, then perhaps your iteration is too
                      > > long.
                      > > And generally, I'd question why your story board isn't telling you enough
                      > > already?
                      > >
                      > > On Mon, Jul 27, 2009 at 8:40 AM, jmilunsky <jack@...> wrote:
                      > >
                      > > > The burndown for me is the single most important vehicle for success in
                      > > > Scrum in my opinion. If you don't have this and you won't ever get to a
                      > > > sustainable throughput and then everything starts to break down
                      > > >
                      > > > Jack
                      > > > www.agilebuddy.com
                      > > > blog.agilebuddy.com
                      > > > twitter.com/agilebuddy
                      > > >
                      > > > --- In extremeprogramming@yahoogroups.com, "woynam" <woyna@> wrote:
                      > > > >
                      > > > >
                      > > > > I believe the abandonment of burndowns is directly tied to the
                      > failure to
                      > > > deliver working software each iteration.
                      > > > >
                      > > > > Teams commit to too much, and fail to deliver. The burndown stares
                      > you in
                      > > > the face every day telling you that you're not going to deliver what
                      > you
                      > > > promised.
                      > > > >
                      > > > > Rather than commit to less, the organization decides to shoot the
                      > > > messenger. We can't have that graph telling us every day what we can't
                      > do.
                      > > > >
                      > > > > Mark
                      > > > >
                      > > > >
                      > > > > --- In extremeprogramming@yahoogroups.com, "Scott Ambler"
                      > <scottwambler@>
                      > > > wrote:
                      > > > > >
                      > > > > > --- In extremeprogramming@yahoogroups.com, "David H." <dmalloc@>
                      > > > wrote:
                      > > > > > >
                      > > > > > > > 4. The three practices which were most likely to be tried and
                      > then
                      > > > > > > > abandoned were Pair Programming, Burndown Tracking, and
                      > Potentially
                      > > > > > > > Shippable Software Each Iteration.
                      > > > > > >
                      > > > > > >
                      > > > > > > That seems top paint quite a sorry picture of the state the world
                      > of
                      > > > agile
                      > > > > > > adoption is in. Oh well...
                      > > > > >
                      > > > > > I see organizations abandon non-solo development strategies such as
                      > > > pair programming all the time. Too many people aren't willing to give
                      > it
                      > > > enough time to take hold, and too many people think that it reduces
                      > > > productivity.
                      > > > > >
                      > > > > > I was surprised by burndown tracking seeing as it's a fairly
                      > > > straightforward thing. Granted, it's part of the hidden bureaucracy in
                      > > > Scrum that people rarely talk about (in the situations where the
                      > burndown
                      > > > charts aren't being automatically generated by the tools that you're
                      > using
                      > > > at least) but perhaps the real issue is that many agile teams are
                      > finding
                      > > > other ways to achieve the same sort of goals.
                      > > > > >
                      > > > > > Potentially shippable software each iteration requires discipline
                      > on
                      > > > the part of the team. I can see how this is hard for a lot of teams to
                      > get
                      > > > their act together on, particularly when they're not been coached
                      > > > effectively (if at all).
                      > > > > >
                      > > > > > - Scott
                      > > > > >
                      > > > >
                      > > >
                      > > >
                      > > >
                      > > >
                      > > > ------------------------------------
                      > > >
                      > > > To Post a message, send it to: extremeprogramming@...
                      > > >
                      > > > To Unsubscribe, send a blank message to:
                      > > > extremeprogramming-unsubscribe@...
                      > > >
                      > > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                      > > >
                      > > >
                      > > >
                      > > >
                      > >
                      > >
                      > > --
                      > > Rob
                      > > --
                      > > http://agileintention.blogspot.com
                      > > http://twitter.com/robpark
                      > >
                      > >
                      > > [Non-text portions of this message have been removed]
                      > >
                      >
                      >
                      >
                      >
                      > ------------------------------------
                      >
                      > To Post a message, send it to: extremeprogramming@...
                      >
                      > To Unsubscribe, send a blank message to:
                      > extremeprogramming-unsubscribe@...
                      >
                      > ad-free courtesy of objectmentor.comYahoo! Groups Links
                      >
                      >
                      >
                      >


                      --
                      Rob
                      --
                      http://agileintention.blogspot.com
                      http://twitter.com/robpark


                      [Non-text portions of this message have been removed]
                    • jmilunsky
                      we burndown the iteration we have a burnup for the release that just shows total story points accumulated over the release on a per sprint basis Jack
                      Message 10 of 14 , Jul 27, 2009
                      • 0 Attachment
                        we burndown the iteration

                        we have a burnup for the release that just shows total story points accumulated over the release on a per sprint basis


                        Jack
                        www.agilebuddy.com
                        blog.agilebudy.com
                        twitter.com/agilebuddy

                        --- In extremeprogramming@yahoogroups.com, Rob Park <robert.d.park@...> wrote:
                        >
                        > And so do you burndown the release?Or each iteration (more Scrum-like)?
                        >
                        > On Mon, Jul 27, 2009 at 11:04 AM, jmilunsky <jack@...> wrote:
                        >
                        > > in my entire career, I don't think i have ever had a single iteration
                        > > release
                        > >
                        > > Jack
                        > > www.agilebuddy.com
                        > > blog.agilebuddy.com
                        > > twitter.com/agilebuddy
                        > >
                        > > --- In extremeprogramming@yahoogroups.com, Rob Park <robert.d.park@>
                        > > wrote:
                        > > >
                        > > > I find the comments in favor of burndowns interesting.
                        > > > To me, burndowns are only really necessary for multi-iteration
                        > > releases...
                        > > > say for tracking the progress of a new feature initiative for a customer.
                        > > >
                        > > > If they feel helpful in an iteration, then perhaps your iteration is too
                        > > > long.
                        > > > And generally, I'd question why your story board isn't telling you enough
                        > > > already?
                        > > >
                        > > > On Mon, Jul 27, 2009 at 8:40 AM, jmilunsky <jack@> wrote:
                        > > >
                        > > > > The burndown for me is the single most important vehicle for success in
                        > > > > Scrum in my opinion. If you don't have this and you won't ever get to a
                        > > > > sustainable throughput and then everything starts to break down
                        > > > >
                        > > > > Jack
                        > > > > www.agilebuddy.com
                        > > > > blog.agilebuddy.com
                        > > > > twitter.com/agilebuddy
                        > > > >
                        > > > > --- In extremeprogramming@yahoogroups.com, "woynam" <woyna@> wrote:
                        > > > > >
                        > > > > >
                        > > > > > I believe the abandonment of burndowns is directly tied to the
                        > > failure to
                        > > > > deliver working software each iteration.
                        > > > > >
                        > > > > > Teams commit to too much, and fail to deliver. The burndown stares
                        > > you in
                        > > > > the face every day telling you that you're not going to deliver what
                        > > you
                        > > > > promised.
                        > > > > >
                        > > > > > Rather than commit to less, the organization decides to shoot the
                        > > > > messenger. We can't have that graph telling us every day what we can't
                        > > do.
                        > > > > >
                        > > > > > Mark
                        > > > > >
                        > > > > >
                        > > > > > --- In extremeprogramming@yahoogroups.com, "Scott Ambler"
                        > > <scottwambler@>
                        > > > > wrote:
                        > > > > > >
                        > > > > > > --- In extremeprogramming@yahoogroups.com, "David H." <dmalloc@>
                        > > > > wrote:
                        > > > > > > >
                        > > > > > > > > 4. The three practices which were most likely to be tried and
                        > > then
                        > > > > > > > > abandoned were Pair Programming, Burndown Tracking, and
                        > > Potentially
                        > > > > > > > > Shippable Software Each Iteration.
                        > > > > > > >
                        > > > > > > >
                        > > > > > > > That seems top paint quite a sorry picture of the state the world
                        > > of
                        > > > > agile
                        > > > > > > > adoption is in. Oh well...
                        > > > > > >
                        > > > > > > I see organizations abandon non-solo development strategies such as
                        > > > > pair programming all the time. Too many people aren't willing to give
                        > > it
                        > > > > enough time to take hold, and too many people think that it reduces
                        > > > > productivity.
                        > > > > > >
                        > > > > > > I was surprised by burndown tracking seeing as it's a fairly
                        > > > > straightforward thing. Granted, it's part of the hidden bureaucracy in
                        > > > > Scrum that people rarely talk about (in the situations where the
                        > > burndown
                        > > > > charts aren't being automatically generated by the tools that you're
                        > > using
                        > > > > at least) but perhaps the real issue is that many agile teams are
                        > > finding
                        > > > > other ways to achieve the same sort of goals.
                        > > > > > >
                        > > > > > > Potentially shippable software each iteration requires discipline
                        > > on
                        > > > > the part of the team. I can see how this is hard for a lot of teams to
                        > > get
                        > > > > their act together on, particularly when they're not been coached
                        > > > > effectively (if at all).
                        > > > > > >
                        > > > > > > - Scott
                        > > > > > >
                        > > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > > ------------------------------------
                        > > > >
                        > > > > To Post a message, send it to: extremeprogramming@
                        > > > >
                        > > > > To Unsubscribe, send a blank message to:
                        > > > > extremeprogramming-unsubscribe@
                        > > > >
                        > > > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > >
                        > > >
                        > > > --
                        > > > Rob
                        > > > --
                        > > > http://agileintention.blogspot.com
                        > > > http://twitter.com/robpark
                        > > >
                        > > >
                        > > > [Non-text portions of this message have been removed]
                        > > >
                        > >
                        > >
                        > >
                        > >
                        > > ------------------------------------
                        > >
                        > > To Post a message, send it to: extremeprogramming@...
                        > >
                        > > To Unsubscribe, send a blank message to:
                        > > extremeprogramming-unsubscribe@...
                        > >
                        > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                        > >
                        > >
                        > >
                        > >
                        >
                        >
                        > --
                        > Rob
                        > --
                        > http://agileintention.blogspot.com
                        > http://twitter.com/robpark
                        >
                        >
                        > [Non-text portions of this message have been removed]
                        >
                      • Scott Ambler
                        That s a great theory, but unfortunately the data doesn t show that. 15 people indicated that they abandoned burndown charts. 12 people indicated that they
                        Message 11 of 14 , Jul 27, 2009
                        • 0 Attachment
                          That's a great theory, but unfortunately the data doesn't show that.

                          15 people indicated that they abandoned burndown charts.
                          12 people indicated that they abandoned potentially shippable software
                          1 person indicated both.

                          - Scott

                          --- In extremeprogramming@yahoogroups.com, "woynam" <woyna@...> wrote:
                          >
                          >
                          > I believe the abandonment of burndowns is directly tied to the failure to deliver working software each iteration.
                          >
                          > Teams commit to too much, and fail to deliver. The burndown stares you in the face every day telling you that you're not going to deliver what you promised.
                          >
                          > Rather than commit to less, the organization decides to shoot the messenger. We can't have that graph telling us every day what we can't do.
                          >
                          > Mark
                        • woynam
                          Why would a group drop potentially shippable software, but keep the burndown? What value does the burndown provide if it never reaches the x-axis, or doesn t
                          Message 12 of 14 , Jul 28, 2009
                          • 0 Attachment
                            Why would a group drop potentially shippable software, but keep the burndown? What value does the burndown provide if it never reaches the x-axis, or doesn't motivate the team to defer stories so that they can deliver something? The data doesn't make sense.

                            Mark

                            --- In extremeprogramming@yahoogroups.com, "Scott Ambler" <scottwambler@...> wrote:
                            >
                            > That's a great theory, but unfortunately the data doesn't show that.
                            >
                            > 15 people indicated that they abandoned burndown charts.
                            > 12 people indicated that they abandoned potentially shippable software
                            > 1 person indicated both.
                            >
                            > - Scott
                            >
                            > --- In extremeprogramming@yahoogroups.com, "woynam" <woyna@> wrote:
                            > >
                            > >
                            > > I believe the abandonment of burndowns is directly tied to the failure to deliver working software each iteration.
                            > >
                            > > Teams commit to too much, and fail to deliver. The burndown stares you in the face every day telling you that you're not going to deliver what you promised.
                            > >
                            > > Rather than commit to less, the organization decides to shoot the messenger. We can't have that graph telling us every day what we can't do.
                            > >
                            > > Mark
                            >
                          • Adrian Howard
                            ... Not having shippable software every iteration doesn t necessarily mean that you ll never meet the x-axis. Or that you don t deliver stuff. It just means
                            Message 13 of 14 , Jul 28, 2009
                            • 0 Attachment
                              On 28 Jul 2009, at 15:02, woynam wrote:

                              > Why would a group drop potentially shippable software, but keep the
                              > burndown? What value does the burndown provide if it never reaches
                              > the x-axis, or doesn't motivate the team to defer stories so that
                              > they can deliver something? The data doesn't make sense.

                              Not having shippable software every iteration doesn't necessarily mean
                              that you'll never meet the x-axis. Or that you don't deliver stuff. It
                              just means you can't ship at the end of every iteration ;-)

                              For example...

                              I still found burndown charts useful on a project when rewriting a
                              bunch of underlying code causing us to have a non-shippable product
                              for a while - along with having some localisation/internationalisation
                              functionality that made it hard to tweak the UI since it involved
                              getting N translations done, checking then, etc.

                              And before you ask... Yes - our definition of done-done wasn't end-to-
                              end during that period. Yes - if we'd been smarter and had a more
                              experienced team co-located team we might have kept a shippable
                              product during that time. Yes - this wasn't ideal and with all the
                              wonderful hindsight I've gained since I'd do it completely differently
                              if I was put in the same sort of situation.

                              That said - we could still track some level of "done" with a bunch of
                              mocks/stubs on the stories that touched the broken stuff (and we had
                              very few problems with integration at the end too - coz we had common
                              code ownership and were pretty good at keeping stuff in sync.) The
                              burndown still kept us as honest as we could be without end-to-end
                              code and helped us spot places where our mock/stub layer was failing
                              coz it was blocking story completion - allowing us to focus people on
                              fixing that.

                              It gave a whole bunch of value despite the lack of releasable code. I
                              could still see the general slope of the burndown and from that can
                              give a pretty good guess when we will be done.

                              Would it have given more value if we were in a state where we could
                              release at the end of each iteration? Hell yes. Would have been better
                              with RTFs rather than testing with mocks and stubs. Better than not
                              doing the burndown - I think so.

                              Cheers,

                              Adrian
                              --
                              http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                            • Fernando Cuenca
                              ... I have observed another variation of this: lack of agreement on how to define done-done. When different members of the team (both dev and business) work
                              Message 14 of 14 , Jul 28, 2009
                              • 0 Attachment
                                On Mon, Jul 27, 2009 at 10:11 AM, woynam<woyna@...> wrote:
                                >
                                >
                                > I believe the abandonment of burndowns is directly tied to the failure to
                                > deliver working software each iteration.

                                I have observed another variation of this: lack of agreement on how to
                                define "done-done." When different members of the team (both dev and
                                business) work towards different interpretation of what "done" mean,
                                you reach a point where it is very difficult to actually track where
                                you really are. At the end of the iteration you have lots of loose
                                ends mixed up with stories that are really "done", but some of those
                                were "done" within this iteration, whereas others are carry overs,
                                etc, so the chart doesn't really reflect progress towards a clear end
                                goal.

                                Saludos!
                                Fernando.
                              Your message has been successfully submitted and would be delivered to recipients shortly.