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

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

Expand Messages
  • Olof Bjarnason
    ... Interesting - How do you measure technical debt?
    Message 1 of 23 , Nov 30, 2008
    • 0 Attachment
      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]
      >
      >
    • Steven Gordon
      ... Pieter, Calm just sounds like going back to silently expecting things to get better until you get too frustrated again. Even better would be attempting to:
      Message 2 of 23 , Dec 1, 2008
      • 0 Attachment
        On Sun, Nov 30, 2008 at 1:42 AM, Pieter Nagel <pieter@...> wrote:
        > On Sat, 2008-11-29 at 17:51 +0000, Jonathan Rasmusson wrote:
        >>
        >> Hi Pieter,
        >>
        >> After reading your post, I sense a lot of drama and anxiety.
        >
        > Thanks for the advice.
        >
        > I do have the tendency to complacently suffer in silence for a long
        > time. Then suddenly a lightbulb goes off, I see a root cause of a
        > problem, and I want to do something NOW!
        >
        > But other people first have to see the lightbulb - or the very problem
        > itself - for themselves, and things don't go so fast as I want, and I
        > become a frustrated.
        >
        > Calm would be better.
        >

        Pieter,

        Calm just sounds like going back to silently expecting things to get
        better until you get too frustrated again.

        Even better would be attempting to:
        - help the people who are together with you in this "same boat" to
        think of themselves as a single team with a common purpose,
        - help this team form a consensus on what is good, what is bad and how
        to make things better (by listening, constructively engaging, and
        sometimes making suggestions),
        - stay as balanced and consistent as possible (i.e., - proactively
        engage with people and lead by example every day, as opposed to
        alternating between passively expecting people to have the same views
        as you and aggressively trying to impose your own views) .

        Not that I am always successful at doing this myself :)

        Steve
      • 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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.