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

Flaccid Scrum ...

Expand Messages
  • Kane Mar
    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
    Message 1 of 30 , Jan 29, 2009
    • 0 Attachment
      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

      Best regards,
      Kane Mar
      http://KaneMar.com | http://www.linkedin.com/in/kanemar
      http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival
    • Joseph Little
      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
      Message 2 of 30 , Jan 30, 2009
      • 0 Attachment
        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.

        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.

        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.

        Regards, Joe


        --- In scrumdevelopment@yahoogroups.com, "Kane Mar" <kane_sfo@...> 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
        >
        > Best regards,
        > Kane Mar
        > http://KaneMar.com | http://www.linkedin.com/in/kanemar
        > http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival
        >
      • Tim Walker
        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
        Message 3 of 30 , Jan 30, 2009
        • 0 Attachment
          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@...> 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
          >
          > Best regards,
          > Kane Mar
          > http://KaneMar.com | http://www.linkedin.com/in/kanemar
          > http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival
          >
          >
        • Steve Henke
          Joe, do you suggest all bugs for a story are fixed within the same sprint? Is that practical? A lot of teams struggle with the DoD for a story within a
          Message 4 of 30 , Jan 30, 2009
          • 0 Attachment
            Joe, do you suggest all bugs for a story are fixed within the same sprint?  Is that practical?  A lot of teams struggle with the DoD for a story within a sprint.

            Steve

            On Fri, Jan 30, 2009 at 7: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.

            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.

            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.

            Regards, Joe

            --- In scrumdevelopment@yahoogroups.com, "Kane Mar" <kane_sfo@...> 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
            >
            > Best regards,
            > Kane Mar
            > http://KaneMar.com | http://www.linkedin.com/in/kanemar
            > http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival
            >


          • Nancy Dirgo
            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
            Message 5 of 30 , Jan 30, 2009
            • 0 Attachment
              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> 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
              >
              > Best regards,
              > Kane Mar
              > http://KaneMar. com | http://www.linkedin .com/in/kanemar
              > http://www.twitter. com/Kane_ Mar | http://www.twitter. com/AgileCarniva l
              >
              >

            • Stephen Bobick
              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
              Message 6 of 30 , Jan 30, 2009
              • 0 Attachment
                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.

                -- Stephn

                On Fri, Jan 30, 2009 at 6:38 AM, Tim Walker <walketim@...> wrote:

                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@...> 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
                >
                > Best regards,
                > Kane Mar
                > http://KaneMar.com | http://www.linkedin.com/in/kanemar
                > http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival
                >
                >


              • Amanda Abelove
                I saw that. I still say that Scrum adoption is largely an issue of poor branding and marketing. -A
                Message 7 of 30 , Jan 30, 2009
                • 0 Attachment
                  I saw that. I still say that Scrum adoption is largely an issue of poor branding and marketing.

                  -A

                  On Thu, Jan 29, 2009 at 7:32 PM, Kane Mar <kane_sfo@...> 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

                  Best regards,
                  Kane Mar
                  http://KaneMar.com | http://www.linkedin.com/in/kanemar
                  http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival


                • Cenk Çivici
                  James Shore has written a similar article about this issue http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html I believe XP (Scrum + engineering
                  Message 8 of 30 , Jan 30, 2009
                  • 0 Attachment
                    James Shore has written a similar article about this issue

                    http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html

                    I believe XP (Scrum + engineering practices) is the bare minimum for success.

                    Cheers
                    Cenk


                    On Fri, Jan 30, 2009 at 5:32 AM, Kane Mar <kane_sfo@...> 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
                    >
                    > Best regards,
                    > Kane Mar
                    > http://KaneMar.com | http://www.linkedin.com/in/kanemar
                    > http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival
                    >
                    >
                  • Joseph Little
                    Hi Steve, Glad you asked. YES! Quality is not an option. Now, what I did not say is how much testing is done during a Sprint. It should normally include both
                    Message 9 of 30 , Jan 30, 2009
                    • 0 Attachment
                      Hi Steve,

                      Glad you asked.

                      YES! Quality is not an option.

                      Now, what I did not say is how much testing is done during a Sprint.
                      It should normally include both Unit and Functional testing at a
                      minimum. Some teams can't do all testing in a sprint.

                      A story is not "done" until all the bugs (that have been identified)
                      are fixed. No velocity until it is done.

                      Why??

                      Several reasons.
                      * Working software is the best thing to inspect and adapt on.
                      * "It ain't over 'til it's over." In other words, we don't know what
                      issues will arise from a featurette until we git 'r done. And when
                      it's done to this degree, we can make a much better estimate to the
                      business guys about "how long to put that in production?"
                      * building technical debt is a sure way to die (metaphorically, if not
                      actually).
                      * and more...

                      Usually when people say that can't do that in 4 weeks, they mean that
                      they haven't the will to do so. Or just can't see how to do it. I
                      personally can't see how it *can't* be possible, but I suppose there
                      must be a case somewhere. For example, a 20 year old COBOL monster
                      spaghetti app with no automated tests.

                      Another common problem is that teams bite off HUGE features. Gotta
                      make 'em small. Smaller. Smaller still.

                      I would look at all the things that keep you (one) from getting a
                      story "done" (by some decent definition) in a Sprint as serious
                      impediments that must be removed.

                      Is this hard in many situations? Well, doing our best is always
                      "hard" in a way. But rewarding.

                      Regards, Joe



                      --- In scrumdevelopment@yahoogroups.com, Steve Henke <steve@...> wrote:
                      >
                      > Joe, do you suggest all bugs for a story are fixed within the same
                      sprint?
                      > Is that practical? A lot of teams struggle with the DoD for a
                      story within
                      > a sprint.
                      > Steve
                      >
                      > On Fri, Jan 30, 2009 at 7: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.
                      > >
                      > > 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.
                      > >
                      > > 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.
                      > >
                      > > Regards, Joe
                      > >
                      > > --- In
                      scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
                      > > "Kane Mar" <kane_sfo@> 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
                      > > >
                      > > > Best regards,
                      > > > Kane Mar
                      > > > http://KaneMar.com | http://www.linkedin.com/in/kanemar
                      > > > http://www.twitter.com/Kane_Mar |
                      http://www.twitter.com/AgileCarnival
                      > > >
                      > >
                      > >
                      > >
                      >
                    • Adam Sroka
                      ... Hehe. You said deflate . ... Yes, but, having been there myself: 1) We can t possibly fix all of the existing (production) bugs in a single iteration.
                      Message 10 of 30 , Jan 30, 2009
                      • 0 Attachment
                        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?
                      • Adam Sroka
                        ... How do we know what simple looks like? Seriously! Do we have a means to measure it? How will we know when what we are creating starts to become less
                        Message 11 of 30 , Jan 30, 2009
                        • 0 Attachment
                          On Fri, Jan 30, 2009 at 10:05 AM, Stephen Bobick <sbobick2@...> 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.
                          >

                          How do we know what "simple" looks like? Seriously! Do we have a means
                          to measure it? How will we know when what we are creating starts to
                          become less simple than it could be? At what point does it become
                          complex? How complex is too complex? Do "engineering practices"
                          provide any help in answering these questions?
                        • George Dinwiddie
                          ... Agreed, and thanks for the pointer. In my experience, most organizations have much room to improve both their project management and their technical
                          Message 12 of 30 , Jan 30, 2009
                          • 0 Attachment
                            Kane Mar wrote:
                            > 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

                            Agreed, and thanks for the pointer.

                            In my experience, most organizations have much room to improve both
                            their project management and their technical engineering practice.
                            Those that start with Scrum seem to improve their project management
                            practice enough that the deficiencies in their technical engineering
                            practice become more painfully obvious.

                            The answer is simple and obvious--improve the technical engineering
                            practice. The way to do that is not so easy, however.

                            For example, Tim Walker suggests "Attention to technical excellence and
                            hiring motivated people are required for it to be successful." As true
                            as this is, it's no way for an organization to get from where it is to a
                            desired state of being able to reliably create desired functionality in
                            their software.

                            People cannot suddenly be attentive to technical excellence. They must
                            slowly acquire the awareness and deeper understanding that they lack, or
                            they would already be attentive. Hiring motivated people suggests that
                            those doing the hiring will suddenly be able to understand what sort of
                            motivation is required, how to discern it in candidates, and follow
                            through with this criteria in preference to the criteria they've been using.

                            And what would you do with the people you have now? Those that are
                            presumably not motivated toward technical excellence? Fire them all and
                            replace them? This is the HR equivalent to the total rewrite of a
                            legacy application, and it has some of the same problems. There is a
                            lot of domain knowledge hidden in there--knowledge that would be
                            difficult to find written down anywhere. The new must achieve the
                            competency of the old before it can begin to surpass it--until then, no
                            benefit is seen. The new will be starting in the same context as the
                            old, and therefore is likely to produce something with a similar
                            organization (or lack thereof).

                            The bottom line is that the developers have to learn to /recognize/ what
                            is "better," they have to learn how to /do/ it, and the cultural context
                            in which they work has to change such that it really is important enough
                            to have happen. Depending on where you start, that's a lot to change
                            all at once. It can take a lot of time and energy.

                            - George

                            --
                            ----------------------------------------------------------------------
                            * George Dinwiddie * http://blog.gdinwiddie.com
                            Software Development http://www.idiacomputing.com
                            Consultant and Coach http://www.agilemaryland.org
                            ----------------------------------------------------------------------
                          • Joseph Little
                            Hi Adam, See below. ... important. ... Yes, if you start in a position of serious technical debt (pretty common really), then the new stories aren t done until
                            Message 13 of 30 , Jan 31, 2009
                            • 0 Attachment
                              Hi Adam,

                              See below.

                              --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...>
                              wrote:
                              >
                              > 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?
                              >

                              Yes, if you start in a position of serious technical debt (pretty
                              common really), then the new stories aren't done until *their* bugs
                              are resolved. And...as you say, all of the bugs will not get fixed in
                              the first Sprint.

                              So, the team needs to write some stories to dig out of technical debt.
                              And convince (explain to) the PO why these are important (they should
                              be to him). Exactly how important will vary.

                              > 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?
                              >

                              So, I take it you mean no automated tests. Again, this is silly and
                              unprofessional, but all too common.

                              Refactoring crusade: well, I would not go that far without asking the
                              Prod Owner. Usually there are several reasons to clean up the code,
                              but I want to emphasize something that can be measured: cleaning it up
                              can increase velocity of "new" stories eventually.

                              So, the technical guys have to show that the cleaning up will do the
                              business some good. There are limits to how much refactoring we do.
                              We let the PO decide what that limit is (and how fast to go), but only
                              after the team has a chance to make their case.

                              > 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.
                              >

                              Well, as you have seen, Scrum or Agile or XP does not magically make a
                              team. And good teams don't have something that great teams have
                              (IMO), as we shall see tomorrow in football (2 pretty darn good teams).

                              I would tend to agree that the whole team needs to do things together.
                              If they are really a team. I believe strongly, based largely on the
                              knowledge creation issue, that we only create software in teams.
                              Still, we have to be reasonable. For example, maybe everyone does not
                              have to do pair programming. For every line of code.

                              > > 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?
                              >

                              As suggested earlier, the main BV of cleaning up is typically the
                              greater velocity in doing good new stories. (There are other things as
                              well.)

                              The team has to explain it to most business guys. Almost all.

                              Sometimes business guys won't "get it" (quickly). Several root
                              causes, including the "hopelessness" of some tech guys in talking to
                              business guys. Scrum and Agile don't do magic or perfectly control
                              people. But I find that usually, if you explain it several times,
                              most business guys will eventually understand that the code must be
                              cleaned up. Perhaps a bit at a time.

                              You have raised a big set of issues. I have tried to give quick
                              answers. Obviously, there are usually lots of wrinkles to your
                              situations as you well know. In real life it might take days or weeks
                              to start making serious progress on the issues you raise.

                              Regards, Joe
                            • George Dinwiddie
                              ... Joe, that s one way of handling it, but there /are/ others. Such as these: 1. If there are bugs in the current code, write stories for those, not for
                              Message 14 of 30 , Jan 31, 2009
                              • 0 Attachment
                                Joseph Little wrote:
                                > --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...>
                                > wrote:
                                >> 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?
                                >
                                > Yes, if you start in a position of serious technical debt (pretty
                                > common really), then the new stories aren't done until *their* bugs
                                > are resolved. And...as you say, all of the bugs will not get fixed in
                                > the first Sprint.
                                >
                                > So, the team needs to write some stories to dig out of technical debt.
                                > And convince (explain to) the PO why these are important (they should
                                > be to him). Exactly how important will vary.

                                Joe, that's one way of handling it, but there /are/ others. Such as these:

                                1. If there are bugs in the current code, write stories for those, not
                                for technical debt. Address /some/ of the technical debt with each of
                                those bug stories. The PO will find it easier to understand why a
                                bug-fix is important than a refactoring that doesn't fix the bug.

                                2. Sometimes you can identify some fairly specific technical debt that
                                you'd like to address. Write a card for that, and put it in a parking
                                area. When an iteration is coming to an end and there's no way for you
                                to productively join the remaining story(ies), then tackle this instead.
                                It's helpful if these are really concrete, so you can know when you've
                                completed them. If you've never got any slack time for such tidbits,
                                then that's another problem, and it's probably contributing to the
                                accumulation of technical debt.

                                - George

                                --
                                ----------------------------------------------------------------------
                                * George Dinwiddie * http://blog.gdinwiddie.com
                                Software Development http://www.idiacomputing.com
                                Consultant and Coach http://www.agilemaryland.org
                                ----------------------------------------------------------------------
                              • Robin Dymond
                                I think Martin raises some good points, and cose to respond to the blog with a blog. I also think he missed the point of visibility by blaming Scrum for
                                Message 15 of 30 , Feb 1, 2009
                                • 0 Attachment
                                  I think Martin raises some good points, and cose to respond to the blog with a blog.
                                  I also think he missed the point of visibility by blaming Scrum for technical debt, when Scrum actually made the debt visible.
                                  http://www.innovel.net/?page_id=13

                                  cheers,
                                  Robin Dymond.

                                  On Fri, Jan 30, 2009 at 6:46 PM, George Dinwiddie <lists@...> wrote:

                                  Kane Mar wrote:
                                  > 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

                                  Agreed, and thanks for the pointer.

                                  In my experience, most organizations have much room to improve both
                                  their project management and their technical engineering practice.
                                  Those that start with Scrum seem to improve their project management
                                  practice enough that the deficiencies in their technical engineering
                                  practice become more painfully obvious.

                                  The answer is simple and obvious--improve the technical engineering
                                  practice. The way to do that is not so easy, however.

                                  For example, Tim Walker suggests "Attention to technical excellence and
                                  hiring motivated people are required for it to be successful." As true
                                  as this is, it's no way for an organization to get from where it is to a
                                  desired state of being able to reliably create desired functionality in
                                  their software.

                                  People cannot suddenly be attentive to technical excellence. They must
                                  slowly acquire the awareness and deeper understanding that they lack, or
                                  they would already be attentive. Hiring motivated people suggests that
                                  those doing the hiring will suddenly be able to understand what sort of
                                  motivation is required, how to discern it in candidates, and follow
                                  through with this criteria in preference to the criteria they've been using.

                                  And what would you do with the people you have now? Those that are
                                  presumably not motivated toward technical excellence? Fire them all and
                                  replace them? This is the HR equivalent to the total rewrite of a
                                  legacy application, and it has some of the same problems. There is a
                                  lot of domain knowledge hidden in there--knowledge that would be
                                  difficult to find written down anywhere. The new must achieve the
                                  competency of the old before it can begin to surpass it--until then, no
                                  benefit is seen. The new will be starting in the same context as the
                                  old, and therefore is likely to produce something with a similar
                                  organization (or lack thereof).

                                  The bottom line is that the developers have to learn to /recognize/ what
                                  is "better," they have to learn how to /do/ it, and the cultural context
                                  in which they work has to change such that it really is important enough
                                  to have happen. Depending on where you start, that's a lot to change
                                  all at once. It can take a lot of time and energy.

                                  - George

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




                                  --
                                  Robin Dymond, CST
                                  Managing Partner, Innovel, LLC.
                                  www.innovel.net
                                  www.scrumtraining.com
                                  (804) 239-4329
                                • George Dinwiddie
                                  Hi, Robin, Re-reading Martin Fowler s posting, then I think it s overstating the case to say he s blaming Scrum for technical debt. Surely the team s
                                  Message 16 of 30 , Feb 1, 2009
                                  • 0 Attachment
                                    Hi, Robin,

                                    Re-reading Martin Fowler's posting, then I think it's overstating the
                                    case to say he's blaming Scrum for technical debt. Surely the team's
                                    technical practices don't worsen just because they're doing Scrum.

                                    The situation he describes, an improvement in software development
                                    [implied in the article] followed by a slowdown [specifically
                                    mentioned], is a case of the technical issues being more visible because
                                    they're no longer hidden in other issues. I certainly agree with you there.

                                    - George

                                    Robin Dymond wrote:
                                    > I think Martin raises some good points, and cose to respond to the blog
                                    > with a blog.
                                    > I also think he missed the point of visibility by blaming Scrum for
                                    > technical debt, when Scrum actually made the debt visible.
                                    > http://www.innovel.net/?page_id=13
                                    >
                                    > cheers,
                                    > Robin Dymond.
                                    >
                                    > On Fri, Jan 30, 2009 at 6:46 PM, George Dinwiddie
                                    > <lists@... <mailto:lists@...>> wrote:
                                    >
                                    > Kane Mar wrote:
                                    > > 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
                                    >
                                    > Agreed, and thanks for the pointer.
                                    >
                                    > In my experience, most organizations have much room to improve both
                                    > their project management and their technical engineering practice.
                                    > Those that start with Scrum seem to improve their project management
                                    > practice enough that the deficiencies in their technical engineering
                                    > practice become more painfully obvious.
                                    >
                                    > The answer is simple and obvious--improve the technical engineering
                                    > practice. The way to do that is not so easy, however.
                                    >
                                    > For example, Tim Walker suggests "Attention to technical excellence and
                                    > hiring motivated people are required for it to be successful." As true
                                    > as this is, it's no way for an organization to get from where it is
                                    > to a
                                    > desired state of being able to reliably create desired functionality in
                                    > their software.
                                    >
                                    > People cannot suddenly be attentive to technical excellence. They must
                                    > slowly acquire the awareness and deeper understanding that they
                                    > lack, or
                                    > they would already be attentive. Hiring motivated people suggests that
                                    > those doing the hiring will suddenly be able to understand what sort of
                                    > motivation is required, how to discern it in candidates, and follow
                                    > through with this criteria in preference to the criteria they've
                                    > been using.
                                    >
                                    > And what would you do with the people you have now? Those that are
                                    > presumably not motivated toward technical excellence? Fire them all and
                                    > replace them? This is the HR equivalent to the total rewrite of a
                                    > legacy application, and it has some of the same problems. There is a
                                    > lot of domain knowledge hidden in there--knowledge that would be
                                    > difficult to find written down anywhere. The new must achieve the
                                    > competency of the old before it can begin to surpass it--until then, no
                                    > benefit is seen. The new will be starting in the same context as the
                                    > old, and therefore is likely to produce something with a similar
                                    > organization (or lack thereof).
                                    >
                                    > The bottom line is that the developers have to learn to /recognize/
                                    > what
                                    > is "better," they have to learn how to /do/ it, and the cultural
                                    > context
                                    > in which they work has to change such that it really is important
                                    > enough
                                    > to have happen. Depending on where you start, that's a lot to change
                                    > all at once. It can take a lot of time and energy.

                                    --
                                    ----------------------------------------------------------------------
                                    * George Dinwiddie * http://blog.gdinwiddie.com
                                    Software Development http://www.idiacomputing.com
                                    Consultant and Coach http://www.agilemaryland.org
                                    ----------------------------------------------------------------------
                                  • Kane Mar
                                    ... So why did you do it? Apologizing for something and then doing it anyway, makes me feel like you re being insincere. ... As part of my CSM training I often
                                    Message 17 of 30 , Feb 1, 2009
                                    • 0 Attachment
                                      --- In scrumdevelopment@yahoogroups.com, "Joseph Little" <jhlittle@...> wrote:
                                      > 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.

                                      So why did you do it? Apologizing for something and then doing it anyway, makes me feel
                                      like you're being insincere.

                                      > 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.

                                      As part of my CSM training I often talk about team etiquette. It's one of my favorite topics
                                      because it's such a simple thing to do, and the impact of good etiquette is tremendous.
                                      One practice of good team etiquette is to avoid the use of "You" because it's accusatory
                                      and can lead to overly defensive behavior. I can share that slide with you, if you wish.

                                      > 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.

                                      Sure, we all pretty much agree on the basics. And, having been through the adoption
                                      cycles for both XP and Scrum, I certainly agree that it's a strength rather than a weakness.

                                      I decided to refer to Martins article because I feel that it's an important topic, and I've
                                      recently read several variations on this theme. Personally, I feel that Martin's post is the
                                      best of them because it's well written and he doesn't try to point blame. In fact he goes out
                                      of his way to say that it's a problem that's bigger than Scrum.

                                      Best regards,
                                      Kane Mar
                                      http://KaneMar.com | http://www.linkedin.com/in/kanemar
                                      http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival
                                    • Kane Mar
                                      ... Hi Amanda, That s a very interesting statement. Would you can to elaborate on it? Best regards, Kane Mar http://KaneMar.com |
                                      Message 18 of 30 , Feb 1, 2009
                                      • 0 Attachment
                                        --- In scrumdevelopment@yahoogroups.com, Amanda Abelove <amanda@...> wrote:
                                        >
                                        > I saw that. I still say that Scrum adoption is largely an issue of poor
                                        > branding and marketing.

                                        Hi Amanda,

                                        That's a very interesting statement. Would you can to elaborate on it?

                                        Best regards,
                                        Kane Mar
                                        http://KaneMar.com | http://www.linkedin.com/in/kanemar
                                        http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival
                                      • Kane Mar
                                        Hi George, ... This is a terrific post! I ve read the above 4 paragraphs about three times and each time I find something new. Great stuff! ... Yes, I think
                                        Message 19 of 30 , Feb 1, 2009
                                        • 0 Attachment
                                          Hi George,

                                          --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                                          > The answer is simple and obvious--improve the technical engineering
                                          > practice. The way to do that is not so easy, however.
                                          >
                                          > For example, Tim Walker suggests "Attention to technical excellence and
                                          > hiring motivated people are required for it to be successful." As true
                                          > as this is, it's no way for an organization to get from where it is to a
                                          > desired state of being able to reliably create desired functionality in
                                          > their software.
                                          >
                                          > People cannot suddenly be attentive to technical excellence. They must
                                          > slowly acquire the awareness and deeper understanding that they lack, or
                                          > they would already be attentive. Hiring motivated people suggests that
                                          > those doing the hiring will suddenly be able to understand what sort of
                                          > motivation is required, how to discern it in candidates, and follow
                                          > through with this criteria in preference to the criteria they've been using.
                                          >
                                          > And what would you do with the people you have now? Those that are
                                          > presumably not motivated toward technical excellence? Fire them all and
                                          > replace them? This is the HR equivalent to the total rewrite of a
                                          > legacy application, and it has some of the same problems. There is a
                                          > lot of domain knowledge hidden in there--knowledge that would be
                                          > difficult to find written down anywhere. The new must achieve the
                                          > competency of the old before it can begin to surpass it--until then, no
                                          > benefit is seen. The new will be starting in the same context as the
                                          > old, and therefore is likely to produce something with a similar
                                          > organization (or lack thereof).

                                          This is a terrific post! I've read the above 4 paragraphs about three times and each time I
                                          find something new. Great stuff!

                                          > The bottom line is that the developers have to learn to /recognize/ what
                                          > is "better," they have to learn how to /do/ it, and the cultural context
                                          > in which they work has to change such that it really is important enough
                                          > to have happen. Depending on where you start, that's a lot to change
                                          > all at once. It can take a lot of time and energy.

                                          Yes, I think you've spot on with the bottom line. It simply isn't enough to recognize
                                          'better', learn how to do it, and change the cultural context ... rather *all* these things
                                          need to happen to make any lasting impact. A lot of time and energy indeed! =)

                                          Best regards,
                                          Kane Mar
                                          http://KaneMar.com | http://www.linkedin.com/in/kanemar
                                          http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival
                                        • Amanda Abelove
                                          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
                                          Message 20 of 30 , Feb 1, 2009
                                          • 0 Attachment
                                            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 :-)

                                            Amanda

                                            On Sun, Feb 1, 2009 at 4:02 PM, Kane Mar <kane_sfo@...> wrote:

                                            --- In scrumdevelopment@yahoogroups.com, Amanda Abelove <amanda@...> wrote:
                                            >
                                            > I saw that. I still say that Scrum adoption is largely an issue of poor
                                            > branding and marketing.

                                            Hi Amanda,

                                            That's a very interesting statement. Would you can to elaborate on it?

                                            Best regards,
                                            Kane Mar
                                            http://KaneMar.com | http://www.linkedin.com/in/kanemar
                                            http://www.twitter.com/Kane_Mar | http://www.twitter.com/AgileCarnival


                                          • 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 21 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 22 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 23 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 24 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 25 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 26 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 27 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 28 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 29 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 30 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.