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

RE: [XP] Starting XP, looking for suggestions.

Expand Messages
  • Amir Kolsky
    I might be stating the obvious, or the dubious, but the BEST thing you can do to get yourself started in XP is to get yourself a good XP coach for at least a
    Message 1 of 16 , Jan 2, 2006
      I might be stating the obvious, or the dubious, but the BEST thing you can
      do to get yourself started in XP is to get yourself a good XP coach for at
      least a few months.

      Amir Kolsky
      XP& Software


      >-----Original Message-----
      >From: extremeprogramming@yahoogroups.com
      >[mailto:extremeprogramming@yahoogroups.com] On Behalf Of jeffadams78
      >Sent: Friday, December 30, 2005 12:29 AM
      >To: extremeprogramming@yahoogroups.com
      >Subject: [XP] Starting XP, looking for suggestions.
      >
      >I'm a "tech lead" with a small team (4 developers) and I'm
      >looking to start transitioning us over to XP. What I'm
      >looking for are suggestions for the best way to start, what
      >are some of the best practices to introduce first.
      >
      >Some background: I'm working for a medium-size (150-200
      >person) mostly software company doing defense contracting.
      >The project consists of three teams (all 4-6 developers) at
      >geographically diverse locations.
      > The tech manager and program manager are both used to
      >waterfall / spiral type development and are not enthusiastic
      >about me trying XP with my team, but they are not going to
      >stop me (unless I'm unsuccessful by the end of our first
      >development "spiral" in 3 months). However they do want a lot
      >of standard type output from me (a detailed plan for the whole
      >three months, design documents, etc).
      >
      >My team is working on the back-end part of the system,
      >ingesting data and providing it to the middle-stage, which
      >then does more work and provides it to clients. So one of the
      >difficulties I'm having is coming up with user stories, since
      >what we're working on is very removed from what the actual
      >user sees. I'm thinking maybe I'll just go with developer
      >stories instead, based on the development tasks we need to do,
      >but I was wondering if anyone had suggestions from working in
      >a similar situation? The only user stories I can think of are
      >too high-level to be very useful, such as "Ingest data type
      >XYZ". But that's a task that will take weeks, much of which
      >is not necessarily coding but more communication: finding and
      >reading specs, getting test data, etc.
      >
      >Next, I have a team which is somewhat reluctant to move
      >rapidly to an "unusual" (to them) development style. I want
      >to get them to try it, but I also don't want to be obnoxious
      >about pushing a ton of changes on them. What are the
      >particular practices that you've found easiest to introduce,
      >the ones that get people to say "Hey that really helps, I'm
      >willing to try more"?
      >
      >Thanks a bunch!
      >Jeff
      >
      >
      >
      >
      >
      >To Post a message, send it to: extremeprogramming@...
      >
      >To Unsubscribe, send a blank message to:
      >extremeprogramming-unsubscribe@...
      >
      >ad-free courtesy of objectmentor.com
      >Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
    • jeffadams78
      ... That s the other goal of my cards-on-monday-to-finish-by-friday idea, is to be able to go to the PM every monday (or friday) and say Here s the schedule
      Message 2 of 16 , Jan 2, 2006
        > That could work, given that you have a decent understanding of what
        > the PM wants. For a while, working from any set of cards,
        > estimating, committing, accomplishing, can be a good way to learn.
        > I'd of course suggest keeping the PM up to date on what is going on.

        That's the other goal of my cards-on-monday-to-finish-by-friday idea,
        is to be able to go to the PM every monday (or friday) and say "Here's
        the schedule update."

        > And ... once a list of things is committed to, I find that it's
        > useful to transcribe the cards to one of the team's whiteboards, so
        > that it is visible. Putting the cards on the wall works OK, but you
        > can't read them from across the room. So if you feel like it, maybe
        > give the whiteboard a try. Leave lots of space between items, we're
        > not making a list, we're making a sign.

        That's a good idea. I'm a big fan of whiteboards myself.

        > The most common comment when I do a TDD demo is "Wow, I didn't know
        > you did it like that."

        Well, I am unlikely to be able to get a demo (no TDD work in-house,
        and my leverage for getting training/instruction/etc is very small...
        I might be able to get some training but I doubt it would be right
        away). I've read a handful of books (Extreme Programming Explained,
        and the other one in that series where they run through a real-life
        example... I forget the title) so I have an understanding of
        test-first but have never seen it in practice. Are there any
        fundamental ideas about it that you'd care to reinforce? From what I
        understand, the main idea is "Don't write code unless you have a
        failing unit test." Which translates to, write new tests before new
        features, and always make a unit test that can reproduce any bug that
        you find.

        > I have mixed feelings about the whole pairing thing. It's very
        > valuable, but if people are going to push back against it, I'm
        > concerned that people will wind up pushing back against everything
        > because of that one item.
        >
        > If I were the boss, I'd be making clear to the senior people that
        > their value isn't mostly in the code they write, because even if
        > they are more productive, they're just one person. Their value is in
        > improving the speed and quality of the code that EVERYONE writes,
        > and the way they can do that is to help the others.

        I'll try to put it terms like that. I'm also thinking I won't push it
        much until we get to the point (hopefully this week or next) where
        we're starting significant code development. It's kind of hard to
        tell people how much value there is in them working together to write
        a 5-line unit test.

        > If I value the results of pairing, the people I lead will value them
        > as well.

        Good point. I'll try to be vocal about the results I expect as much
        as or more than the practices themselves (the why not just the what).

        > I don't think I follow the above. That might be what was holding me
        > back from responding.

        Heh. Don't feel bad, it's taken me a while to understand it. Let's
        see if I can simplify it.

        We do defense contracting. The end user of our product
        (theoretically; we haven't deployed any yet) is some fairly
        low-ranking soldier sitting in a tent somewhere. Lots and lots of
        soldiers in tents.

        That's the USER.

        However, the CUSTOMER is actually someone working in an army R&D lab,
        who we have a contract with. For reasons which are kinda convoluted
        the company basically writes whatever they want as the contract and
        the customer signs it. So of course the company makes it as vague as
        possible.

        The customer has a pretty good understanding of the target user (used
        to be one). So, the customer has very specific ideas of what they
        would like to see in the finished product. I intend to try and focus
        on what the customer has expressed to me as their most desired
        features. However the customer is NOT the user, so one of the things
        the customer has to do is "sell" our product to some army division or
        project or whatever in order to actually get it used somewhere. This
        is the source of the random short-notice demos we have to do. Also
        the vagueness of the contract leads to differing opinions between
        upper management on what we ought to do, some people would prefer to
        focus on producing IP for the company which happens to satisfy the
        wording of the contract, as opposed to working to best satisfy the
        customer/user.

        We are not starting from ground level. This contract is basically
        just a continuation of work on a project that we worked on in the last
        contract. There are a number of features of that project that are
        "done" but not really... For example we reused a bunch of code off
        another project; in theory we can do ten things that other project
        could do, but we've didn't test them. So part of the work I'm
        insisting on is verifying (via unit tests that we can continue to run
        forever) that we can actually do everything we claim to be able to do.

        > If every feature's tests were automated, we could test every feature
        > all the time ...

        That's where I'd like to get to. One of the things I just did was add
        a unit-test-run script to the bottom of our build script. So now
        every time we build, it runs all the unit tests. Which is a whopping
        3 at the moment, but you've got to start somewhere :-).

        > > * Upper management, PM, Manager, and Developer all have different
        > > ideas of what is being done and what should be being done.
        >
        > A weekly status report should get people understanding what is
        > being done. One would think that the cards or the story list on the
        > whiteboard would be the essence of that report.
        >
        > But I want to know more about why all these people are on different
        > pages. That seems very bad to me ...

        <Insert a big sigh here> Yeah it seems bad to me too. I'm hoping to
        be able to get PM, Manager, and Developer all on the same page. Then
        I can let the PM worry about upper management. In the past there has
        been somewhat of a lack of communication from PM/Manager down. So you
        had developer told to start task A, working task A, management decides
        task B ought to be done, fails to communicate that for a few days,
        then wonders why the developer's been doing task A when B is more
        important! Above that it's all internal politics.

        > See above. It's easy to be clear about what is being done and what
        > is not. What's getting in the way of this. Relatedly, see
        > http://www.xprogramming.com/xpmag/PetitionTheKing.htm for an idea
        > supporting the notion that projects/stories/features/tasks should
        > have only two statuses: being worked on right now, or not scheduled
        > at all. Note also the related article,

        That's an interesting read, but unfortunately in my case the PM has
        handed down a commandment that All Tasks Shall Be On The Schedule.
        And the schedule is in Microsoft Project. She's ok with changing the
        schedule, but everything has to be on there. Which, as far as I'm
        concerned, makes it a lot like the weather forecast. More or less
        accurate for this week, possibly next, beyond that good luck.

        I don't indend for developers to report on tasks they are not working,
        even if they are shown as assigned in MS Project. Keeping the
        developers focused only on the tasks they are working is the part that
        I can do.

        > http://www.xprogramming.com/xpmag/PrioritiesChanged.htm .

        This is a good idea for us. It isn't usually that tasks get cancelled
        per se, but suddenly there's a higher priority task. And then a
        higher priority one than that. But you're right, if we scale our
        development cycles short enough, it ceases to become an issue. Even
        if our tasks still get interrupted, leaving a 1-week task half done
        means a lot less half-finished code in there than a 1-month (or
        2-month or ...) task.

        Thanks for all your input so far!
      • jeffadams78
        ... you can ... for at ... Not a bad idea. My suspicion is that it is unlikely the PM will approve bringing on a coach. However, you never know until you
        Message 3 of 16 , Jan 2, 2006
          --- In extremeprogramming@yahoogroups.com, "Amir Kolsky" <kolsky@a...>
          wrote:
          >
          > I might be stating the obvious, or the dubious, but the BEST thing
          you can
          > do to get yourself started in XP is to get yourself a good XP coach
          for at
          > least a few months.
          >
          > Amir Kolsky
          > XP& Software
          >

          Not a bad idea. My suspicion is that it is unlikely the PM will
          approve bringing on a coach. However, you never know until you ask.
          I'll try to remember to bring it up tomorrow.

          Jeff
        • Kent Beck
          Jeff, One exercise that comes to mind is to have them read through the list of primary practices, choose one that reminds them of a time they were really
          Message 4 of 16 , Jan 5, 2006
            Jeff,

            One exercise that comes to mind is to have them read through the list of
            primary practices, choose one that reminds them of a time they were really
            satisfied with their work, and apply what they know from those experiences
            to the current environment. If you try this I'd love to hear how it goes
            (that goes for the rest of the list as well).

            Sincerely yours,

            Kent Beck
            Three Rivers Institute

            > -----Original Message-----
            > From: extremeprogramming@yahoogroups.com
            > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of jeffadams78
            > Sent: Thursday, December 29, 2005 2:29 PM
            > To: extremeprogramming@yahoogroups.com
            > Subject: [XP] Starting XP, looking for suggestions.
            >
            > Next, I have a team which is somewhat reluctant to move rapidly to an
            > "unusual" (to them) development style. I want to get them to try it,
            > but I also don't want to be obnoxious about pushing a ton of changes
            > on them. What are the particular practices that you've found easiest
            > to introduce, the ones that get people to say "Hey that really helps,
            > I'm willing to try more"?
          Your message has been successfully submitted and would be delivered to recipients shortly.