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

Re: [XP] Slack for Crises

Expand Messages
  • glbrown@inebraska.com
    ... Here, at a well-known company that produces vehicle history reports, we always have 2 - 4 pairs assigned to work on Production Support issues. We still
    Message 1 of 19 , Jul 5, 2006
      Quoting Greg Akins <angrygreg@...>:

      > This has been discussed previously, but I'd like to bring up some discussion
      > again to get help with my current situation.
      >
      > As we move to Agile/XP, how do we deal with "urgent" requests.
      >
      > If a feature can't wait to be placed in a release, what's the best way to
      > satisfy the customer who asks that a feature, or bug, be resolved NOW.
      >
      > My two thoughts are:
      >
      > 1. Stop a pair's work on a feature and move them to the PRIORITY request.
      > 2. Leave an individual in a non-assigned mode, so they can respond to those
      > requests immediately, without concern for the iteration
      >
      > Are these approaches any good. Does anyone have better suggestions?

      Here, at a well-known company that produces vehicle history reports, we always
      have 2 - 4 pairs assigned to work on Production Support issues. We still have
      a lot of defect-laden legacy code, and we continue to deliver new defects to
      production, more often than we would like.

      Last year, we spent about 25% of our development resources on fixing defects and
      accomodating urgent requests. We are working to improve our discipline in
      Test-Driven Development, especially testing everything that could possibly
      break, Simple Design, Refactoring, and getting our Customers engaged with our
      Acceptance Testing efforts.

      We are also working with our Customers, to improve their ability to identify and
      prioritize the most important work, so that we can move the urgent rquests to
      the main-stream development process. Historically, our Customers have asked
      that urgent requests be done in addition to the planned work. Most of the
      stakeholders have come to realize that this expectation has caused the
      developers to miss their commitments on planned work.

      For now, we plan to continue to allocate resources to production support, as a
      buffer or slack, so that we can meet expectations for planned work. Our goal
      is to eliminate the need for it, by reducing defects and better planning, but
      it's what we need to do for now.

      GB.
    • Sammy Larbi
      Out of curiosity for how others are doing it, after you ve released an application that is hosted on your servers, do you follow a release schedule or do you
      Message 2 of 19 , Jul 5, 2006
        Out of curiosity for how others are doing it, after you've released an
        application that is hosted on your servers, do you follow a "release
        schedule" or do you just apply updates as they are made?

        While developing the application, we normally do weekly demonstrations
        until the application is "releasable." After that we apply updates as
        they are made.

        How do you all do it?

        -Sammy Larbi
      • Ron Jeffries
        ... Well, how long are your iterations? If they are more than a week, maybe they should be shorter. If these requests are defects, maybe we need to be more
        Message 3 of 19 , Jul 5, 2006
          On Wednesday, July 5, 2006, at 9:37:59 AM, Greg Akins wrote:

          > This has been discussed previously, but I'd like to bring up some discussion
          > again to get help with my current situation.

          > As we move to Agile/XP, how do we deal with "urgent" requests.

          > If a feature can't wait to be placed in a release, what's the best way to
          > satisfy the customer who asks that a feature, or bug, be resolved NOW.

          > My two thoughts are:

          > 1. Stop a pair's work on a feature and move them to the PRIORITY request.
          > 2. Leave an individual in a non-assigned mode, so they can respond to those
          > requests immediately, without concern for the iteration

          > Are these approaches any good. Does anyone have better suggestions?

          Well, how long are your iterations? If they are more than a week,
          maybe they should be shorter.

          If these requests are defects, maybe we need to be more careful what
          we release, since time spent fixing almost certainly exceeds the
          time that would have been spent making it work right in the first
          place.

          If the customer is changing her mind, maybe she needs to be a bit
          more certain before bringing things in. Perhaps showing her the cost
          of changing things would be valuable in providing motivation. (This
          is worth tracking in any case, I'd think.)

          It might be valuable to get a better deadline than "right now" for
          many of these requests. Perhaps "by the end of the week", or "in the
          next two weeks" would actually do for a number of them.

          Rather than having people standing by, I'd suggest signing up for
          fewer stories overall, so that when something comes in, there
          doesn't need to be so much diversion.

          And again, by all means, track the time spent doing this kind of
          work, and its impact on the "real" priorities of the project.

          Ron Jeffries
          www.XProgramming.com
          2 + 2 = 5, for sufficiently large values of 2.
        • Adrian Howard
          On 5 Jul 2006, at 14:37, Greg Akins wrote: [snip] ... You sit down with the Customer and say something like: We understand that you need UrgentFeature to be
          Message 4 of 19 , Jul 5, 2006
            On 5 Jul 2006, at 14:37, Greg Akins wrote:
            [snip]
            > As we move to Agile/XP, how do we deal with "urgent" requests.
            >
            > If a feature can't wait to be placed in a release, what's the best
            > way to
            > satisfy the customer who asks that a feature, or bug, be resolved NOW.
            >
            > My two thoughts are:
            >
            > 1. Stop a pair's work on a feature and move them to the PRIORITY
            > request.
            > 2. Leave an individual in a non-assigned mode, so they can respond
            > to those
            > requests immediately, without concern for the iteration
            >
            > Are these approaches any good. Does anyone have better suggestions?

            You sit down with the Customer and say something like:

            "We understand that you need UrgentFeature to be implemented ASAP.
            Let's look at how long it will take."

            <insert planning game here>

            "Cool - this looks like that breaks down into X stories that will
            take Y points to implement - so we'll need to drop Y points from the
            current iteration."

            <insert discussion about what is going to get dropped from the
            iteration>

            Add new story cards to board. Remove cards that are going to be
            dropped. Continue as normal.

            If I was in a situation where enough emergencies were occurring that
            I wanted to keep somebody in a non-assigned role I would think there
            was something wrong with my Customer/Developer interactions - and I
            would be trying to improve that rather than deal with the symptoms.

            Hopefully making some vague sort of sense...

            Adrian
          • Greg Akins
            OK.. Let s see if I can summarize. It seems that the general impression is that if there are that many emergencies, then there is something wrong. Either too
            Message 5 of 19 , Jul 5, 2006
              OK.. Let's see if I can summarize.

              It seems that the general impression is that if there are that many
              emergencies, then there is something wrong. Either too many defects are
              slipping out, or planning isn't occurring appropriately.

              I think both of those things are true. Part of what needs to be
              accomplished is a way to mitigate those problems, while we move to better
              quality and better planning.



              --
              ==============
              Greg Akins
              http://www.pghcodingdojo.org


              [Non-text portions of this message have been removed]
            • Brandon Campbell
              Greg, We had similar issues at my current job. We had UrgentItems(either bugs or features) that needed to get into the current iteration(we use 3 week
              Message 6 of 19 , Jul 6, 2006
                Greg,

                We had similar issues at my current job. We had UrgentItems(either bugs or
                features) that needed to get into the current iteration(we use 3 week
                iterations). What we ended up doing was track in a spreadsheet the Item and
                the reason for the emergency. After a few months we had enough data to
                start make some changes to our process. Each emergency on its own couldn't
                give us the information we needed to change the process, but together they
                were enlightening.

                On 7/5/06, Greg Akins <angrygreg@...> wrote:
                >
                > OK.. Let's see if I can summarize.
                >
                > It seems that the general impression is that if there are that many
                > emergencies, then there is something wrong. Either too many defects are
                > slipping out, or planning isn't occurring appropriately.
                >
                > I think both of those things are true. Part of what needs to be
                > accomplished is a way to mitigate those problems, while we move to better
                > quality and better planning.
                >
                >
                >
                > --
                > ==============
                > Greg Akins
                > http://www.pghcodingdojo.org
                >
                >
                > [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
                >
                >
                >
                >
                >
                >
                >


                --
                Brandon Campbell
                http://www.acommonprogrammer.com/
                http://www.squidoo.com/xp/


                [Non-text portions of this message have been removed]
              • Bill Caputo
                ... We recently did this as well. One interesting thing to note is that it only took a couple of iterations to get some useful patterns in the data (as Brandon
                Message 7 of 19 , Jul 6, 2006
                  On 7/6/06, Brandon Campbell <brandonjc@...> wrote:
                  > We had similar issues at my current job. We had UrgentItems(either bugs or
                  > features) that needed to get into the current iteration(we use 3 week
                  > iterations). What we ended up doing was track in a spreadsheet the Item and
                  > the reason for the emergency. After a few months we had enough data to
                  > start make some changes to our process.

                  We recently did this as well. One interesting thing to note is that it
                  only took a couple of iterations to get some useful patterns in the
                  data (as Brandon indicates in his email), but because we were using 1
                  - week iterations we were able to make changes in a couple of weeks.

                  Not to say that 3 week iterations are wrong (I've used them on several
                  occasions, and such choice depends on many more factors than just
                  this), or that the data couldn't be analyzed mid-iteration (although
                  its usually harder to see patterns, and there usually is not a time to
                  focus on such things), but rather to underscore Brandon's point that
                  it often only takes a few feedback cycles to harvest meaningful data
                  for process change.

                  Best,
                  Bill
                • geoffrey_slinker
                  ... discussion ... way to ... NOW. ... request. ... to those ... #2 seems risky in that if I were that individual I would become bored and feel that my skills
                  Message 8 of 19 , Jul 6, 2006
                    --- In extremeprogramming@yahoogroups.com, "Greg Akins"
                    <angrygreg@...> wrote:
                    >
                    > This has been discussed previously, but I'd like to bring up some
                    discussion
                    > again to get help with my current situation.
                    >
                    > As we move to Agile/XP, how do we deal with "urgent" requests.
                    >
                    > If a feature can't wait to be placed in a release, what's the best
                    way to
                    > satisfy the customer who asks that a feature, or bug, be resolved
                    NOW.
                    >
                    > My two thoughts are:
                    >
                    > 1. Stop a pair's work on a feature and move them to the PRIORITY
                    request.
                    > 2. Leave an individual in a non-assigned mode, so they can respond
                    to those
                    > requests immediately, without concern for the iteration
                    >
                    > Are these approaches any good. Does anyone have better suggestions?
                    >
                    >

                    #2 seems risky in that if I were that individual I would become bored
                    and feel that my skills were falling behind and would start to look
                    for another job. If there were lots of tasks then I would feel like I
                    had to clean up everyone's mess and would start looking for another
                    job. I guess I am hard to please.

                    #1 seems better, but the verbage maybe overly harsh. I would state it
                    like this:
                    Pause a pair's work on a feature...

                    If you have programmer's tests in place, pausing on task to work on
                    another isn't difficult at all. It is easy to pick up where you left
                    off. If you have your tasks broken down very small, prioritized, and
                    on a progress chart of somekind then you know what to do next. Witht
                    he tests in place you can run those a couple of times, maybe step
                    through some code to get the domain concepts forward in your mind.
                    The interruption may not be any worse than the interruption that
                    occurs every week called the week end! :-)

                    There are situations where you pause everything and do planning for
                    an emergency release. But don't think emergency means haste.

                    For example, suppose you find out that the tax laws for a supported
                    country has changed and you have to comply within one week or face
                    possible litigation. You start up a planning session. You come up
                    with things like:
                    a) If we aren't done with changes by day 6 we take down the site.
                    b) We take team X and team Y and give them the task and let them
                    break it down...

                    So, in summary, restarting a paused task isn't very difficult if you
                    have good task breakdown and prioritization and programmer's tests.

                    Geoff
                  • Brandon Campbell
                    ... Just a note on the 3 week iterations. We are a small development shop and we find that one week iterations don t always provide us with enough stories
                    Message 9 of 19 , Jul 6, 2006
                      On 7/6/06, Bill Caputo <list-subscriber@...> wrote:
                      >
                      > On 7/6/06, Brandon Campbell <brandonjc@...> wrote:
                      > > We had similar issues at my current job. We had UrgentItems(either
                      > bugs or
                      > > features) that needed to get into the current iteration(we use 3 week
                      > > iterations). What we ended up doing was track in a spreadsheet the
                      > Item and
                      > > the reason for the emergency. After a few months we had enough data to
                      > > start make some changes to our process.
                      >
                      > We recently did this as well. One interesting thing to note is that it
                      > only took a couple of iterations to get some useful patterns in the
                      > data (as Brandon indicates in his email), but because we were using 1
                      > - week iterations we were able to make changes in a couple of weeks.
                      >
                      > Not to say that 3 week iterations are wrong (I've used them on several
                      > occasions, and such choice depends on many more factors than just
                      > this),


                      Just a note on the 3 week iterations. We are a small development shop and
                      we find that one week iterations don't always provide us with enough stories
                      completed to provide a valuable release to the customers while a 3 week
                      iteration. Does provide enough stories that the release is meaningful to
                      the customers.

                      If we were a larger team, I am sure that we would shorten our iterations,
                      and release more often.



                      or that the data couldn't be analyzed mid-iteration (although
                      > its usually harder to see patterns, and there usually is not a time to
                      > focus on such things), but rather to underscore Brandon's point that
                      > it often only takes a few feedback cycles to harvest meaningful data
                      > for process change.
                      >
                      > Best,
                      > Bill
                      >
                      >
                      >


                      --
                      Brandon Campbell
                      http://www.acommonprogrammer.com/
                      http://www.squidoo.com/xp/


                      [Non-text portions of this message have been removed]
                    • Adrian Howard
                      On 5 Jul 2006, at 19:55, Greg Akins wrote: [snip] ... [snip] Does everybody involved realise that there is a problem - Customer and Developers? If not maybe
                      Message 10 of 19 , Jul 6, 2006
                        On 5 Jul 2006, at 19:55, Greg Akins wrote:
                        [snip]
                        > I think both of those things are true. Part of what needs to be
                        > accomplished is a way to mitigate those problems, while we move to
                        > better
                        > quality and better planning.
                        [snip]

                        Does everybody involved realise that there is a problem - Customer
                        and Developers?

                        If not maybe the first stage should be collecting some stats on how
                        often emergencies crop up, how long they take to fix, etc.

                        As for mitigation in the short term - maybe deliberately include N
                        points of "droppable" stories in each iteration?

                        Adrian
                      • Greg Akins
                        ... I think that most of development realizes there is a problem. Some of the customers (program managers, sales & marketing, client services; in our case)
                        Message 11 of 19 , Jul 6, 2006
                          On 7/6/06, Adrian Howard <adrianh@...> wrote:
                          >
                          >
                          > On 5 Jul 2006, at 19:55, Greg Akins wrote:
                          > [snip]
                          >
                          > > I think both of those things are true. Part of what needs to be
                          > > accomplished is a way to mitigate those problems, while we move to
                          > > better
                          > > quality and better planning.
                          > [snip]
                          >
                          > Does everybody involved realise that there is a problem - Customer
                          > and Developers?
                          >
                          > If not maybe the first stage should be collecting some stats on how
                          > often emergencies crop up, how long they take to fix, etc.
                          >
                          > As for mitigation in the short term - maybe deliberately include N
                          > points of "droppable" stories in each iteration?
                          >
                          >

                          I think that most of development realizes there is a problem. Some of the
                          customers (program managers, sales & marketing, client services; in our
                          case) don't realize there's a problem. Instead, they think it's business as
                          usual.

                          What I'd like to start doing is put some planned stories on a board, and put
                          "emergency" stories in red to highlight the fact that little of our work is
                          planned, and to make it obvious when we're working on one persons emergency
                          at the expense of someone elses plan.


                          --
                          ==============
                          Greg Akins
                          http://www.pghcodingdojo.org


                          [Non-text portions of this message have been removed]
                        • geoffrey_slinker
                          ... and put ... work is ... emergency ... We do something similar and discovered that over half the team was spending over half their time on emergencies.
                          Message 12 of 19 , Jul 6, 2006
                            --- In extremeprogramming@yahoogroups.com, "Greg Akins" >
                            > What I'd like to start doing is put some planned stories on a board,
                            and put
                            > "emergency" stories in red to highlight the fact that little of our
                            work is
                            > planned, and to make it obvious when we're working on one persons
                            emergency
                            > at the expense of someone elses plan.

                            We do something similar and discovered that over half the team was
                            spending over half their time on emergencies. Planning and
                            priortization has helped reduce that number dramatically.

                            Geoff
                          • Jim Standley
                            We release software to internal users only. Releases are high effort, high ceremony involving infrastructure and our team folks for the mechanical steps,
                            Message 13 of 19 , Jul 8, 2006
                              We release software to internal users only. Releases are high effort,
                              high ceremony involving infrastructure and our team folks for the
                              mechanical steps, business folks for smoke test and sign off, heightened
                              monitoring and prod support for a while after. There are corporate lock
                              down periods for various reasons, and some releases are scheduled with
                              training in the user sites, which has to be meshed with seasonal
                              business peaks. Quarterly releases are the goal. Hardly agile or ideal
                              even in a non-agile world, but there it is.

                              Sammy Larbi wrote:
                              > Out of curiosity for how others are doing it, after you've released an
                              > application that is hosted on your servers, do you follow a "release
                              > schedule" or do you just apply updates as they are made?
                              >
                              > While developing the application, we normally do weekly demonstrations
                              > until the application is "releasable." After that we apply updates as
                              > they are made.
                              >
                              > How do you all do it?
                              >
                              > -Sammy Larbi
                              >
                              >
                              > 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
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                            • David H.
                              ... Change only happen when you do not accept the status quo. I would suggest that you start the Kaizen. -d -- Sent from gmail so do not trust this
                              Message 14 of 19 , Jul 8, 2006
                                On 08/07/06, Jim Standley <jimstandley@...> wrote:
                                > We release software to internal users only. Releases are high effort,
                                > high ceremony involving infrastructure and our team folks for the
                                > mechanical steps, business folks for smoke test and sign off, heightened
                                > monitoring and prod support for a while after. There are corporate lock
                                > down periods for various reasons, and some releases are scheduled with
                                > training in the user sites, which has to be meshed with seasonal
                                > business peaks. Quarterly releases are the goal. Hardly agile or ideal
                                > even in a non-agile world, but there it is.
                                >
                                Change only happen when you do not accept the status quo.
                                I would suggest that you start the Kaizen.

                                -d

                                --
                                Sent from gmail so do not trust this communication.
                                Do not send me sensitive information here, ask for my none-gmail accounts.

                                "Therefore the considerations of the intelligent always include both
                                benefit and harm." - Sun Tzu
                              • Jim Standley
                                Did I say I wanted to change it? Just answering a survey question about what is. :-)
                                Message 15 of 19 , Jul 8, 2006
                                  Did I say I wanted to change it? Just answering a survey question about
                                  what is. :-)

                                  David H. wrote:
                                  >
                                  >
                                  > On 08/07/06, Jim Standley <jimstandley@...
                                  > <mailto:jimstandley%40adelphia.net>> wrote:
                                  > > We release software to internal users only. Releases are high effort,
                                  > > high ceremony involving infrastructure and our team folks for the
                                  > > mechanical steps, business folks for smoke test and sign off, heightened
                                  > > monitoring and prod support for a while after. There are corporate lock
                                  > > down periods for various reasons, and some releases are scheduled with
                                  > > training in the user sites, which has to be meshed with seasonal
                                  > > business peaks. Quarterly releases are the goal. Hardly agile or ideal
                                  > > even in a non-agile world, but there it is.
                                  > >
                                  > Change only happen when you do not accept the status quo.
                                  > I would suggest that you start the Kaizen.
                                  >
                                  > -d
                                  >
                                  > --
                                  > Sent from gmail so do not trust this communication.
                                  > Do not send me sensitive information here, ask for my none-gmail accounts.
                                  >
                                  > "Therefore the considerations of the intelligent always include both
                                  > benefit and harm." - Sun Tzu
                                  >
                                  >
                                • David H.
                                  ... I would be very sad if someone with an agile mindset would not strive to end such a situation and thus, introduce change. -d -- Sent from gmail so do not
                                  Message 16 of 19 , Jul 8, 2006
                                    On 08/07/06, Jim Standley <jimstandley@...> wrote:
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    > Did I say I wanted to change it? Just answering a survey question about
                                    > what is. :-)
                                    >
                                    I would be very sad if someone with an agile mindset would not strive
                                    to end such a situation and thus, introduce change.

                                    -d

                                    --
                                    Sent from gmail so do not trust this communication.
                                    Do not send me sensitive information here, ask for my none-gmail accounts.

                                    "Therefore the considerations of the intelligent always include both
                                    benefit and harm." - Sun Tzu
                                  • Jim Standley
                                    Yeah, I m fairly sad about it too.
                                    Message 17 of 19 , Jul 9, 2006
                                      Yeah, I'm fairly sad about it too.

                                      David H. wrote:
                                      >
                                      >
                                      > On 08/07/06, Jim Standley <jimstandley@...
                                      > <mailto:jimstandley%40adelphia.net>> wrote:
                                      > >
                                      > >
                                      > >
                                      > >
                                      > >
                                      > >
                                      > >
                                      > > Did I say I wanted to change it? Just answering a survey question about
                                      > > what is. :-)
                                      > >
                                      > I would be very sad if someone with an agile mindset would not strive
                                      > to end such a situation and thus, introduce change.
                                      >
                                      > -d
                                    Your message has been successfully submitted and would be delivered to recipients shortly.