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

Re: [scrumdevelopment] Re: Flaccid Scrum ...

Expand Messages
  • Adam Sroka
    ... I am interested, and I would suggest that it is fine to post it here if it is pertinent to the practice of Scrum/Agile. It sounded like it was.
    Message 1 of 30 , Feb 1, 2009
    • 0 Attachment
      On Sun, Feb 1, 2009 at 5:13 PM, Amanda Abelove <amanda@...> wrote:
      > Totally! But let's take the discussion offline, since this isn't a product
      > management or marketing related list and will therefore probably annoy
      > everyone collectively :-)
      >

      I am interested, and I would suggest that it is fine to post it here
      if it is pertinent to the practice of Scrum/Agile. It sounded like it
      was.
    • Amanda Abelove
      How about I hate posting things voicing minority opinions on the Internet that get googled and brought up in job interviews I ll cc you.
      Message 2 of 30 , Feb 1, 2009
      • 0 Attachment
        How about "I hate posting things voicing minority opinions on the Internet that get googled and brought up in job interviews"

        I'll cc you.

        On Sun, Feb 1, 2009 at 5:17 PM, Adam Sroka <adam.sroka@...> wrote:

        On Sun, Feb 1, 2009 at 5:13 PM, Amanda Abelove <amanda@...> wrote:
        > Totally! But let's take the discussion offline, since this isn't a product
        > management or marketing related list and will therefore probably annoy
        > everyone collectively :-)
        >

        I am interested, and I would suggest that it is fine to post it here
        if it is pertinent to the practice of Scrum/Agile. It sounded like it
        was.

      • Kane Mar
        ... Sounds good. I m looking forward to your email. Best regards, Kane Mar http://KaneMar.com | http://www.linkedin.com/in/kanemar
        Message 3 of 30 , Feb 1, 2009
        • 0 Attachment
          --- In scrumdevelopment@yahoogroups.com, Amanda Abelove <amanda@...> wrote:
          > Totally! But let's take the discussion offline, since this isn't a product
          > management or marketing related list and will therefore probably annoy
          > everyone collectively :-)

          Sounds good. I'm looking forward to your email.

          Best regards,
          Kane Mar
          http://KaneMar.com | http://www.linkedin.com/in/kanemar
          http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival
        • georgievh
          Dear Amanda, I am a newbie in Scrum and will probably not be able to contribute to the debate. However, I am interested in the topic. Could you, please cc me
          Message 4 of 30 , Feb 1, 2009
          • 0 Attachment
            Dear Amanda,

            I am a newbie in Scrum and will probably not be able to contribute to
            the debate. However, I am interested in the topic.

            Could you, please cc me too?


            Regards,

            Hristo




            --- In scrumdevelopment@yahoogroups.com, Amanda Abelove <amanda@...>
            wrote:
            >
            > How about "I hate posting things voicing minority opinions on the
            Internet
            > that get googled and brought up in job interviews"
            >
            > I'll cc you.
            >
            > On Sun, Feb 1, 2009 at 5:17 PM, Adam Sroka <adam.sroka@...> wrote:
            >
            > > On Sun, Feb 1, 2009 at 5:13 PM, Amanda Abelove
            <amanda@...<amanda%40scrumclub.org>>
            > > wrote:
            > > > Totally! But let's take the discussion offline, since this isn't a
            > > product
            > > > management or marketing related list and will therefore probably
            annoy
            > > > everyone collectively :-)
            > > >
            > >
            > > I am interested, and I would suggest that it is fine to post it here
            > > if it is pertinent to the practice of Scrum/Agile. It sounded like it
            > > was.
            > >
            > >
            >
          • Stephen Palmer
            Absolutely! Agile processes, Scrum or otherwise, make it harder to hide poor quality people and teams behind process compliance. Steve
            Message 5 of 30 , Feb 2, 2009
            • 0 Attachment
              Absolutely! Agile processes, Scrum or otherwise, make it harder to hide
              poor quality people and teams behind process compliance.

              Steve

              Nancy Dirgo wrote:
              > Tim,
              >
              > I totally agree. If you don't have he team and discipline as well as
              > the motivation, SCRUM won't get you there. I've been doing software
              > development now for 25 years and have used many different processes.
              > The people make the difference.
              >
              > Nancy
              >
              > ------------------------------------------------------------------------
              > *From:* Tim Walker <walketim@...>
              > *To:* scrumdevelopment@yahoogroups.com
              > *Sent:* Friday, January 30, 2009 6:38:04 AM
              > *Subject:* Re: [scrumdevelopment] Flaccid Scrum ...
              >
              > Scrum is not enough. Attention to technical excellence and hiring
              > motivated people are required for it to be successful. It's no silver
              > bullet and absence adherence to the values and principles we might,
              > indeed, be better off with a different process.
              >
              > Tim
              >
              > On Thu, Jan 29, 2009 at 8:32 PM, Kane Mar <kane_sfo@yahoo. com
              > <mailto:kane_sfo%40yahoo.com>> wrote:
              > > Martin Fowler has written a thought provoking article on, what he calls,
              > > FlaccidScrum. In a
              > > nutshell he's seeing projects that have adopted Scrum, make quick
              > progress
              > > and then "After a
              > > while progress is slow because the code base is a mess. What's
              > happened is
              > > that they haven't
              > > paid enough attention to the internal quality of their software."
              > >
              > > In defense of Scrum Martin also points out, "prominent Scrummers they've
              > > always
              > > emphasized that you must have good technical practices."
              > >
              > > I personally think that he makes a good point, and his article is a
              > timely
              > > reminder that good
              > > engineering practices (Continuous Integration, TDD and Refactoring)
              > are all
              > > very important.
              > >
              > > Anyway, here's the article: http://martinfowler .com/bliki/
              > FlaccidScrum. html <http://martinfowler.com/bliki/FlaccidScrum.html>
              > >
              > > Best regards,
              > > Kane Mar
              > > http://KaneMar. com <http://KaneMar.com> | http://www.linkedin
              > .com/in/kanemar <http://www.linkedin.com/in/kanemar>
              > > http://www.twitter. com/Kane_ Mar <http://www.twitter.com/Kane_Mar>
              > | http://www.twitter. com/AgileCarniva l
              > <http://www.twitter.com/AgileCarnival>
              > >
              > >
              >
              >
            • Brad Appleton
              Doesnt Scrum also prescribe (or at least REALLY STRONGLY recommend) at least daily integration and test-automation? I could swear I remember reading that in
              Message 6 of 30 , Feb 2, 2009
              • 0 Attachment
                Doesnt Scrum also prescribe (or at least REALLY STRONGLY recommend) at
                least daily integration and test-automation? I could swear I remember
                reading that in the first Scrum book from Schwaber and Beedle?

                I'm curious as to how often this problem is encountered even in the face
                of daily/nightly builds and test-automation (but not necessarily
                "continuous" integration, and no TDD, despite the string test-automation).

                What Ive seen is that even with the above (but no refactoring and TDD),
                the problem can still very easily happen. The recent book "Emergent
                Design" suggests that the discipline of Emergent Design (which includes
                both TDD and Refactoring) is the bare minimum in technical practices
                that are needed in conjunction with Scrum (no mention of pairing, tho it
                is often easiest to teach and grow refactoring expertise thru pairing).

                --
                Brad Appleton <brad {AT} bradapp.net>
                Agile CM Environments (http://blog.bradapp.net/)
                & Software CM Patterns (www.scmpatterns.com)
                "And miles to go before I sleep" -- Robert Frost
              • Amanda Abelove
                Sigh... I just figure it is easier to start a badass user group with some awesome tricks than try to do a million things with a user forum. Since this stuff is
                Message 7 of 30 , Feb 2, 2009
                • 0 Attachment
                  Sigh... I just figure it is easier to start a badass user group with some awesome tricks than try to do a million things with a user forum. Since this stuff is part of my job, I want it to be cooler and easier to get by the brass.

                  Watch this space around the beginning of March: http://scrumclub.org

                  On Mon, Feb 2, 2009 at 5:50 AM, Stephen Palmer <stephen.palmer@...> wrote:


                  Absolutely! Agile processes, Scrum or otherwise, make it harder to hide
                  poor quality people and teams behind process compliance.

                  Steve

                  Nancy Dirgo wrote:
                  > Tim,
                  >
                  > I totally agree. If you don't have he team and discipline as well as
                  > the motivation, SCRUM won't get you there. I've been doing software
                  > development now for 25 years and have used many different processes.
                  > The people make the difference.
                  >
                  > Nancy
                  >
                  > ----------------------------------------------------------
                  > *From:* Tim Walker <walketim@...>
                  > *To:* scrumdevelopment@yahoogroups.com
                  > *Sent:* Friday, January 30, 2009 6:38:04 AM
                  > *Subject:* Re: [scrumdevelopment] Flaccid Scrum ...
                  >
                  > Scrum is not enough. Attention to technical excellence and hiring
                  > motivated people are required for it to be successful. It's no silver
                  > bullet and absence adherence to the values and principles we might,
                  > indeed, be better off with a different process.
                  >
                  > Tim
                  >
                  > On Thu, Jan 29, 2009 at 8:32 PM, Kane Mar <kane_sfo@yahoo. com
                  > <mailto:kane_sfo%40yahoo.com>> wrote:
                  > > Martin Fowler has written a thought provoking article on, what he calls,
                  > > FlaccidScrum. In a
                  > > nutshell he's seeing projects that have adopted Scrum, make quick
                  > progress
                  > > and then "After a
                  > > while progress is slow because the code base is a mess. What's
                  > happened is
                  > > that they haven't
                  > > paid enough attention to the internal quality of their software."
                  > >
                  > > In defense of Scrum Martin also points out, "prominent Scrummers they've
                  > > always
                  > > emphasized that you must have good technical practices."


                  > >
                  > > I personally think that he makes a good point, and his article is a
                  > timely
                  > > reminder that good
                  > > engineering practices (Continuous Integration, TDD and Refactoring)
                  > are all
                  > > very important.
                  > >
                  > > Anyway, here's the article: http://martinfowler .com/bliki/
                  > FlaccidScrum. html <http://martinfowler.com/bliki/FlaccidScrum.html>
                  > >
                  > > Best regards,
                  > > Kane Mar
                  > > http://KaneMar. com <http://KaneMar.com> | http://www.linkedin
                  > .com/in/kanemar <http://www.linkedin.com/in/kanemar>
                  > > http://www.twitter. com/Kane_ Mar <http://www.twitter.com/Kane_Mar>
                  > | http://www.twitter. com/AgileCarniva l
                  > <http://www.twitter.com/AgileCarnival>
                  > >
                  > >
                  >
                  >


                • Brad Appleton
                  ... I m struggling with trying to get some folks thru this as well. Despite drawing upon my wonderful list of quotes on simplicity at
                  Message 8 of 30 , Feb 2, 2009
                  • 0 Attachment
                    Stephen Bobick wrote:
                    > I've seen this "flaccid Scrum" before as well, and usually the culprit
                    > is (mis)use of the KISS principle and an aversion to the principal of
                    > agressive and regular refactoring.

                    I'm struggling with trying to get some folks thru this as well. Despite
                    drawing upon my wonderful list of "quotes" on simplicity at
                    http://blog.bradapp.net/2006/05/simple-aint-easy-myths-and.html

                    I still run into the misinterpretation of "Simple" as being easy to do
                    today/now rather than being simple to change/evolve over the long hall
                    (i.e. minimizing TOTAL work (today + tomorrow) rather than minimizing
                    CURRENT efforts.)

                    Maarten Volder's does a good job of describing the misconception at
                    http://www.maartenvolders.com/blog/2008/09/simplicity-and-why-it-matters.html

                    --
                    Brad Appleton <brad {AT} bradapp.net>
                    Agile CM Environments (http://blog.bradapp.net/)
                    & Software CM Patterns (www.scmpatterns.com)
                    "And miles to go before I sleep" -- Robert Frost
                  • Mitch Lacey
                    Hello Adam, Sorry to chime in a little late, but the topic of fixing defects into a Sprint is a bit of a perplexing one. I ve wrestled with this and have a
                    Message 9 of 30 , Feb 2, 2009
                    • 0 Attachment

                      Hello Adam,

                       

                      Sorry to chime in a little late, but the topic of fixing defects into a Sprint is a bit of a perplexing one.

                       

                      I’ve wrestled with this and have a chapter on it for my upcoming book.

                       

                      One of the rules we have on the list is no spamming of blog posts or URL’s to drive traffic to our websites, but I talked to Ken about it and he’s OK with me sharing.

                       

                      You can check out the draft chapter here:

                      http://tinyurl.com/chghy5

                       

                      Please provide feedback on the chapter, it’s fresh off the press.

                       

                      Mitch

                       

                      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Adam Sroka
                      Sent: Friday, January 30, 2009 3:26 PM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: Re: [scrumdevelopment] Re: ScrumButt [was [Bad] Scrum ...]

                       

                      On Fri, Jan 30, 2009 at 5:39 AM, Joseph Little <jhlittle@...> wrote:

                      > Hi Kane,
                      >
                      > I would certainly agree. And thanks for raising the issue. And
                      > apologies if I deflate the interest of some readers by changing the
                      > subject line to a different metaphor.
                      >

                      Hehe. You said "deflate".

                      > I think it is a feature (not a bug) that Scrum does not *require
                      > specific* engineering practices. But not continuously improving
                      > Engineering practices is a form of ScrumButt ("we do Scrum, but...we
                      > don't have any engineering practices"). Doing Scrum absolutely means
                      > that you must improve engineering practices. Continuously!!!
                      >
                      > You and Martin (apparently) don't define what "a mess" means.
                      I'll
                      > suggest two things to start with that might clean it up:
                      > (1) A story is not done until all bugs are fixed (very soon this
                      > almost always means you must have more automated testing).
                      > (2) Somewhere in every story we must do some refactoring of the code.
                      > Should be part of the definition of done. That DoD is *very* important.
                      >

                      Yes, but, having been there myself:

                      1) We can't possibly fix all of the existing (production) bugs in a
                      single iteration. Would it be okay if we increased the length of our
                      iterations? Add an "iteration 0" so that we can assess the impact to
                      existing production code of every new effort?

                      2) I don't know what is going to break if I refactor this stuff,
                      because there are no tests. Can we create "technical stories" so that
                      we can go on refactoring crusades? Can we greatly inflate our
                      estimates, because we don't know what is going to break?

                      And, I'll add another "but" to the pile:

                      What do we do if some parts of the team are willing to adopt
                      "engineering practices" and others resist? In my experience (And I'm
                      an "XP guy") "engineering practices" only work team wide. If most of
                      the team are doing TDD, continuous integration, pairing, etc, and one
                      or two guys are sneaking in untested code, velocity will grind to a
                      standstill while the "good guys" attempt to clean up after the bad.

                      > One more thing, somewhat different to what Martin was getting at:
                      > * we must also have continuous improvement in Business Value Engineering.
                      >
                      > If we can't provide evidence that we are getting better and better at
                      > delivering BV, then what are we doing? Of course, many specific
                      > practices in this. More in another post.
                      >

                      What is the "business value" of cleaning up the huge mess of horrible
                      legacy code we've created over the past umpteen years? Does business
                      understand the value of adding tests? Does business understand the
                      value of eliminating bugs that don't have an immediate (known) impact
                      on the customer? Adding testing and refactoring to every story will
                      greatly reduce velocity (at least initially.) Will the business accept
                      this?

                    • Anthony Principato
                      Hello, My company is in the process of figuring out how we can better leverage Scrum techniques, disciplines and principles within our Data Center and
                      Message 10 of 30 , Feb 2, 2009
                      • 0 Attachment

                        Hello,

                         

                        My company is in the process of figuring out how we can better leverage Scrum techniques, disciplines and principles within our Data Center and Infrastructure groups to better support Scrum/Agile Development teams. Can anyone please share their experiences, approaches with aligning the planning of Data Center and Infrastructure new and updated build outs of all environments up and through Disaster Recovery in preparation of Sprint Development efforts.  

                        What we are trying to do is align accordingly the timing of Infrastructure and Data Center build outs in direct relation with Development Sprint efforts so we can be better prepared for Sprint Development.

                         

                        Questions we are asking ourselves:  

                         

                        Do we time-box work effort processes by server type, number of servers so we can strive for velocity levels to communicate back to the business and development for release planning?

                        Do we create a Scrum Service Level Model so we can maintain a plug and play of Virtual Machine resources for all project release initiatives?

                         

                        Any help would be appreciative.

                         

                        Tony

                          

                          

                         

                        -----Original Message-----
                        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mitch Lacey
                        Sent: Monday, February 02, 2009 4:05 PM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: RE: [scrumdevelopment] Re: ScrumButt [was [Bad] Scrum ...]

                         

                        Hello Adam,

                         

                        Sorry to chime in a little late, but the topic of fixing defects into a Sprint is a bit of a perplexing one.

                         

                        I’ve wrestled with this and have a chapter on it for my upcoming book.

                         

                        One of the rules we have on the list is no spamming of blog posts or URL’s to drive traffic to our websites, but I talked to Ken about it and he’s OK with me sharing.

                         

                        You can check out the draft chapter here:

                        http://tinyurl. com/chghy5

                         

                        Please provide feedback on the chapter, it’s fresh off the press.

                         

                        Mitch

                         

                        From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Adam Sroka
                        Sent: Friday, January 30, 2009 3:26 PM
                        To: scrumdevelopment@ yahoogroups. com
                        Subject: Re: [scrumdevelopment] Re: ScrumButt [was [Bad] Scrum ...]

                         

                        On Fri, Jan 30, 2009 at 5:39 AM, Joseph Little <jhlittle@mindspring .com> wrote:

                        > Hi Kane,
                        >
                        > I would certainly agree. And thanks for raising the issue. And
                        > apologies if I deflate the interest of some readers by changing the
                        > subject line to a different metaphor.
                        >

                        Hehe. You said "deflate".

                        > I think it is a feature (not a bug) that Scrum does not *require
                        > specific* engineering practices. But not continuously improving
                        > Engineering practices is a form of ScrumButt ("we do Scrum, but...we
                        > don't have any engineering practices"). Doing Scrum absolutely means
                        > that you must improve engineering practices. Continuously! !!
                        >
                        > You and Martin (apparently) don't define what "a mess" means.
                        I'll
                        > suggest two things to start with that might clean it up:
                        > (1) A story is not done until all bugs are fixed (very soon this
                        > almost always means you must have more automated testing).
                        > (2) Somewhere in every story we must do some refactoring of the code.
                        > Should be part of the definition of done. That DoD is *very* important.
                        >

                        Yes, but, having been there myself:

                        1) We can't possibly fix all of the existing (production) bugs in a
                        single iteration. Would it be okay if we increased the length of our
                        iterations? Add an "iteration 0" so that we can assess the impact to
                        existing production code of every new effort?

                        2) I don't know what is going to break if I refactor this stuff,
                        because there are no tests. Can we create "technical stories" so that
                        we can go on refactoring crusades? Can we greatly inflate our
                        estimates, because we don't know what is going to break?

                        And, I'll add another "but" to the pile:

                        What do we do if some parts of the team are willing to adopt
                        "engineering practices" and others resist? In my experience (And I'm
                        an "XP guy") "engineering practices" only work team wide. If most of
                        the team are doing TDD, continuous integration, pairing, etc, and one
                        or two guys are sneaking in untested code, velocity will grind to a
                        standstill while the "good guys" attempt to clean up after the bad.

                        > One more thing, somewhat different to what Martin was getting at:
                        > * we must also have continuous improvement in Business Value Engineering.
                        >
                        > If we can't provide evidence that we are getting better and better at
                        > delivering BV, then what are we doing? Of course, many specific
                        > practices in this. More in another post.
                        >

                        What is the "business value" of cleaning up the huge mess of horrible
                        legacy code we've created over the past umpteen years? Does business
                        understand the value of adding tests? Does business understand the
                        value of eliminating bugs that don't have an immediate (known) impact
                        on the customer? Adding testing and refactoring to every story will
                        greatly reduce velocity (at least initially.) Will the business accept
                        this?

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