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

Re: [XP] Introducing XP at My Workplace: A Turn for the Worse

Expand Messages
  • Ron Jeffries
    ... My old mentor, Bill Rogers, used to say You have to either laugh or cry. I m glad you can still find things to laugh at. Keep on keeping on ... Ron
    Message 1 of 19 , Dec 29, 2005
    • 0 Attachment
      On Thursday, December 29, 2005, at 1:46:27 PM, Robert Williams wrote:

      > On a somewhat related, and lighter-hearted note: From what I gather,
      > a common response to agile development is "I see how that would work
      > on /other/ projects, but it could never work on /this/ one." A few
      > days ago, the other developer on this project told me "I see how
      > iterative development can work on /this/ project, but it will never
      > work on /other/ ones." I found that funny.

      My old mentor, Bill Rogers, used to say "You have to either laugh or
      cry." I'm glad you can still find things to laugh at.

      Keep on keeping on ...

      Ron Jeffries
      www.XProgramming.com
      If we're not shipping our software when it's ready,
      it's poor business practice.
      If we're not sure whether our software is ready,
      it's poor software practice.
      http://www.xprogramming.com/blog/Page.aspx?display=FrequentReleases
    • Chris Wheeler
      ... This is great news! And I think that you found the heart of the solution - when you planned the project it seemed as though you had about two months .
      Message 2 of 19 , Dec 30, 2005
      • 0 Attachment
        >
        >
        > We figured something out this morning that might work. We are faking
        > and dropping a whole bunch of stuff, but we think we can get the
        > single most important piece of data without having to rework
        > everything. And the design isn't too dirty.
        >

        This is great news! And I think that you found the heart of the solution -
        when you planned the project it seemed as though you had 'about two
        months'. But, the business need changed - screaming, angry customer - and
        thus so did the project. I've come to the conversation late, so this may be
        slightly out of context, but since everything else was changing - boss
        cancelled vacations, deadline moved way up, angry customer, then perhaps
        that's an indication to throw out anything that you have in terms of a
        project and start over - take a day or two, start fresh, and solve the
        problem at hand as opposed to the problem that had been scheduled. I hope
        that isn't phrased in a way that implies that you did the wrong thing. It's
        just that everytime I've been in a position like that, I've always found it
        best to crumple everything up, throw it out, and take a fresh look at the
        new problem.

        Chris.
        --
        Chris Wheeler
        www.agilelectric.com
        coach, programmer & practitioner


        [Non-text portions of this message have been removed]
      • Dakshinamurthy Karra
        I second this suggestion. It always worked for me. When a crisis arrives (it invariably does) during development rework the plan as a new project. In one
        Message 3 of 19 , Dec 30, 2005
        • 0 Attachment
          I second this suggestion. It always worked for me. When a crisis
          arrives (it invariably does) during development rework the plan as a
          new project. In one specific case, we got priorities that were vastly
          different from the original plan and we could tide over the crisis
          because of the change in the focus.

          HTH

          Thanks and Regards
          KD

          On 12/31/05, Chris Wheeler <christopher.wheeler@...> wrote:

          > This is great news! And I think that you found the heart of the solution -
          > when you planned the project it seemed as though you had 'about two
          > months'. But, the business need changed - screaming, angry customer - and
          > thus so did the project. I've come to the conversation late, so this may be
          > slightly out of context, but since everything else was changing - boss
          > cancelled vacations, deadline moved way up, angry customer, then perhaps
          > that's an indication to throw out anything that you have in terms of a
          > project and start over - take a day or two, start fresh, and solve the
          > problem at hand as opposed to the problem that had been scheduled. I hope
          > that isn't phrased in a way that implies that you did the wrong thing. It's
          > just that everytime I've been in a position like that, I've always found it
          > best to crumple everything up, throw it out, and take a fresh look at the
          > new problem.
          >
          > Chris.
          > --
          > Chris Wheeler
          > www.agilelectric.com
          > coach, programmer & practitioner
          >
          >
          > [Non-text portions of this message have been removed]
          >
          >
          >
          > 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
          >
          >
          >
          >
          >
          >
          >


          --
          Dakshinamurthy Karra
        • Robert Williams
          ... Well, I didn t wind up having to throw /everything/ out. But we did wind up ripping out most of it. And the parts we kept, we refactored to the point
          Message 4 of 19 , Jan 1, 2006
          • 0 Attachment
            >>that's an indication to throw out anything that you have in terms of a
            >>project and start over - take a day or two, start fresh, and solve the
            >>problem at hand as opposed to the problem that had been scheduled. I hope
            >>
            >>
            Well, I didn't wind up having to throw /everything/ out. But we did
            wind up ripping out most of it. And the parts we kept, we refactored to
            the point that it will be easy if and when we need to add those pieces
            back in.

            Thanks again for all the advice.

            Robert
          • William Pietri
            Hi, Robert! Returning from the holidays, I m sorry to hear of your troubles, but it sounds like you re dealing quite well. One comment. ... It may help you to
            Message 5 of 19 , Jan 3, 2006
            • 0 Attachment
              Hi, Robert! Returning from the holidays, I'm sorry to hear of your
              troubles, but it sounds like you're dealing quite well. One comment.

              Robert Williams wrote:

              >1. Unreasonable schedules and schedule changes, which I should deal
              >with by trying to cut features/scope and defend through a good set of
              >estimates.
              >
              >

              It may help you to get through this to realize that unreasonable
              behaviors are often reasonable responses to unreasonable situations. Put
              another way, managers who schedule unreasonably aren't all naturally
              crazy. They've learned those behaviors in response to the flawed
              traditional model of software project management.

              One of my favorite things about adopting agile methods is that short,
              frequent iterations give all parties plenty of opportunity to learn how
              to act more sanely, and set things up so they are rewarded for doing so.
              You may not see much improvement right away, but sanity is contagious.

              William
            Your message has been successfully submitted and would be delivered to recipients shortly.