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

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

Expand Messages
  • Mike Coon
    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]
    • Show all 23 messages in this topic