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

Need advice preparing the waters for XP

Expand Messages
  • Pieter Nagel
    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
    Message 1 of 23 , Nov 27, 2008
    • 0 Attachment
      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
    • Steven Gordon
      ... If he does not learn to handle face-to-face communication, admitting and correcting mistakes, etc, there are only 3 possible outcomes: 1. the adoption of
      Message 2 of 23 , Nov 27, 2008
      • 0 Attachment
        On Thu, Nov 27, 2008 at 9:19 AM, 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?

        If he does not learn to handle face-to-face communication, admitting
        and correcting mistakes, etc, there are only 3 possible outcomes:
        1. the adoption of the new process will fail,
        2. he will be leaving the company.
        3. he will be leaving the team, but be given a different position in
        the company.

        Often, when a legacy product is being triaged, there is a period of
        time in which it can make sense to have a small separate team
        maintaining the product for the customer base while the new team does
        new development (while attacking the technical debt that most directly
        impacts that new development). If you go this route, this person
        might be a good candidate to lead the maintenance team. Once the
        other members of the team have learned what he knows and the new
        development is ready to become the next release, then the maintenance
        team (with or without its leader) can be folded into the development
        team.

        >
        > --
        > ,_
        > /_) /| /
        > / i e t e r / |/ a g e l
        >
      • D. André Dhondt
        It sounds like you really want to gain the support of this PM, and I think it makes sense to collaborate with him. How about starting a book discussion, and
        Message 3 of 23 , Nov 27, 2008
        • 0 Attachment
          It sounds like you really want to gain the support of this PM, and I think
          it makes sense to collaborate with him. How about starting a book
          discussion, and reading a chapter or two a week of XP Explained? Then every
          Wednesday or so, talk as a team about what you've been reading, whether
          there are ideas in it that could apply to you, etc. Don't worry about roles
          yet, try to get lots of people on the same page in terms of what this
          process should look like. Or if you're in for more detail about the
          practices, read the Art of Agile Development together (by James Shore and
          James Warden).

          On Thu, Nov 27, 2008 at 5:19 PM, 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
          >
          >
          >



          --
          D. André Dhondt
          mobile: 001 33 671 034 984


          [Non-text portions of this message have been removed]
        • Pieter Nagel
          ... This sounds a lot like what I would want to do, ideally. Except I would add pizzas or a brown paper bag lunch to the mix, and I would prefer to work from
          Message 4 of 23 , Nov 28, 2008
          • 0 Attachment
            On Fri, 2008-11-28 at 08:36 +0100, D. André Dhondt wrote:
            > How about starting a book
            > discussion, and reading a chapter or two a week of XP Explained? Then
            > every
            > Wednesday or so, talk as a team about what you've been reading,

            This sounds a lot like what I would want to do, ideally. Except I would
            add pizzas or a brown paper bag lunch to the mix, and I would prefer to
            work from James Shore's book (which I plan to give to the MD as a
            surprise early Christmas gift).

            James's book is more to the Shu side, where Kent's book is more to the
            Ri side. And I think my team needs to see the Shu before they'll "get
            it". They've been exposed to too many bastardizations like "information
            radiator" means "project whiteboard in a small, out of the way,
            storeroom" (???)

            The reason why I chatted to the MD first is so that if the rumours start
            reaching her, she already knows what's going on. And that was a good
            conversation. I actually think I'm going to like closer interaction with
            the customers.

            As far as the impression that the PM will resist goes, I should maybe
            discuss that with friends, offline. Just in case he stumbles across this
            thread...

            --
            ,_
            /_) /| /
            / i e t e r / |/ a g e l
          • 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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.