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

Digging out of technical debt (was: ScrumButt [was [Bad] Scrum ...])

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