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

Slack for Crises

Expand Messages
  • Greg Akins
    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
    Message 1 of 19 , Jul 5, 2006
      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?

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


      [Non-text portions of this message have been removed]
    • D. AndrĂ© Dhondt
      The customers have the right at any time to change their minds, right? We just write up a new RED card that represents the emergency, with an estimate, and
      Message 2 of 19 , Jul 5, 2006
        The customers have the right at any time to change their minds, right? We
        just write up a new RED card that represents the emergency, with an
        estimate, and get right to work. When things have settled down, we ask the
        customer to exchange a card or cards of their choice from the current
        iteration with the red card.

        We've found that red card work is much less efficient and much more draining
        than normal work, though. What do you do to prevent or reduce the amount of
        emergency work you do? It seems to me like if we were to do preventative
        work it's subject to the 'YAGNI' "you ain't gonna need it" principle and
        therefore not agile; it seems like embracing change is much more useful but
        that attitude can only go so far when we [occasionally] see an iteration get
        burned up in red and the other customers are disappoined that we didn't
        deliver on their cards because someone else's emergency trumped all.

        So where do these emegencies come from? Normally they come from legacy
        applications, that don't have UTs, ATs. These legacy apps are only used a
        few times a year--so it's not easy to get to the root cause (e.g., improve
        the quality of the software we produce / better refine customer requirements
        / etc.) because the cause is outside of our day-to-day development work.
        It's also not a priority to the business, so we don't get the time to clean
        up the legacy apps.


        On 7/5/06, 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?
        >
        > --
        > ==============
        > Greg Akins
        > http://www.pghcodingdojo.org
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >


        [Non-text portions of this message have been removed]
      • 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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.