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

Re: [XP] Need advice preparing the waters for XP

Expand Messages
  • Craig Davidson
    Hi Olof, I don t use the word measure , that suggests a degree of precision that I don t get. You can observe it s impact (subjectively is fine - If it has
    Message 1 of 23 , Dec 1, 2008
    • 0 Attachment
      Hi Olof,

      I don't use the word "measure", that suggests a degree of precision that I
      don't get.

      You can observe it's impact (subjectively is fine - If it has negligible
      impact is it really a technical debt?).
      And you can guesstimate what it would take to pay it off.

      To track debt, I like to write the main offenders as notes or index cards
      put them on a Technical Debit wall or column.
      This makes it visible to the team and stakeholders - I find without that
      visibility it is easily ignored - until something crunches.
      As a team we work out how (or whether to) address that debt, eventually
      adding them to the iteration plan with stories. Obviously, there is nothing
      wrong with carrying debt if there are more pressing concerns - you just need
      remain aware you are carrying it.

      I would write technical debt out as something like this:

      Fat controllers.
      Our Controller classes are riddled with duplication. Some action methods are
      80 lines long! It takes (me anyway) at least half an hour to work out
      what's actually going on in these methods. Because of all the mocking our
      controller developer tests are becoming unreadable. We currently have over
      30 actions across 8 controllers. This is only going to get worse as
      development progresses.
      What needs done:
      We need break these action methods up and move much of the logic into our
      model classes (which at the moment are just an anemic data model). This
      would simplify our controller tests, and give us nice simple model tests. I
      don't know how long this would take, I'm thinking maybe an hour per action?
      Even if we do this gradually, we should find the system easier to understand
      and easier to test.



      2008/12/1 Olof Bjarnason <olof.bjarnason@...>

      > 2008/11/30 Craig Davidson <craigmdavidson@...>:
      > > Hi Pieter,
      > >
      > > You wrote:
      > > I wish to (re)introduce XP to our team, because our system is suffering
      > > from years of technical debt.
      > >
      > > Are you currently tracking technical debt? Is it and it's impact visible
      > > enough to motivate the team to re-evaluate what they are doing?
      > > Is there a way you make your technical debt, it's impact, and what it
      > would
      > > take to "pay it off" more visible to the project team and the
      > stakeholders?
      >
      > Interesting - How do you measure technical debt?
      >
      > >
      > > Cheers,
      > >
      > > Craig
      > >
      > > 2008/11/28 Pieter Nagel <pieter@...>
      > >
      > >> I wish to (re)introduce XP to our team, because our system is suffering
      > >> from years of technical debt.
      > >>
      > >> Our original team used to do (relatively complete) XP from 2000-2003,
      > >> but the original team split under acrimonious circumstances, leaving
      > >> just me alone.
      > >>
      > >> Unfortunately I was unable to reintroduce XP when we hired our first new
      > >> developer. In retrospect, pairing with the same person for weeks on end
      > >> was not a good idea, and I was not mature enough to shift the
      > >> "master/novice" imbalance into an "equal peers" situation. After two
      > >> months he asked that we stop pairing since it wasn't working for him;
      > >> and XP died.
      > >>
      > >> I had breakfast with the MD yesterday, and she is very supportive of the
      > >> idea of us going XP instead. We share a mutual concern about or
      > >> development velocity, and she said the XP planning practices sounded
      > >> like "common sense". I've begun floating the idea of pair programming to
      > >> the team as well, and it seems most developers would be open.
      > >>
      > >> The catch is this: the initial extra developer, who had the bad pairing
      > >> experience, volunteered to become PM a few years ago. And, to be honest,
      > >> he made a mess of it. He introduced a homebrew pseudo Cargo Cult Scrum
      > >> (minus estimation, Sprint planning sessions, retrospectives, or a well
      > >> defined backlog). He himself was frustrated and wanted to step down and
      > >> become "just a developer" again, and so asked the company to recruit a
      > >> "real PM". The recruitment failed, and he's still stuck where he is.
      > >>
      > >> The obvious solution would be to tell the current PM: "Relax, thanks for
      > >> all your help, rescue is on the way, you may step down as you want - but
      > >> instead of handing over to a *person*, you'll be handing over to a team
      > >> *process*".
      > >>
      > >> The weird thing is, despite the fact that the PM wants to step down,
      > >> both me and the MD have the impression that he would resist any attempt
      > >> by me to coach the team in XP. We guess it's because it would feel like
      > >> an acknowledgement of failure to him.
      > >>
      > >> We're concerned about him being stretched to the breaking point and
      > >> resigning, and thereby losing his considerable knowledge of the system.
      > >>
      > >> The only concrete thing I can think of right now is to send him an email
      > >> (he doesn't like face-to-face communication. Hmm) and ask him how he
      > >> would feel about me introducing pairing as a tool to help dig us out of
      > >> our technical debt - even if only limited at first, amongst those who
      > >> are comfortable, and since he's had to suffer a bad pairing experience
      > >> he can stand back and watch at first if he wants to.
      > >>
      > >> If he's open to pairing, my guess is he'll be open to letting go of the
      > >> PM responsibilities he dislikes, and becoming part of a re-formed XP
      > >> team as well.
      > >>
      > >> Advice?
      > >>
      > >> --
      > >> ,_
      > >> /_) /| /
      > >> / i e t e r / |/ a g e l
      > >>
      > >>
      > >>
      > >> ------------------------------------
      > >>
      > >> To Post a message, send it to: extremeprogramming@...
      > >>
      > >> To Unsubscribe, send a blank message to:
      > >> extremeprogramming-unsubscribe@...
      > >>
      > >> ad-free courtesy of objectmentor.comYahoo! Groups Links
      > >>
      > >>
      > >>
      > >>
      > >
      > > [Non-text portions of this message have been removed]
      > >
      > >
      >
      > ------------------------------------
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.comYahoo! Groups Links
      >
      >
      >
      >


      [Non-text portions of this message have been removed]
    • banshee858
      ... A good start would be to think about what sort of needs your organization has and identify the (XP) requirements which meet those needs. I have a
      Message 2 of 23 , Dec 1, 2008
      • 0 Attachment
        >
        > Advice?
        >
        A good start would be to think about what sort of needs your
        organization has and identify the (XP) requirements which meet those
        needs. I have a structured set of thinking exercises I use when I
        coach teams on how to transition to Agile processes which might be
        helpful here. If you are in San Diego this week, I will be running a
        workshop on how to do this at the local XPSD (www.xpsd.org) meeting.

        Carlton

        www.carltonnettleton.com\blog
      • Mike Coon
        So have you talked to this PM about the pairing experience you had together? Have you acknowledged your shortcomings to him in a way that might allow him to
        Message 3 of 23 , Dec 1, 2008
        • 0 Attachment
          So have you talked to this PM about the pairing experience you had
          together? Have you acknowledged your shortcomings to him in a way that
          might allow him to trust you and help in your efforts?

          Why was original XP team's breakup acrimonious? Have the factors that
          contributed to that been addressed?

          Is pairing the thing you need most? Does the team understand refactoring?
          Do you have unit tests? Functional tests? Automated regression tests? A
          prioritized backlog?

          If technical debt is the problem you're trying to solve is pairing really
          the highest priority practice to start with?


          Mike

          On Mon, Dec 1, 2008 at 7:20 PM, banshee858 <cnett858@...> wrote:

          > >
          > > Advice?
          > >
          > A good start would be to think about what sort of needs your
          > organization has and identify the (XP) requirements which meet those
          > needs. I have a structured set of thinking exercises I use when I
          > coach teams on how to transition to Agile processes which might be
          > helpful here. If you are in San Diego this week, I will be running a
          > workshop on how to do this at the local XPSD (www.xpsd.org) meeting.
          >
          > Carlton
          >
          > www.carltonnettleton.com\blog
          >
          >
          >



          --
          http://mikeonitstuff.net/ New Blog
          http://mikeonitstuff.com/ Old Blog
          http://mikeonbikes.blogspot.com/


          [Non-text portions of this message have been removed]
        • Olof Bjarnason
          Thanks for you answer Craig.. After I stated the question here on the list - I thought about it a little. One good indicator of technical dept is duplicated
          Message 4 of 23 , Dec 1, 2008
          • 0 Attachment
            Thanks for you answer Craig..

            After I stated the question here on the list - I thought about it a little.

            One good indicator of technical dept is duplicated code. So I looked
            for tools that can find code duplication and found a bunch:

            - simian: competent but costs like $500 for a commercial project
            license. Tokenizes/parses the code enabling"similar looking" pieces to
            be found
            - duplo: minimalistic and free - but can only find exact matching
            lines of duplication.

            .. just to name those I tried out.

            You are mentioning "fat controllers" -- classes with too much
            responsibility. A measure of how "fat" a class is might be the number
            of named fields it has - how much state it is responsible for?

            Another measure would be "long methods" - just cound number of lines
            or number of semicolons.

            All of theses measures could be part of the build process or maybe a
            separate monitor program, run for example during meetings.

            Actually, I think FxCop (microsofts free code measure tool) has a lot
            of these measures built-in. But it is so huge I find it hard to use.

            /Olof


            2008/12/2 Craig Davidson <craigmdavidson@...>:
            > Hi Olof,
            >
            > I don't use the word "measure", that suggests a degree of precision that I
            > don't get.
            >
            > You can observe it's impact (subjectively is fine - If it has negligible
            > impact is it really a technical debt?).
            > And you can guesstimate what it would take to pay it off.
            >
            > To track debt, I like to write the main offenders as notes or index cards
            > put them on a Technical Debit wall or column.
            > This makes it visible to the team and stakeholders - I find without that
            > visibility it is easily ignored - until something crunches.
            > As a team we work out how (or whether to) address that debt, eventually
            > adding them to the iteration plan with stories. Obviously, there is nothing
            > wrong with carrying debt if there are more pressing concerns - you just need
            > remain aware you are carrying it.
            >
            > I would write technical debt out as something like this:
            >
            > Fat controllers.
            > Our Controller classes are riddled with duplication. Some action methods are
            > 80 lines long! It takes (me anyway) at least half an hour to work out
            > what's actually going on in these methods. Because of all the mocking our
            > controller developer tests are becoming unreadable. We currently have over
            > 30 actions across 8 controllers. This is only going to get worse as
            > development progresses.
            > What needs done:
            > We need break these action methods up and move much of the logic into our
            > model classes (which at the moment are just an anemic data model). This
            > would simplify our controller tests, and give us nice simple model tests. I
            > don't know how long this would take, I'm thinking maybe an hour per action?
            > Even if we do this gradually, we should find the system easier to understand
            > and easier to test.
            >
            > 2008/12/1 Olof Bjarnason <olof.bjarnason@...>
            >
            >> 2008/11/30 Craig Davidson <craigmdavidson@...>:
            >> > Hi Pieter,
            >> >
            >> > You wrote:
            >> > I wish to (re)introduce XP to our team, because our system is suffering
            >> > from years of technical debt.
            >> >
            >> > Are you currently tracking technical debt? Is it and it's impact visible
            >> > enough to motivate the team to re-evaluate what they are doing?
            >> > Is there a way you make your technical debt, it's impact, and what it
            >> would
            >> > take to "pay it off" more visible to the project team and the
            >> stakeholders?
            >>
            >> Interesting - How do you measure technical debt?
            >>
            >> >
            >> > Cheers,
            >> >
            >> > Craig
            >> >
            >> > 2008/11/28 Pieter Nagel <pieter@...>
            >> >
            >> >> I wish to (re)introduce XP to our team, because our system is suffering
            >> >> from years of technical debt.
            >> >>
            >> >> Our original team used to do (relatively complete) XP from 2000-2003,
            >> >> but the original team split under acrimonious circumstances, leaving
            >> >> just me alone.
            >> >>
            >> >> Unfortunately I was unable to reintroduce XP when we hired our first
            >> >> new
            >> >> developer. In retrospect, pairing with the same person for weeks on end
            >> >> was not a good idea, and I was not mature enough to shift the
            >> >> "master/novice" imbalance into an "equal peers" situation. After two
            >> >> months he asked that we stop pairing since it wasn't working for him;
            >> >> and XP died.
            >> >>
            >> >> I had breakfast with the MD yesterday, and she is very supportive of
            >> >> the
            >> >> idea of us going XP instead. We share a mutual concern about or
            >> >> development velocity, and she said the XP planning practices sounded
            >> >> like "common sense". I've begun floating the idea of pair programming
            >> >> to
            >> >> the team as well, and it seems most developers would be open.
            >> >>
            >> >> The catch is this: the initial extra developer, who had the bad pairing
            >> >> experience, volunteered to become PM a few years ago. And, to be
            >> >> honest,
            >> >> he made a mess of it. He introduced a homebrew pseudo Cargo Cult Scrum
            >> >> (minus estimation, Sprint planning sessions, retrospectives, or a well
            >> >> defined backlog). He himself was frustrated and wanted to step down and
            >> >> become "just a developer" again, and so asked the company to recruit a
            >> >> "real PM". The recruitment failed, and he's still stuck where he is.
            >> >>
            >> >> The obvious solution would be to tell the current PM: "Relax, thanks
            >> >> for
            >> >> all your help, rescue is on the way, you may step down as you want -
            >> >> but
            >> >> instead of handing over to a *person*, you'll be handing over to a team
            >> >> *process*".
            >> >>
            >> >> The weird thing is, despite the fact that the PM wants to step down,
            >> >> both me and the MD have the impression that he would resist any attempt
            >> >> by me to coach the team in XP. We guess it's because it would feel like
            >> >> an acknowledgement of failure to him.
            >> >>
            >> >> We're concerned about him being stretched to the breaking point and
            >> >> resigning, and thereby losing his considerable knowledge of the system.
            >> >>
            >> >> The only concrete thing I can think of right now is to send him an
            >> >> email
            >> >> (he doesn't like face-to-face communication. Hmm) and ask him how he
            >> >> would feel about me introducing pairing as a tool to help dig us out of
            >> >> our technical debt - even if only limited at first, amongst those who
            >> >> are comfortable, and since he's had to suffer a bad pairing experience
            >> >> he can stand back and watch at first if he wants to.
            >> >>
            >> >> If he's open to pairing, my guess is he'll be open to letting go of the
            >> >> PM responsibilities he dislikes, and becoming part of a re-formed XP
            >> >> team as well.
            >> >>
            >> >> Advice?
            >> >>
            >> >> --
            >> >> ,_
            >> >> /_) /| /
            >> >> / i e t e r / |/ a g e l
            >> >>
            >> >>
            >> >>
            >> >> ------------------------------------
            >> >>
            >> >> To Post a message, send it to: extremeprogramming@...
            >> >>
            >> >> To Unsubscribe, send a blank message to:
            >> >> extremeprogramming-unsubscribe@...
            >> >>
            >> >> ad-free courtesy of objectmentor.comYahoo! Groups Links
            >> >>
            >> >>
            >> >>
            >> >>
            >> >
            >> > [Non-text portions of this message have been removed]
            >> >
            >> >
            >>
            >> ------------------------------------
            >>
            >> To Post a message, send it to: extremeprogramming@...
            >>
            >> To Unsubscribe, send a blank message to:
            >> extremeprogramming-unsubscribe@...
            >>
            >> ad-free courtesy of objectmentor.comYahoo! Groups Links
            >>
            >>
            >>
            >>
            >
            > [Non-text portions of this message have been removed]
            >
            >
          • Pieter Nagel
            ... I ve emailed him last week (he explicitly asked that Big Things and proposed process changes be emailed to him, so he can mull them over, since he does
            Message 5 of 23 , Dec 2, 2008
            • 0 Attachment
              On Mon, 2008-12-01 at 19:40 -0600, Mike Coon wrote:
              > Have you acknowledged your shortcomings to him in a way that
              > might allow him to trust you and help in your efforts?

              I've emailed him last week (he explicitly asked that Big Things and
              proposed process changes be emailed to him, so he can mull them over,
              since he "does not communicate well on his feet"). No reply yet, but
              that's normal.

              > Why was original XP team's breakup acrimonious? Have the factors that
              > contributed to that been addressed?

              Some members of the team engaged in back-channel strong-arm dealing with
              the project sponsor in order to try and obtain profit share for
              themselves.

              > Is pairing the thing you need most? Does the team understand
              > refactoring?

              The team knows refactoring but they still don't grok it.

              Pairing will allow:

              - Coaching the team in what the TDD rhythm is, how incredibly small
              those steps can be, how important the small mechnical refactorings can
              be if not done etc. - by doing together instead of speeches.

              - Honing the teams refactoring skills.

              - Removing cognitive barriers that make people hesitant to touch other
              code as part of their refactorings. Without that, we too often end up
              with small localised refactorings that aren't system-wide and thus
              achieve nothing except introducing Yet Another Different Way of Doing X.

              - Paying down technical debt will cause new consolidated abstractions
              to be created at a high rate, and pairing is the best way I know of
              communicating the existence of these new abstractions to the rest of the
              team (else they just continue writing old-style code that "inlines" the
              abstractions, as it were).

              - And then there's the issue that pairing can give the moral support to
              stick with it and keep at paying down the technical debt and applying
              TDD.

              My idea is to first just go after low-hanging fruit. Firstly, so the
              team can improve its code-cleanup skills. Secondly, because often those
              very same silly little low-hanging smells are in the way of the Big
              Refactorings anyway.

              As skills improve, we can start taking careful stabs at bigger
              refactorings that aim at the most painful coupling issues etc. But by
              then, hopefully, the approach would have formed organically anyway.

              > Do you have unit tests? Functional tests? Automated regression tests?

              We have tests. That's the one bit of XP culture that has survived.

              The tests fixtures are too complicated, so they're more like integration
              tests than proper isolated unit tests. For technical reasons all our GUI
              tests are end-to-end tests instead of unit tests (the knock-on result
              should come as no surprise: there arent' any proper reusable "units" in
              our GUI). Our tests take too long to run.

              But at least we have tests. That's the one saving grace that makes me
              confident that we can introduce most or all of the XP practices.

              > A prioritized backlog?

              Ironically, despite the fact that we're supposedly doing Scrum, we do
              not. The PM doles out multiple parallel streams of development, so that
              the 4 people on the team are always busy with 8 "stories" concurrently.

              The first thing I'd do is to smooth out development by using a strict
              priority based queue and always taking just one thing from the top. As
              far as possible, I'd like the entire team to always work on the
              technical tasks of one single story at a time.

              > If technical debt is the problem you're trying to solve is pairing
              > really
              > the highest priority practice to start with?

              I believe so.
            • Mike Coon
              So what I might try in your position would be to ask for help in a casual way. Hey, I want to redo the tests for this component do you mind being a second
              Message 6 of 23 , Dec 2, 2008
              • 0 Attachment
                So what I might try in your position would be to ask for help in a casual
                way. "Hey, I want to redo the tests for this component do you mind being a
                second set of eyes and maybe helping me find the best approach?" Get people
                used to working together for short periods on small problems. And, by all
                means, avoid the appearance of thinking yourself superior - not saying you
                do, but it's a risk. People have to know that you're on their side, in the
                trenches with them, and trying to help them *be successful at what they want
                to do*.

                The PM seems to be a pretty big impediment to the way you want to do
                things. Does he control actual assignments on the team? If you have any
                control of the assignment of work, you could assign each item to two people
                and explain that you expect each of them to be up to speed on their items.
                This is not really XP or scrum - what with you doing the assignments - but
                it will encourage people to work together, even if only to avoid the
                embarrassment of ignorance.

                Of course this might be terrible advice :-)

                Mike

                On Tue, Dec 2, 2008 at 1:13 PM, Pieter Nagel <pieter@...> wrote:

                > On Mon, 2008-12-01 at 19:40 -0600, Mike Coon wrote:
                > > Have you acknowledged your shortcomings to him in a way that
                > > might allow him to trust you and help in your efforts?
                >
                > I've emailed him last week (he explicitly asked that Big Things and
                > proposed process changes be emailed to him, so he can mull them over,
                > since he "does not communicate well on his feet"). No reply yet, but
                > that's normal.
                >
                > > Why was original XP team's breakup acrimonious? Have the factors that
                > > contributed to that been addressed?
                >
                > Some members of the team engaged in back-channel strong-arm dealing with
                > the project sponsor in order to try and obtain profit share for
                > themselves.
                >
                > > Is pairing the thing you need most? Does the team understand
                > > refactoring?
                >
                > The team knows refactoring but they still don't grok it.
                >
                > Pairing will allow:
                >
                > - Coaching the team in what the TDD rhythm is, how incredibly small
                > those steps can be, how important the small mechnical refactorings can
                > be if not done etc. - by doing together instead of speeches.
                >
                > - Honing the teams refactoring skills.
                >
                > - Removing cognitive barriers that make people hesitant to touch other
                > code as part of their refactorings. Without that, we too often end up
                > with small localised refactorings that aren't system-wide and thus
                > achieve nothing except introducing Yet Another Different Way of Doing X.
                >
                > - Paying down technical debt will cause new consolidated abstractions
                > to be created at a high rate, and pairing is the best way I know of
                > communicating the existence of these new abstractions to the rest of the
                > team (else they just continue writing old-style code that "inlines" the
                > abstractions, as it were).
                >
                > - And then there's the issue that pairing can give the moral support to
                > stick with it and keep at paying down the technical debt and applying
                > TDD.
                >
                > My idea is to first just go after low-hanging fruit. Firstly, so the
                > team can improve its code-cleanup skills. Secondly, because often those
                > very same silly little low-hanging smells are in the way of the Big
                > Refactorings anyway.
                >
                > As skills improve, we can start taking careful stabs at bigger
                > refactorings that aim at the most painful coupling issues etc. But by
                > then, hopefully, the approach would have formed organically anyway.
                >
                > > Do you have unit tests? Functional tests? Automated regression tests?
                >
                > We have tests. That's the one bit of XP culture that has survived.
                >
                > The tests fixtures are too complicated, so they're more like integration
                > tests than proper isolated unit tests. For technical reasons all our GUI
                > tests are end-to-end tests instead of unit tests (the knock-on result
                > should come as no surprise: there arent' any proper reusable "units" in
                > our GUI). Our tests take too long to run.
                >
                > But at least we have tests. That's the one saving grace that makes me
                > confident that we can introduce most or all of the XP practices.
                >
                > > A prioritized backlog?
                >
                > Ironically, despite the fact that we're supposedly doing Scrum, we do
                > not. The PM doles out multiple parallel streams of development, so that
                > the 4 people on the team are always busy with 8 "stories" concurrently.
                >
                > The first thing I'd do is to smooth out development by using a strict
                > priority based queue and always taking just one thing from the top. As
                > far as possible, I'd like the entire team to always work on the
                > technical tasks of one single story at a time.
                >
                > > If technical debt is the problem you're trying to solve is pairing
                > > really
                > > the highest priority practice to start with?
                >
                > I believe so.
                >
                >
                >



                --
                http://mikeonitstuff.net/ New Blog
                http://mikeonitstuff.com/ Old Blog
                http://mikeonbikes.blogspot.com/


                [Non-text portions of this message have been removed]
              • banshee858
                ... Guess what? If you don t have a prioritized backlog you are not doing Scrum. You might be doing something iterative or incremental, but certainly not
                Message 7 of 23 , Dec 3, 2008
                • 0 Attachment
                  >
                  > > A prioritized backlog?
                  >
                  > Ironically, despite the fact that we're supposedly doing Scrum, we
                  > do not. The PM doles out multiple parallel streams of development,
                  > so that the 4 people on the team are always busy with 8 "stories"
                  > concurrently.
                  >
                  Guess what? If you don't have a prioritized backlog you are not doing
                  Scrum. You might be doing something iterative or incremental, but
                  certainly not Scrum.

                  Carlton
                • Pieter Nagel
                  ... Oh, I m in total agreement. Our PM s claims to the contrary leave me alternatively sad and vexed.
                  Message 8 of 23 , Dec 3, 2008
                  • 0 Attachment
                    On Wed, 2008-12-03 at 18:22 +0000, banshee858 wrote:

                    > Guess what? If you don't have a prioritized backlog you are not doing
                    > Scrum.

                    Oh, I'm in total agreement. Our PM's claims to the contrary leave me
                    alternatively sad and vexed.
                  • banshee858
                    ... I am just going to echo the posts other people have mentioned - improve your relationship with the PM and build trust. I will also bring up something that
                    Message 9 of 23 , Dec 4, 2008
                    • 0 Attachment
                      >
                      > > Guess what? If you don't have a prioritized backlog you are not
                      > > doing Scrum.
                      >
                      > Oh, I'm in total agreement. Our PM's claims to the contrary leave me
                      > alternatively sad and vexed.
                      >
                      I am just going to echo the posts other people have mentioned -
                      improve your relationship with the PM and build trust.

                      I will also bring up something that might not have been raised
                      earlier: this project (or series of projects) may not be good
                      candidate for Scrum or XP. Pilot projects succeed best when working
                      on new development with co-located teams with dedicated people and
                      customers\product owners. When an organization has experience and
                      success with these techniques, they can rationally apply them to the
                      "tough projects". Perhaps a tactic might be to "back off" of Scrum
                      for now with the trade off (and commitment) of using "real Scrum" on
                      the next new project?

                      Carlton
                    • Pieter Nagel
                      ... This project is a mature 8 year old system approaching legacy status. It is the only project in the company. There is no other project to try out XP on,
                      Message 10 of 23 , Dec 4, 2008
                      • 0 Attachment
                        On Thu, 2008-12-04 at 20:26 +0000, banshee858 wrote:

                        > Perhaps a tactic might be to "back off" of Scrum
                        > for now with the trade off (and commitment) of using "real Scrum" on
                        > the next new project?

                        This project is a mature 8 year old system approaching "legacy" status.
                        It is the only project in the company. There is no other project to try
                        out XP on, or none with any value. This project is the company, without
                        it the company will most likely not survive. However, the project
                        started out its first 3 years as an XP project in a relatively pure
                        sense of the word. As such, I don't think this project is ill-suited for
                        returning back home to its XP roots.

                        Things are moving; most stakeholders are keen on XP now. Management and
                        the project sponsor/product visionary perceive the political obstacles
                        to introducing XP as their own problems, too.
                      • Steven Gordon
                        ... So, they do understand that XP would involve active involvement of the business side (including maintaining a prioritized backlog of user stories), not
                        Message 11 of 23 , Dec 4, 2008
                        • 0 Attachment
                          On Thu, Dec 4, 2008 at 3:40 PM, Pieter Nagel <pieter@...> wrote:
                          > On Thu, 2008-12-04 at 20:26 +0000, banshee858 wrote:
                          >
                          >> Perhaps a tactic might be to "back off" of Scrum
                          >> for now with the trade off (and commitment) of using "real Scrum" on
                          >> the next new project?
                          >
                          > This project is a mature 8 year old system approaching "legacy" status.
                          > It is the only project in the company. There is no other project to try
                          > out XP on, or none with any value. This project is the company, without
                          > it the company will most likely not survive. However, the project
                          > started out its first 3 years as an XP project in a relatively pure
                          > sense of the word. As such, I don't think this project is ill-suited for
                          > returning back home to its XP roots.
                          >
                          > Things are moving; most stakeholders are keen on XP now. Management and
                          > the project sponsor/product visionary perceive the political obstacles
                          > to introducing XP as their own problems, too.
                          >

                          So, they do understand that XP would involve active involvement of the
                          business side (including maintaining a prioritized backlog of user
                          stories), not just requiring the developers be more disciplined.
                        • Pieter Nagel
                          ... She does, and the greater business involvement is the one big thing that appeals to her. I don t think she knows yet how far the implications of this go,
                          Message 12 of 23 , Dec 4, 2008
                          • 0 Attachment
                            On Thu, 2008-12-04 at 18:06 -0700, Steven Gordon wrote:

                            > So, they do understand that XP would involve active involvement of the
                            > business side (including maintaining a prioritized backlog of user
                            > stories), not just requiring the developers be more disciplined.

                            She does, and the greater business involvement is the one big thing that
                            appeals to her. I don't think she knows yet how far the implications of
                            this go, but she also feels that there is a lack of business people who
                            are engaged in driving the customer's (her) desires. All this is an
                            ongoing conversation, and the implications of Whole Team and Sit
                            Together are the next topic I want to chat with her about.

                            For the moment, I've given her some literature on XP, which she is
                            obviously devouring, and today my copy of James Shore's book will be
                            deliverd. I'll promptly gift-wrap it, along with some highligther
                            markers, and put it on her table as an early Christmass gift, with a
                            note saying please scribble in it so we can have an ongoing
                            converstation about what you like, dislike, or don't understand.

                            That means James is one lucky boy, since I already had to put in a
                            second order of his book so I can have one too. ;-)
                          • banshee858
                            ... Get ready for some hard feedback - I think you are being too solution oriented. I suspect you do not understand what your organization really wants, but
                            Message 13 of 23 , Dec 5, 2008
                            • 0 Attachment
                              >
                              > > Perhaps a tactic might be to "back off" of Scrum
                              > > for now with the trade off (and commitment) of using "real Scrum"
                              > > on the next new project?
                              >
                              > This project is a mature 8 year old system approaching "legacy"
                              > status. It is the only project in the company. There is no other
                              > project to try out XP on, or none with any value. This project is
                              > the company, without it the company will most likely not survive.
                              > However, the project started out its first 3 years as an XP project
                              > in a relatively pure sense of the word. As such, I don't think this
                              > project is ill-suited for returning back home to its XP roots.
                              >
                              Get ready for some hard feedback - I think you are being too solution
                              oriented. I suspect you do not understand what your organization
                              really wants, but are intent on giving XP as the solution because that
                              is what you want to do. XP is a solution for some problems, but not
                              all.

                              I would suggest you do some analysis on what the organization is
                              saying are the problems, derive some requirements which will define a
                              change initiative and work with the stakeholders, executives &
                              participants to build some objective measures to monitor the progress
                              of the initiative. Why would someone empower you to change "the
                              project" which is the lifeblood of the company in these economic times
                              without first showing you have a thoughtful plan on how to change,
                              that you have incorporated the viewpoints of the different
                              stakeholders and some simple metrics to monitor the change?

                              Carlton
                            • Pieter Nagel
                              ... As far as I understand it, the organization s wants to overtake competitors again, which will require a reversal of the development slowdown; insight and
                              Message 14 of 23 , Dec 5, 2008
                              • 0 Attachment
                                On Fri, 2008-12-05 at 17:53 +0000, banshee858 wrote:

                                > Get ready for some hard feedback - I think you are being too solution
                                > oriented. I suspect you do not understand what your organization
                                > really wants, but are intent on giving XP as the solution because that
                                > is what you want to do.

                                As far as I understand it, the organization's wants to overtake
                                competitors again, which will require a reversal of the development
                                slowdown; insight and oversight into what is going on in development;
                                and the ability for more in-house domain experts to contribute to
                                product development.

                                I believe XP can give us all that.

                                There's also growing awareness of the issue of technical debt and how it
                                relates to the slowdown in development, and awareness that paying down
                                the debt is the only viable long-term survival strategy. When the
                                sponsor realized that I didn't want to "close up shop" to "clean up the
                                system for a year" but instead wanted to pay down debt incrementally,
                                focussing on the debt with highest impact on business value, whilst
                                continuing to develop new features, the lightbulb lit up.

                                But these are all issues I'm still doing a lot of talking around,
                                because I do want to make very sure the organization knows what we'll be
                                embarking on.
                              Your message has been successfully submitted and would be delivered to recipients shortly.