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

Re: Starting XP, looking for suggestions.

Expand Messages
  • 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 1 of 16 , Jan 2, 2006
    • 0 Attachment
      > 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 2 of 16 , Jan 2, 2006
      • 0 Attachment
        --- 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 3 of 16 , Jan 5, 2006
        • 0 Attachment
          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.