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

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

Expand Messages
  • Victor
    ... and providing it to the middle-stage, ... Could it be that a redefinition of Customer is in order? Maybe your customer is the middle-stage, and they could
    Message 1 of 16 , Dec 29, 2005
    • 0 Attachment
      > My team is working on the back-end part of the system, ingesting data
      and providing it to the middle-stage, ...

      Could it be that a redefinition of Customer is in order? Maybe your
      customer is the middle-stage, and they could be a good source of user
      stories?

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

      There are some similarities between waterfall and XP. One of those is that
      in both cases you need to know what is that you are doing, to some extent.
      In your case there maybe an advantage that you are required to prepare the
      documentation. That will give you time to better understand the problem
      domain. As you advance in your understanding, it will be easier to think
      about potential user stories. Part of your documentation will be these user
      stories. As you progress with your user stories, you could create tests in
      the spirit of TDD. These working tests will also be part of your
      documentation, and the advantage of this documentation will be that the
      tests will be alive and working, contrary to the stale documentation you are
      being requested to produce. That will be the proof (hopefully) that your
      approach is better. And you know what? You don't even need to mention XP or
      Agile. You'll just be producing documentation and working code.

      As a bonus you could also be producing some high level UML or other flow and
      state diagrams. If you so do, remember to document the history of their
      changes, so you can demonstrate how futile it is (or not) to try to capture
      all the design from the beginning.

      After a while and some successes, you'll find a common language.

      Victor

      =============================================
      ----- Original Message -----
      From: "jeffadams78" <jeffadams78@...>
      To: <extremeprogramming@yahoogroups.com>
      Sent: Thursday, December 29, 2005 5:29 PM
      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
      >
      >
      >
      >
      >
      >
    • William Pietri
      ... I d second this. When writing an API, your user is a programmer, so the stories will sound programmer-like. The important distinction is that they should
      Message 2 of 16 , Dec 30, 2005
      • 0 Attachment
        Victor wrote:

        >> My team is working on the back-end part of the system, ingesting data
        >>
        >>
        >and providing it to the middle-stage, ...
        >
        >Could it be that a redefinition of Customer is in order? Maybe your
        >customer is the middle-stage, and they could be a good source of user
        >stories?
        >
        >

        I'd second this. When writing an API, your user is a programmer, so the
        stories will sound programmer-like. The important distinction is that
        they should be about things the consumers of your efforts need, not what
        your team needs.

        For example, if you were building the Flickr API, you'd have stories like
        * client adds photo
        * client gets photos
        * client tags photo
        * client gets photo info

        But you still wouldn't have stories like
        * install database
        * refactor the frobnitz layer


        Note that since you're embedded in a larger waterfall cycle, it may be
        hard to get the upstream team to give you stories like this, especially
        officially. But most good programmers like to manually test things as
        they go, so you can probably work with the individual developers to find
        out what they'd like to see and try next.

        William



        [Non-text portions of this message have been removed]
      • jeffadams78
        ... I think I conveyed the wrong impression about my team. Open-minded but dubious would be a better description. They re willing to try new stuff, but
        Message 3 of 16 , Dec 30, 2005
        • 0 Attachment
          --- In extremeprogramming@yahoogroups.com, Ron Jeffries
          <ronjeffries@X...> wrote:
          > Hi Jeff,
          >
          > Tell us more about why, in the face of all this opposition, you want
          > to try it. What problems do you see that XP might help with? What
          > benefits do you need that XP might provide.
          >
          > Thanks,
          >
          > Ron Jeffries
          > www.XProgramming.com
          > Any errors you find in this are the work of Secret Villains,
          > whose mad schemes will soon be revealed. -- Wil McCarthy
          >

          I think I conveyed the wrong impression about my team. "Open-minded
          but dubious" would be a better description. They're willing to try
          new stuff, but mostly in the vein of humoring me. I'd like to show
          them how useful some of these practices can be and get them really
          interested in XP.

          The main benefit I see is the flexibility in the face of change. No
          one (management-wise) likes to admit it, but our project changes
          scope/requirements/direction a LOT. In the same meeting where the
          program manager made me provide tasks, estimates, and assign
          developers to tasks for the next three months, she mentioned how the
          first or second week of January we hope to be meeting with a potential
          customer who, if they decide to adopt our system, will dramatically
          change the requirements. It is very common for a new demo opportunity
          to appear on short notice (2-3 weeks) where they suddenly want to demo
          a different feature or scenario than what we've been focusing on so far.

          I'd like to get to the point where we have short (ideally 1 week)
          iterations, so that when changes like that come up we can easily
          change direction at the end of an iteration without leaving a bunch of
          stuff half-done (which has happened frequently in the past).
        • jeffadams78
          ... what ... like ... OK That makes a lot of sense. How do you handle user stories that are longer than an iteration? Hmm now that I ask, I m having a hard
          Message 4 of 16 , Dec 30, 2005
          • 0 Attachment
            --- In extremeprogramming@yahoogroups.com, William Pietri
            <william@s...> wrote:

            > I'd second this. When writing an API, your user is a programmer, so the
            > stories will sound programmer-like. The important distinction is that
            > they should be about things the consumers of your efforts need, not
            what
            > your team needs.
            >
            > For example, if you were building the Flickr API, you'd have stories
            like
            > * client adds photo
            > * client gets photos
            > * client tags photo
            > * client gets photo info
            >
            > But you still wouldn't have stories like
            > * install database
            > * refactor the frobnitz layer

            OK That makes a lot of sense. How do you handle user stories that are
            longer than an iteration? Hmm now that I ask, I'm having a hard time
            coming up with an example. But let's say from the user's point of
            view, there is a single story (which is too large for one iteration),
            but from the developer point of view it breaks into a series of
            reasonable steps? Do you break stories into "User Story X Part 1" and
            "User Story X Part 2"?
          • banshee858
            ... Here are two possible solutions I can think of: 1) Work on splitting the story. IMO, if the story is too big for an iteration, then the customer still
            Message 5 of 16 , Dec 30, 2005
            • 0 Attachment
              >
              > How do you handle user stories that are longer than an iteration? Hmm
              > now that I ask, I'm having a hard time coming up with an example. But
              > let's say from the user's point of view, there is a single story
              > (which is too large for one iteration), but from the developer point
              > of view it breaks into a series of reasonable steps? Do you break
              > stories into "User Story X Part 1" and "User Story X Part 2"?
              >
              Here are two possible solutions I can think of:

              1) Work on splitting the story. IMO, if the story is too big for an
              iteration, then the customer still does not have a good idea on what
              they want built. Try defining the acceptance test to help flush out
              the details of the story so it may be split. I have only met very few
              user stories that cannot be split into smaller parts each providing
              value. Remember, a completed story must provide the customer value,
              it does not have to be released when completed it just has to be
              complete, i.e. coded, tested, reviewed and with the necessary
              documentation.

              I would NOT break apart the story from the developer's POV. User
              stories are defined and prioritized by the customer, almost never by
              the developer. Be very wary of crossing that line.

              2) You could extend your iteration length. If stories do not fit into
              a one week window, try using two week iterations. I would not suggest
              three week iterations since that seems a long time to me, but Scrum
              uses 30 days, so three weeks is possible, if a little long for XP.

              Carlton
            • Ron Jeffries
              ... OK ... ... Short iterations would certainly help with that, as would card-based planning where the program manager etc come to understand that you can only
              Message 6 of 16 , Dec 30, 2005
              • 0 Attachment
                On Friday, December 30, 2005, at 10:19:18 AM, jeffadams78 wrote:

                > I think I conveyed the wrong impression about my team. "Open-minded
                > but dubious" would be a better description. They're willing to try
                > new stuff, but mostly in the vein of humoring me. I'd like to show
                > them how useful some of these practices can be and get them really
                > interested in XP.

                OK ...

                > The main benefit I see is the flexibility in the face of change. No
                > one (management-wise) likes to admit it, but our project changes
                > scope/requirements/direction a LOT. In the same meeting where the
                > program manager made me provide tasks, estimates, and assign
                > developers to tasks for the next three months, she mentioned how the
                > first or second week of January we hope to be meeting with a potential
                > customer who, if they decide to adopt our system, will dramatically
                > change the requirements. It is very common for a new demo opportunity
                > to appear on short notice (2-3 weeks) where they suddenly want to demo
                > a different feature or scenario than what we've been focusing on so far.

                > I'd like to get to the point where we have short (ideally 1 week)
                > iterations, so that when changes like that come up we can easily
                > change direction at the end of an iteration without leaving a bunch of
                > stuff half-done (which has happened frequently in the past).

                Short iterations would certainly help with that, as would card-based
                planning where the program manager etc come to understand that you
                can only do N things per week, so they need to decide which N.

                Tell us more ...

                Ron Jeffries
                www.XProgramming.com
                In programming, do, or undo. There is always try. --Yoda
              • William Pietri
                ... In the years I ve been doing this, I ve never come up with an example that stood the test of time. I think the worst case is that you ll come up with a
                Message 7 of 16 , Dec 30, 2005
                • 0 Attachment
                  jeffadams78 wrote:

                  >OK That makes a lot of sense. How do you handle user stories that are
                  >longer than an iteration? Hmm now that I ask, I'm having a hard time
                  >coming up with an example.
                  >

                  In the years I've been doing this, I've never come up with an example
                  that stood the test of time.

                  I think the worst case is that you'll come up with a story that you
                  currently don't know how to break apart. If that happened to me, I'd
                  bring it here and see what others suggested. Failing that, I'd probably
                  split it into two parts, but I wouldn't be happy about it. And even
                  then, I'd be energetically looking for things I could split out or leave
                  until later.

                  The biggest initial hurdle I see for teams is taking a small step
                  forward and being happy that it's a step forward rather than feeling
                  negative that it's small. For most of my stories these days, I tend to
                  break them down into mini-stories so that I can show things to the XP
                  Customer every 1-3 hours. The longer you go without external validation,
                  the more you gamble. The smaller your units of work, the more options
                  you have when trying to trim the schedule.

                  William
                • jeffadams78
                  ... 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
                  Message 8 of 16 , Dec 31, 2005
                  • 0 Attachment
                    --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                    <ronjeffries@X...> wrote:
                    > Short iterations would certainly help with that, as would card-based
                    > planning where the program manager etc come to understand that you
                    > can only do N things per week, so they need to decide which N.
                    >
                    > Tell us more ...
                    >
                    > Ron Jeffries
                    > www.XProgramming.com
                    > In programming, do, or undo. There is always try. --Yoda
                    >

                    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?

                    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.

                    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.

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

                    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.

                    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!
                    * Upper management, PM, Manager, and Developer all have different
                    ideas of what is being done and what should be being done.
                    * 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?")
                    * 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.
                  • news.gmane.org
                    ... We didn t use cards in the begining. I insisted that they re-prioratized at the start of every iteration, but the stories were written in a document and
                    Message 9 of 16 , Dec 31, 2005
                    • 0 Attachment
                      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?

                      We didn't use cards in the begining. I insisted that they re-prioratized
                      at the start of every iteration, but the stories were written in a
                      document and put on a white board during planning, because thats what
                      every one was comfortable with.

                      Ater half a year the customers said "for gods sake, can't we just write
                      them on cards or something so we don't have to re-write them every
                      time". I "reluctanlty" agreed (whilst smiling on the inside ;-)).

                      The point is that at every iteration planning meeting you are
                      effectively deciding how to spend tens of thousands of pounds/dollars.
                      So your customers must re-evaluate their priorites. Since the customers
                      own the story, sometimes its better to get them to suggest what the best
                      medium is. Give them the right stimulus, and they are bound to suggest
                      something like cards.

                      I should add that previous to this we tried to impose cards, and the
                      customers didn't like it. They liked it a lot more when it was their
                      idea ;-)

                      Cheers

                      Daniel
                    • 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 10 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 11 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 12 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 13 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 14 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.