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

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

Expand Messages
  • Ron Jeffries
    Hi Jeff ... I ve been holding back from responding in hopes that I d think of something profound to say. Since that appears not to be happening, here s what
    Message 1 of 16 , Jan 2, 2006
    • 0 Attachment
      Hi Jeff ... I've been holding back from responding in hopes that I'd
      think of something profound to say. Since that appears not to be
      happening, here's what I've got. ;->

      On Saturday, December 31, 2005, at 12:03:13 PM, jeffadams78 wrote:

      > Well, at first I wasn't going to do card-based planning because it
      > seems so "antiquated"... just track everything online! But all the
      > resources say over and over again the same thing: there's just no
      > substitute for being able to pick up the cards, flip through 'em,
      > stack 'em, etc. And I can understand that, honestly I think I was
      > more worried about what my boss and PM would think if they saw me
      > playing with index cards. But really, if it gets the job done, who
      > cares if they giggle behind my back at first?

      I carry 3x5 cards in my pocket. I use them to write down the phone
      numbers of any good looking people who offer their number, to sign
      autographs for people requesting them, to draw maps of how to get to
      Lu & Carl's from wherever, and still have plenty left over for less
      important things, like

      * making short notes on things I observe when working with a team;

      * writing class or object names one per card, and moving the cards
      around on the table to describe how something works;

      * writing story names one per card and arranging them to make a
      schedule;

      * writing book chapter ideas one per card to arrange chapters as
      well as have a list of all the ideas;

      * writing detailed paragraph ideas when filling in a chapter

      and many more. I use the cards as a natural part of my work. Each
      card is about the size of any of the N electronic PDAs I have bought
      over the years. And cards have some fantastic advantages, not least
      of which is that you can see more than one page of your card PDA at
      once.

      I have never had anyone show a weird reaction to my cards, although
      they could of course be laughing at me behind my back. If they're
      doing that, my guess is it's for other reasons. ;->

      And, with a little study of the rare but excellent book by Ricky
      Jay, /Cards as Weapons/, you can learn to fling one across the room
      and embed it in the skull of anyone who shows disrespect.

      But seriously, if you use cards naturally, everyone will get it. If
      you leave cards around the workspace, everyone will start writing
      stuff on them. The big decision is which size to use. I like 3x5
      because they fit in my pocket without making me look like I'm happy
      to see you. 4x6 would work a bit better for me for book and article
      writing, because my writing is large enough that I can't get a
      decent paragraph, even short ones like I use, on one 3x5. I see a
      lot of teams using 4x6 after I've been there a few times. I think
      5x8 are usually too large, as they tend to start getting too much
      written on them. The idea that works best, I think, is to have a
      card be a reminder, not a document.

      > So starting Tuesday (Monday's a holiday), I'm going to try to have a
      > stack of cards that my team agrees can be done by Friday. Although I
      > know technically the PM probably ought to be the "customer" deciding
      > which cards should be implemented, I think it would be good if we
      > could get in the groove of making realistic estimates and
      > accomplishing them before we "go live" as it were.

      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.

      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.

      > The other two practices I've been trying to get started are test-first
      > programming and pair programming.

      > Test-first is easy at the moment, because we aren't doing much
      > development. Most of our initial tasks are things like "determine
      > where the performance bottleneck is" and "verify that we can do what
      > we think we can." Those lend themselves well to simply writing some
      > unit tests and seeing what the output is. The real test (pun
      > intended) will come when we start implementing changes. However at
      > least we'll have the framework there by that point and people will be
      > used to using junit.

      Sounds good. I'd suggest working some TDD problems as a group, on
      the screen (don't forget to blow up the font size), and if you can
      get a TDD-experienced person to come in and show how they do it, it
      will be valuable.

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

      > Pair programming is a little more challenging. My four developers are
      > split in half, two junior folks and two senior. The two junior folks
      > ("junior" is relative, they've got a few years experience and are
      > plenty competent) are willing and have been working well together.
      > The two senior folks (10+ years experience) are a little more
      > reluctant. They'll work with someone, but only if I "remind" them.
      > I'm not sure whether assigning pairs would be better in this case, or
      > if I should just let it lie until we actually get into code changes
      > (so far the work that has been going on is debugging (identifying
      > problems, not fixing yet), testing, and implementation of build
      > scripts and other ancillary stuff).

      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.

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

      > A little more background that may be useful, we're just starting a
      > follow-on contract to the contract we just "finished". So we have an
      > existing code base, existing behavior (although what is claimed and
      > what is actual are not necessarily in sync). The contracts are sort
      > of R&D and very vague so although "it would be nice" to make something
      > that guys in the field will use, the contract doesn't really specify
      > that we have to. The customer (and I) would like a useful system with
      > features beneficial to end users.

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

      > Problems we have had in the past (that I would like to avoid/correct
      > using XP) include...

      > * Adding a feature, making sure it works, then not trying it again
      > until demo time (months later) and hey, now it doesn't work any more!

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

      > * 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 ...

      > * Frequent direction changes resulting in many tasks being started and
      > not finished, and sometimes getting in trouble with management later.
      > ("That was on the schedule months ago! Why isn't it done?")

      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,
      http://www.xprogramming.com/xpmag/PrioritiesChanged.htm .

      > * Pigeonholing of developers (He's the database guy, she's the
      > installer guru, he's the client developer) resulting in problems when
      > one person is out (vacation, sick, whatever) and no one else knows
      > that portion of the system.

      Pairing can help with that, as can clarity about the boss's
      priorities regarding information and skill transfer. Doing stories
      in narrow "vertical slices" instead of parallel technical tasks,
      will do so as well.

      Regards,

      Ron Jeffries
      www.XProgramming.com
      A lot of preconceptions can be dismissed when you actually
      try something out. -- Bruce Eckel
    • 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 2 of 16 , Jan 2, 2006
      • 0 Attachment
        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 3 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 4 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 5 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.