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

Re: Need advice preparing the waters for XP

Expand Messages
  • Jonathan Rasmusson
    Hi Pieter, After reading your post, I sense a lot of drama and anxiety. My advice would be to relax, and stop worring to much about others, and instead focus
    Message 1 of 23 , Nov 29, 2008
    • 0 Attachment
      Hi Pieter,

      After reading your post, I sense a lot of drama and anxiety.

      My advice would be to relax, and stop worring to much about others,
      and instead focus on yourself.

      Set expectations on how you are going to write software.
      Do it the way you know it needs to be done.
      Master yourself, and be less concerned others.

      Then be patient, and look for opportunities.

      You already have a lot going for you.

      For one you are asking questions on news groups.

      More importantly you are self aware, and mature enough to acknowledge
      that pairing with some people can be hard, and you will have to adjust.

      Take your time, and do what needs to be done.

      If it comes from a good place, trust, respect, and good things will
      follow.

      Best of luck,

      Jonathan Rasmusson


      --- In extremeprogramming@yahoogroups.com, Pieter Nagel <pieter@...>
      wrote:
      >
      > 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
      >
    • Pieter Nagel
      ... 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
      Message 2 of 23 , Nov 30, 2008
      • 0 Attachment
        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.
      • Craig Davidson
        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
        Message 3 of 23 , Nov 30, 2008
        • 0 Attachment
          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?


          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]
        • Olof Bjarnason
          ... Interesting - How do you measure technical debt?
          Message 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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.