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

Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac

Expand Messages
  • nicolaslochet
    Hi all, First let me reassert that I share your point of view on the subject. Here is how I see things: - A situation such as the one described of so-called
    Message 1 of 15 , Oct 28, 2011
    • 0 Attachment
      Hi all,

      First let me reassert that I share your point of view on the subject.

      Here is how I see things:
      - A situation such as the one described of so-called "maintenance" shouldn't
      exist for a good Agile team since the team has to deliver working software
      - The situation could happen for a team either having used a classical waterfall
      approach or not being too good with their Agile process
      Indeed this is closer to chaotic than to complex (Jim Highsmith in "Adaptive
      Software Development" has a very good explanation about the distinctions in
      between these environments see pp. 36-37 of his book).

      A synonym for complex could be edge of chaos and indeed when Jeff Sutherland
      thought of building up Scrum this was to be able to manage projects at the edge
      of chaos, see the article from Mike Beedle on the early history of Scrum:
      http://scrum.jeffsutherland.com/2010/08/mike-beedle-on-early-history-of-scrum.ht\
      ml

      So indeed nothing to say that Scrum cannot work in a situation very close from
      Chaos but still at the edge and that it cannot help to bring back things within
      control.

      However I'll give you some context to explain why I think Kanban-Scrum can be
      better adapted than Scrum in a situation where you have constant interruptions
      of your work and where high priority means within the hour... (which again
      doesn't mean that Scrum couldn't work)

      The situation was on a contract for which we were asked to bid (indeed it wasn't
      really a project) for the externalization of the support of an application. I
      only participated to the bid offer. I don't know what happened afterwards and
      how exactly was the situation on site.
      The company asking our bid was a TV-Channel company, the software was the one
      used to build up all their news.
      This means:
      - Need to make a news announcement is not predictable and can happen anytime
      - Time to live broadcast can be as short as a few minutes
      - The software has high interactions with all source of content database to
      provide support for the news
      - The software handles a very high collection of different file formats
      - The software handles the whole flow from creation of the subject to broadcast.

      Now in this situation when you have a bug in the process you cannot wait: it has
      to be fixed now (within the minute for critical things and most often within the
      day)

      If you are rigorous about Scrum you normally don't add items from the backlog
      while you're in the middle of a Sprint. Still you can have some buffer of
      capacity within your sprint to allow that but normally the time to resolution of
      a bug would be N+1 where N is the time to do one sprint.
      You can of course reduce your sprint duration but you can see that in my example
      that wouldn't help that much.

      Now if the interruptions are constant even if your buffer is sufficient enough
      so that you can integrate them the risk is that you loose too much time
      switching from one task to the other.
      Also everything that happens within this buffer is not really a process under
      control as you don't have real time for estimation and cannot really prepare for
      it so that you are organized in the way that creates the maximum added value for
      your customer.

      In a Kanban+Scrum you wouldn't need this buffer and everything can be kept under
      control. The flow is continuous, integration and deliveries are a live process
      so the time in between the addition of a new task and its completion can be
      really short. In this case it would be N'+1 where N' is the time to do one task.
      Kanban also puts limits to the maximum of tasks you can have at one time within
      a certain status (such as in progress, integrated, tested).
      This way it ensures that you don't loose focus and let problems accumulating
      (bottlenecks) by leaving unfinished tasks to take a new high priority one.
      Also it helps reducing, if not removing the loss due to being interrupted and
      having to switch tasks because you only take the new tasks when the one you were
      working upon is done (some loss due to task switching still exists because if
      you have reached a limit of tasks simultaneously within a peculiar status you
      are required to go assist others solving the bottleneck).

      I think that with this method the process is both under better control and more
      efficient.

      I may be wrong. As I said, I have not tested it but I would say that
      theoretically at least it makes much sense to me.

      Cheers,

      Nicolas

      PS: One thing we loose though that I find quite interesting in Scrum is the fact
      that having the timeboxing of a Sprint pushes us to make hard-choices. However
      since this situation is not really a project anymore and should be something not
      made to last I suppose this is ok.
    • Charles Bradley - Scrum Coach CSM PSM I
      Nicolas, Thanks for the added context.  I have a couple of questions to try and get to a root cause. What do you mean by this?? ... is the time to do one
      Message 2 of 15 , Oct 28, 2011
      • 0 Attachment
        Nicolas,

        Thanks for the added context.  I have a couple of questions to try and get to a root cause.

        What do you mean by this??
        > but normally the time to resolution of a bug would be N+1 where N is the time to do one sprint.
        Are you saying you have to wait until an end of sprint boundary to release your bug fix increment?


        When you say Kanban+Scrum, what do you mean?  What from Kanban do you use? What from Scrum do you use?  The number of variations on Kanban-Scrum is infinite, so I'm having trouble analyzing.

         
        -------
        Charles Bradley, CSM, PSM I
        Experienced Scrum Coach
        My blog: http://scrumcrazy.wordpress.com/

        From: nicolaslochet <lochetnicolas@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Friday, October 28, 2011 4:30 AM
        Subject: [scrumdevelopment] Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac

        Hi all,

        First let me reassert that I share your point of view on the subject.

        Here is how I see things:
        - A situation such as the one described of so-called "maintenance" shouldn't
        exist for a good Agile team since the team has to deliver working software
        - The situation could happen for a team either having used a classical waterfall
        approach or not being too good with their Agile process
        Indeed this is closer to chaotic than to complex (Jim Highsmith in "Adaptive
        Software Development" has a very good explanation about the distinctions in
        between these environments see pp. 36-37 of his book).

        A synonym for complex could be edge of chaos and indeed when Jeff Sutherland
        thought of building up Scrum this was to be able to manage projects at the edge
        of chaos, see the article from Mike Beedle on the early history of Scrum:
        http://scrum.jeffsutherland.com/2010/08/mike-beedle-on-early-history-of-scrum.ht\
        ml

        So indeed nothing to say that Scrum cannot work in a situation very close from
        Chaos but still at the edge and that it cannot help to bring back things within
        control.

        However I'll give you some context to explain why I think Kanban-Scrum can be
        better adapted than Scrum in a situation where you have constant interruptions
        of your work and where high priority means within the hour... (which again
        doesn't mean that Scrum couldn't work)

        The situation was on a contract for which we were asked to bid (indeed it wasn't
        really a project) for the externalization of the support of an application. I
        only participated to the bid offer. I don't know what happened afterwards and
        how exactly was the situation on site.
        The company asking our bid was a TV-Channel company, the software was the one
        used to build up all their news.
        This means:
        - Need to make a news announcement is not predictable and can happen anytime
        - Time to live broadcast can be as short as a few minutes
        - The software has high interactions with all source of content database to
        provide support for the news
        - The software handles a very high collection of different file formats
        - The software handles the whole flow from creation of the subject to broadcast.

        Now in this situation when you have a bug in the process you cannot wait: it has
        to be fixed now (within the minute for critical things and most often within the
        day)

        If you are rigorous about Scrum you normally don't add items from the backlog
        while you're in the middle of a Sprint. Still you can have some buffer of
        capacity within your sprint to allow that but normally the time to resolution of
        a bug would be N+1 where N is the time to do one sprint.
        You can of course reduce your sprint duration but you can see that in my example
        that wouldn't help that much.

        Now if the interruptions are constant even if your buffer is sufficient enough
        so that you can integrate them the risk is that you loose too much time
        switching from one task to the other.
        Also everything that happens within this buffer is not really a process under
        control as you don't have real time for estimation and cannot really prepare for
        it so that you are organized in the way that creates the maximum added value for
        your customer.

        In a Kanban+Scrum you wouldn't need this buffer and everything can be kept under
        control. The flow is continuous, integration and deliveries are a live process
        so the time in between the addition of a new task and its completion can be
        really short. In this case it would be N'+1 where N' is the time to do one task.
        Kanban also puts limits to the maximum of tasks you can have at one time within
        a certain status (such as in progress, integrated, tested).
        This way it ensures that you don't loose focus and let problems accumulating
        (bottlenecks) by leaving unfinished tasks to take a new high priority one.
        Also it helps reducing, if not removing the loss due to being interrupted and
        having to switch tasks because you only take the new tasks when the one you were
        working upon is done (some loss due to task switching still exists because if
        you have reached a limit of tasks simultaneously within a peculiar status you
        are required to go assist others solving the bottleneck).

        I think that with this method the process is both under better control and more
        efficient.

        I may be wrong. As I said, I have not tested it but I would say that
        theoretically at least it makes much sense to me.

        Cheers,

        Nicolas

        PS: One thing we loose though that I find quite interesting in Scrum is the fact
        that having the timeboxing of a Sprint pushes us to make hard-choices. However
        since this situation is not really a project anymore and should be something not
        made to last I suppose this is ok.



        ------------------------------------

        To Post a message, send it to:  scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

        <*> To visit your group on the web, go to:
            http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
            Individual Email | Traditional

        <*> To change settings online go to:
            http://groups.yahoo.com/group/scrumdevelopment/join
            (Yahoo! ID required)

        <*> To change settings via email:
            scrumdevelopment-digest@yahoogroups.com
            scrumdevelopment-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
            scrumdevelopment-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
            http://docs.yahoo.com/info/terms/



      • Barlotta, Michael [USA]
        I ll jump in regarding maint etc. We have a program which consists of multiple projects. Some projects are under major development efforts. There are goals to
        Message 3 of 15 , Oct 28, 2011
        • 0 Attachment

          I’ll jump in regarding maint etc.

           

          We have a program which consists of multiple projects.

          Some projects are under major development efforts. There are goals to be met and release plans consisting of multiple sprints. We use scrum and have a team that is “mostly” consistent.

           

          Other projects are in O&M. By contract they have so many “patches” that are released per year.

          For the most part the DR/bugs are not urgent. The releases for these can be very ad hoc regarding release dates, number of bugs fixed, and how consistent team works that effort vs. others. The team (of 1 or 2) is less consistent. So a sprint plan seems overkill (to many on the team) as many will work on the larger efforts and the patch is not as pressing.  A patch release could go out with 5 or 10 DRs and usually that is ok. Or it could go out with 10 DRs this month or next month.

           

          Hope that makes some amount of sense.

           

          Mike

           

           

           

          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Charles Bradley - Scrum Coach CSM PSM I
          Sent: Thursday, October 27, 2011 7:47 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Re: Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac

           

           

          Michael et. al,

           

          I concur with David on this. 

           

          In Ken Schwaber's blog post:

           

          He talks of 4 different types of problem spaces(From Process control theory or some such study):

          Chaotic

          Simple

          Complicated

          Complex

           

          What you describe sounds somewhat chaotic.

          What Dave described, IMO, is an attempt to go from chaotic to complex, and Scrum can work well for complex problem spaces.

           

          In a different forum, Ken also makes the point that Kanban might work well for "complicated" problem spaces, where work is more known than unknown, like IT support tickets (not software bugs, mind you).  For instance, an IT support team that will: install/fix your office phone, install/fix your computer, maintain A/V equipment, etc.  Their requests are often repeated (build pc for person A, build PC for person B, upgrade person C's machine).  Now, each ticket will not be exactly the same, but many of the tickets will have a lot in common and thus there are more knowns than unknowns.

           

          To me, a software maintenance team that is doing bug fixes for defect reports is not "complicated" work, it is "complex" work, and as such Scrum can work just fine. 

           

          You know what doesn't work well?  People getting pulled off of bug fixing efforts all of the time.  It kinds of smacks of the idea that bug fixes are really not that important or urgent, as Dave says. What it smacks of is someone is trying to keep developers "busy" instead of "producing the most value."

           

          I will say that one might be able to use a Kanban board for a Scrum team to help highlight the fact that people are being pulled elsewhere.  But, do you really need a different board to figure that out?  Do you not talk about these issues in the retrospective?  What is is that your team thinks it will get from Kanban that it won't get from Scrum?

           

          I can understand your trepidation about using Scrum in a maint scenario like you described, but tell us where you think you might have difficulty implementing Scrum in that scenario and maybe we can help out.  I've coached several teams that do both maintenance and new features all at the same time.  Typically, it's a single team doing both, so none of this "getting pulled away" business.

           

          -------
          Charles Bradley, CSM, PSM I
          Experienced Scrum Coach
          My blog: http://scrumcrazy.wordpress.com/


          From: David A Barrett <dave.barrett@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Thursday, October 27, 2011 2:53 PM
          Subject: [scrumdevelopment] Re: Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac



          Two thoughts on this:

          First the situation described, which seems to be an endless procession of bug fixes handled in an ad hoc manner, doesn't fit any reasonable definition of "project".  A project is supposed to be a journey, with at least a theoretical end point and some kind of achievable goal.  The only goal in this situation seems to be "keep the software running for another day".

          So I wouldn't call it a project, and I'm not sure that project management processes, Scrum or otherwise, are appropriate to manage it.


          Secondly, the idea that "...operatibility is a key: meaning that any "unexpected situation" would have to be fixed very fast", doesn't ring true with me.  Show me a system where operability isn't a key....you can't.  Just because something doesn't work the way you thought it should doesn't mean that changing it is automatically a top priority.

          OK, so I don't really think that any of this stuff is that important with the situation described, because I don't think this situation really is a "project" in the sense that most of us would think of one.  But this idea that maintenance work somehow presents some insurmountable barrier to Scrum seems to come up over and over, and it just isn't true.

          A bug is simply work that someone wants you to do.  It's not instantly more important than any other work that they want you to do.  If the system is in production, the nature of the bug *might* make it super important, but that's something that you need to decide when it's reported to you.  It's not unestimate-able.  You need to have a system to decide how to triage bugs when they are reported.  Determine if it's something you can clear up in a few minutes, and them maybe you just fix it right away.  If not, you have to evaluate the actual urgency and the importance of the bug.  Bugs which aren't important can wait.  Bugs which aren't urgent - surprise - can wait.

          How do you schedule them?  Personally, I'd just toss them into the PB with all the other work someone wants.  Let the PO figure out what he wants done first.  Others take unction with that, claiming that it screws up their metrics, and velocity and earned value with rework.  So have a different list if it makes you feel better.

          Here's the key thing, once you've got a way to get the trivial, non-urgent, or non-important unscheduled out of the day to day interruptions, you then get a feel for how much time the  truly non-trivial urgent and important stuff sucks out of your Sprint.  Then plan your Sprints taking this into account.



          Dave Barrett


          This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

          Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.

           

        • avinap77
          Hi Nicolas ... So what you r describing is a situation where your team needed to provide support for an already existing, mission-critical and (probably) buggy
          Message 4 of 15 , Oct 28, 2011
          • 0 Attachment
            Hi Nicolas

            --- "nicolaslochet" <lochetnicolas@...> wrote:
            > The situation was on a contract for which we were asked to bid
            > (indeed it wasn't
            > really a project) for the externalization of the support of an
            > application.

            So what you'r describing is a situation where your team needed to provide support for an already existing, mission-critical and (probably) buggy system.

            In other words - you were bidding to be a firefighter, not a software developer. It's just coincidental that your "fires" were unexpected bugs and that your "fire hose" was a keyboard. :)

            In that case I guess scrum would indeed not apply - as it would not be relevant for real firefighters, policemen, or ER doctors.
            Kanban might be more fit for that, as would other support models (3-level support model etc.).

            Still, it would be interesting to check if the agile values could be applied and what benefit could arise form them.
            For instance - customer collaboration over contract negotiation comes to mind - It would be better to have a good personal relationship with your support-person than have a rigorous contract.

            In fact here's a real life example - I just today needed to get my car towed. No matter what my towing contract said, I still needed to wait over 3 hours for the tow-truck to come. But once I got eye-contact with the person driving the truck ad breaking some ice, we started collaborating and he was very kind and gave me excellent and gracious service, even bending the fine lines of the contractual boundaries. Had either of us started fighting over contract subtleties I'm sure none of us would really benefit.

            But back to your example - I'd make the distinction between this situation and the process of developing software. Sounds like a whole different ballgame.
            Wouldn't you agree?

            Avi
          • Charles Bradley - Scrum Coach CSM PSM I
            Avi, You make some good points.  I m just not convinced that Kanban is the best answer.  It might be the best answer of the widely known processes though.
            Message 5 of 15 , Oct 28, 2011
            • 0 Attachment
              Avi,

              You make some good points.  I'm just not convinced that Kanban is the best answer.  It might be the best answer of the widely known processes though.

              OTOH, let's take your analogy a step further.  If the bugs he speaks of are truly important and urgent, and the situation as chaotic as described by process theory, then let's look at the ER/triage model for a better fit.

              Kanban is for work that is more similar in nature than different, and I'm not sure a chaotic environment like an ER room has "similar in nature" type work (same would go for firefighters).  Also, since Kanban is very much about continuous flow, I would argue that an ER room is definitely NOT about continuous flow.  It's more about a hierarchical value system (preventing death, dealing with the most critical emergencies first, saving the most lives, etc etc).  In that vain, I would like an ER triage process more than a "continuous flow" process.    What do you do if you have a guy who is having a hard attack but your "WIP limit" and "Silver ticket limit" is exceeded?  While I think that you could modify Kanban to fit better here, I also think the Kanban as we know it is not necessarily the best fit for a chaotic environment.  The Kanban board shows bottlenecks, but maybe what we need to show here is some relationship between the most critical work and whether that critical work is being done or not (so WIP limits don't really apply I think -- maybe resource limits and prioritization is more important to show than bottlenecks).

              Of course, as we apply this metaphor to software, there is a slight difference. As ER doctors, we have the ability to directly influence the amount of emergencies coming in the door.  I don't think that really fits the Kanban model either.

              (Btw, I don't think Scrum fits well here either)
               
              -------
              Charles Bradley, CSM, PSM I
              Experienced Scrum Coach
              My blog: http://scrumcrazy.wordpress.com/

              From: avinap77 <avi_a@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Friday, October 28, 2011 1:17 PM
              Subject: [scrumdevelopment] Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac

              Hi Nicolas

              --- "nicolaslochet" <lochetnicolas@...> wrote:
              > The situation was on a contract for which we were asked to bid
              > (indeed it wasn't
              > really a project) for the externalization of the support of an
              > application.

              So what you'r describing is a situation where your team needed to provide support for an already existing, mission-critical and (probably) buggy system.

              In other words - you were bidding to be a firefighter, not a software developer. It's just coincidental that your "fires" were unexpected bugs and that your "fire hose" was a keyboard. :)

              In that case I guess scrum would indeed not apply - as it would not be relevant for real firefighters, policemen, or ER doctors.
              Kanban might be more fit for that, as would other support models (3-level support model etc.).

              Still, it would be interesting to check if the agile values could be applied and what benefit could arise form them.
              For instance - customer collaboration over contract negotiation comes to mind - It would be better to have a good personal relationship with your support-person than have a rigorous contract.

              In fact here's a real life example - I just today needed to get my car towed. No matter what my towing contract said, I still needed to wait over 3 hours for the tow-truck to come. But once I got eye-contact with the person driving the truck ad breaking some ice, we started collaborating and he was very kind and gave me excellent and gracious service, even bending the fine lines of the contractual boundaries. Had either of us started fighting over contract subtleties I'm sure none of us would really benefit.

              But back to your example - I'd make the distinction between this situation and the process of developing software. Sounds like a whole different ballgame.
              Wouldn't you agree?

              Avi





              ------------------------------------

              To Post a message, send it to:  scrumdevelopment@...
              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

              <*> To visit your group on the web, go to:
                  http://groups.yahoo.com/group/scrumdevelopment/

              <*> Your email settings:
                  Individual Email | Traditional

              <*> To change settings online go to:
                  http://groups.yahoo.com/group/scrumdevelopment/join
                  (Yahoo! ID required)

              <*> To change settings via email:
                  scrumdevelopment-digest@yahoogroups.com
                  scrumdevelopment-fullfeatured@yahoogroups.com

              <*> To unsubscribe from this group, send an email to:
                  scrumdevelopment-unsubscribe@yahoogroups.com

              <*> Your use of Yahoo! Groups is subject to:
                  http://docs.yahoo.com/info/terms/



            • avinap77
              Hi Charles. ... I m not extremely acquainted with the subtleties of Kanban - so I ll have to assume you re correct here and let others comment. ... I assume
              Message 6 of 15 , Oct 29, 2011
              • 0 Attachment
                Hi Charles.

                --- Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                >
                > Avi,
                >
                > You make some good points.  I'm just not convinced that Kanban is
                > the best answer.  It might be the best answer of the widely known
                > processes though.
                >
                I'm not extremely acquainted with the subtleties of Kanban - so I'll have to assume you're correct here and let others comment.


                A little off-topic but I do have a concern with your final statement:

                > As ER doctors, we have the ability to directly influence
                > the amount of emergencies coming in the door.
                >
                I assume you meant the opposite? I don't suppose any ER doctor really can or will be willing to refrain from treating an emergency case, but would rather need to find creative ways to accommodate them and quickly remove any impediments.

                I assume this is also the case in Nicolas's example - where bugs needed to be addresses ASAP and at all costs.

                Avi
              • brendabao321
                ... Put one of the ongoing thing on hold, and empty one slow for the most emergent one (heart attack). Or you can just adjust the limit. While I think that you
                Message 7 of 15 , Oct 29, 2011
                • 0 Attachment
                  --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                  >
                  > Avi,
                  >
                  > You make some good points.  I'm just not convinced that Kanban is the best answer.  It might be the best answer of the widely known processes though.
                  >
                  > OTOH, let's take your analogy a step further.  If the bugs he speaks of are truly important and urgent, and the situation as chaotic as described by process theory, then let's look at the ER/triage model for a better fit.
                  >
                  > Kanban is for work that is more similar in nature than different, and I'm not sure a chaotic environment like an ER room has "similar in nature" type work (same would go for firefighters).  Also, since Kanban is very much about continuous flow, I would argue that an ER room is definitely NOT about continuous flow.  It's more about a hierarchical value system (preventing death, dealing with the most critical emergencies first, saving the most lives, etc etc).  In that vain, I would like an ER triage process more than a "continuous flow" process.    What do you do if you have a guy who is having a hard attack but your "WIP limit" and "Silver ticket limit" is exceeded? 


                  Put one of the ongoing thing on hold, and empty one slow for the most emergent
                  one (heart attack). Or you can just adjust the limit.



                  While I think that you could modify Kanban to fit better here, I also think the Kanban as we know it is not necessarily the best fit for a chaotic environment.  The Kanban board shows bottlenecks, but maybe what we need to show here is some relationship between the most critical work
                  > and whether that critical work is being done or not (so WIP limits don't really apply I think -- maybe resource limits and prioritization is more important to show than bottlenecks).
                  >


                  I think the most powerful thing of Kanban is to make things visible.


                  > Of course, as we apply this metaphor to software, there is a slight difference. As ER doctors, we have the ability to directly influence the amount of emergencies coming in the door.  I don't think that really fits the Kanban model either.
                  >
                  > (Btw, I don't think Scrum fits well here either)
                  >
                  >  
                  > -------
                  > Charles Bradley, CSM, PSM I
                  > Experienced Scrum Coach
                  > My blog: http://scrumcrazy.wordpress.com/
                  >
                  >
                  > >________________________________
                  > >From: avinap77 <avi_a@...>
                  > >To: scrumdevelopment@yahoogroups.com
                  > >Sent: Friday, October 28, 2011 1:17 PM
                  > >Subject: [scrumdevelopment] Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac
                  > >
                  > >Hi Nicolas
                  > >
                  > >--- "nicolaslochet" <lochetnicolas@> wrote:
                  > >> The situation was on a contract for which we were asked to bid
                  > >> (indeed it wasn't
                  > >> really a project) for the externalization of the support of an
                  > >> application.
                  > >
                  > >So what you'r describing is a situation where your team needed to provide support for an already existing, mission-critical and (probably) buggy system.
                  > >
                  > >In other words - you were bidding to be a firefighter, not a software developer. It's just coincidental that your "fires" were unexpected bugs and that your "fire hose" was a keyboard. :)
                  > >
                  > >In that case I guess scrum would indeed not apply - as it would not be relevant for real firefighters, policemen, or ER doctors.
                  > >Kanban might be more fit for that, as would other support models (3-level support model etc.).
                  > >
                  > >Still, it would be interesting to check if the agile values could be applied and what benefit could arise form them.
                  > >For instance - customer collaboration over contract negotiation comes to mind - It would be better to have a good personal relationship with your support-person than have a rigorous contract.
                  > >
                  > >In fact here's a real life example - I just today needed to get my car towed. No matter what my towing contract said, I still needed to wait over 3 hours for the tow-truck to come. But once I got eye-contact with the person driving the truck ad breaking some ice, we started collaborating and he was very kind and gave me excellent and gracious service, even bending the fine lines of the contractual boundaries. Had either of us started fighting over contract subtleties I'm sure none of us would really benefit.
                  > >
                  > >But back to your example - I'd make the distinction between this situation and the process of developing software. Sounds like a whole different ballgame.
                  > >Wouldn't you agree?
                  > >
                  > >Avi
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >------------------------------------
                  > >
                  > >To Post a message, send it to:  scrumdevelopment@...
                  > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  >
                • David A Barrett
                  ... One thing strikes me about this. A bug that can be fixed within a minute is by definition trivial. Any bug that has an urgency level of fix within a
                  Message 8 of 15 , Oct 31, 2011
                  • 0 Attachment
                    >Now in this situation when you have a bug in the
                    > process you cannot wait: it has to be fixed now
                    >(within the minute for critical things and most often
                    >within the day)

                    One thing strikes me about this.  A bug that can be fixed "within a minute" is by definition trivial.  Any bug that has an urgency level of "fix within a minute" is also going to require handling outside of any formal project management methodology (other than tell the users, "Here's the number you call when this happens"), simply because there won't be any time to do any project management.

                    So it seems that as long as your team has the ability to determine whether or not something is trivial, or whether or not the business really does need it fixed "right now", you shouldn't have trouble with Scrum.  

                    Seriously, a problem that you can fix "within a minute" isn't going to tank your Sprint.  Nor would 60 of them a week; if they really only took a minute resolve.  But what you'd probably want to do is figure out what's really happening to cause all these emergencies, and get the PO to prioritize a proper correction to the problem so that they don't happen any more.

                    In my experience, what kills you is the programmers getting wound up in some problem that isn't urgent, isn't important (or at least urgent enough, or  improtant enough) and takes a significant amount of time to fix.   I had that happen last week.  One of the programmers spent a whole day on a support request that (he thought) the CIO had passed on to him, and he was prepared to spend another half day on it.  No way was it more important than the project that we're working on.  When it came up at the Scrum as an impediment, I told him to stop working on it and I'd make sure the parties involved knew they'd have to figure it out without him.  But the day was lost.  Where the hell did I put my Tardis?

                    So here's the thing:  Yes, the business has to keep going and the programmers will need to drop everything and put out a fire when the business is stopped.  But beyond that, the programmers are delivering the greatest value to the business when they are working on the things that the organization has identified are the most important things - in other words, the Sprint Backlog.  The most common situation that arises, however, is where the business isn't stopped or put a great risk, but a problem has been identified.   The other thing that happens is that there's a quick fix, but the programmer sees a bigger, systematic, problem which isn't quick and decides to solve that, so the problem won't happen again.  In those cases, when the developers spend too much time (or any time) on those issues, they are actually usurping the PO's right to make prioritization decisions about the product.

                    My guess is that anyone having trouble with maintenance issues tanking Sprint deliverables has a team that hasn't got a handle on determining what really is mission critical for the business, and funnelling anything non-trivial that isn't mission critical into the PB.  It might help to make sure that the developers understand that they'll pretty much only get measured or evaluated on their ability to deliver Sprint after Sprint on the Sprint deliverables.  




                    Dave Barrett


                    This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

                    Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
                  • Charles Bradley - Scrum Coach CSM PSM I
                    ...   ... assume you meant the opposite? I don t suppose any ER doctor really can or will be willing ... would rather need to find creative ways to
                    Message 9 of 15 , Oct 31, 2011
                    • 0 Attachment
                      > A little off-topic but I do have a concern with your final statement:

                      >> As ER doctors, we have the ability to directly influence
                      >> the amount of emergencies coming in the door.
                       
                      > I
                      assume you meant the opposite? I don't suppose any ER doctor really can or will be willing
                      > to refrain from treating an emergency case, but
                      would rather need to find creative ways to accommodate them and quickly remove any impediments.

                      > I assume this is also the case in Nicolas's example - where bugs needed to be addresses ASAP and at all costs.

                      My point here was that, as software developers(I said "ER Doctors" but I was still speaking in the metaphor), we have the ability to influence how many emergencies come through the door (by better design/quality, paying off technical debt that causes emergencies, etc).  That is the one key difference that we should always remember and where the ER metaphor breaks down.  Oh sure, doctors and firefighters can have 'indirect' influence over health and safety, but usually never direct influence.  We software developers can have direct influence.
                       
                      -------
                      Charles Bradley, CSM, PSM I
                      Experienced Scrum Coach
                      My blog: http://scrumcrazy.wordpress.com/

                      From: avinap77 <avi_a@...>
                      To: scrumdevelopment@yahoogroups.com
                      Sent: Saturday, October 29, 2011 2:16 PM
                      Subject: [scrumdevelopment] Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac

                      Hi Charles.

                      --- Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                      >
                      > Avi,
                      >
                      > You make some good points.  I'm just not convinced that Kanban is
                      > the best answer.  It might be the best answer of the widely known
                      > processes though.
                      >
                      I'm not extremely acquainted with the subtleties of Kanban - so I'll have to assume you're correct here and let others comment.


                      A little off-topic but I do have a concern with your final statement:

                      > As ER doctors, we have the ability to directly influence
                      > the amount of emergencies coming in the door.
                      >
                      I assume you meant the opposite? I don't suppose any ER doctor really can or will be willing to refrain from treating an emergency case, but would rather need to find creative ways to accommodate them and quickly remove any impediments.

                      I assume this is also the case in Nicolas's example - where bugs needed to be addresses ASAP and at all costs.

                      Avi




                      ------------------------------------

                      To Post a message, send it to:  scrumdevelopment@...
                      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                      <*> To visit your group on the web, go to:
                          http://groups.yahoo.com/group/scrumdevelopment/

                      <*> Your email settings:
                          Individual Email | Traditional

                      <*> To change settings online go to:
                          http://groups.yahoo.com/group/scrumdevelopment/join
                          (Yahoo! ID required)

                      <*> To change settings via email:
                          scrumdevelopment-digest@yahoogroups.com
                          scrumdevelopment-fullfeatured@yahoogroups.com

                      <*> To unsubscribe from this group, send an email to:
                          scrumdevelopment-unsubscribe@yahoogroups.com

                      <*> Your use of Yahoo! Groups is subject to:
                          http://docs.yahoo.com/info/terms/



                    • woynam
                      In Nicolas case, I don t think they had any input on the design and development of the software, as they signed a contract to provide production support to an
                      Message 10 of 15 , Oct 31, 2011
                      • 0 Attachment
                        In Nicolas' case, I don't think they had any input on the design and development of the software, as they signed a contract to provide production support to an existing product.

                        I'm curious. Nicolas, did your company (code) review the software before bidding on the project? Did you ask to see a list of bugs known at the time? Did you ask to see the reports from running unit and/or acceptance tests? Does the software have a set of automated tests?

                        If not, what type of due diligence did the management of the company perform before bidding on the project?

                        Mark


                        --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                        >
                        > > A little off-topic but I do have a concern with your final statement:
                        >
                        > >> As ER doctors, we have the ability to directly influence
                        > >> the amount of emergencies coming in the door.
                        >  
                        > > I
                        > assume you meant the opposite? I don't suppose any ER doctor really can
                        > or will be willing
                        >
                        > > to refrain from treating an emergency case, but
                        > would rather need to find creative ways to accommodate them and quickly
                        > remove any impediments.
                        >
                        > > I assume this is also the case in Nicolas's example - where bugs needed to be addresses ASAP and at all costs.
                        >
                        > My point here was that, as software developers(I said "ER Doctors" but I was still speaking in the metaphor), we have the ability to influence how many emergencies come through the door (by better design/quality, paying off technical debt that causes emergencies, etc).  That is the one key difference that we should always remember and where the ER metaphor breaks down.  Oh sure, doctors and firefighters can have 'indirect' influence over health and safety, but usually never direct influence.  We software developers can have direct influence.
                        >
                        >  
                        > -------
                        > Charles Bradley, CSM, PSM I
                        > Experienced Scrum Coach
                        > My blog: http://scrumcrazy.wordpress.com/
                        >
                        >
                        > >________________________________
                        > >From: avinap77 <avi_a@...>
                        > >To: scrumdevelopment@yahoogroups.com
                        > >Sent: Saturday, October 29, 2011 2:16 PM
                        > >Subject: [scrumdevelopment] Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac
                        > >
                        > >Hi Charles.
                        > >
                        > >--- Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@> wrote:
                        > >>
                        > >> Avi,
                        > >>
                        > >> You make some good points.  I'm just not convinced that Kanban is
                        > >> the best answer.  It might be the best answer of the widely known
                        > >> processes though.
                        > >>
                        > >I'm not extremely acquainted with the subtleties of Kanban - so I'll have to assume you're correct here and let others comment.
                        > >
                        > >
                        > >A little off-topic but I do have a concern with your final statement:
                        > >
                        > >> As ER doctors, we have the ability to directly influence
                        > >> the amount of emergencies coming in the door.
                        > >>
                        > >I assume you meant the opposite? I don't suppose any ER doctor really can or will be willing to refrain from treating an emergency case, but would rather need to find creative ways to accommodate them and quickly remove any impediments.
                        > >
                        > >I assume this is also the case in Nicolas's example - where bugs needed to be addresses ASAP and at all costs.
                        > >
                        > >Avi
                        > >
                        > >
                        > >
                        > >
                        > >------------------------------------
                        > >
                        > >To Post a message, send it to:  scrumdevelopment@...
                        > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                        > >
                        > >
                        > >
                        > >
                        > >
                        > >
                        >
                      • Charles Bradley - Scrum Coach CSM PSM I
                        Good post Mark.  I think my point is valid even if they only signed a contract to do production support -- they can still directly influence the software by
                        Message 11 of 15 , Oct 31, 2011
                        • 0 Attachment
                          Good post Mark.  I think my point is valid even if they only signed a contract to do production support -- they can still directly influence the software by proposing changes to it that the original company would then pay for(esp if the prod support company can show that it will save them money).  Obviously, if there is no room to move there, then you are correct, a) they will forever be chaotic, which is not a problem space for Scrum and b) they should have done some serious risk mitigation before signing that contract.
                           
                          -------
                          Charles Bradley, CSM, PSM I
                          Experienced Scrum Coach
                          My blog: http://scrumcrazy.wordpress.com/

                          From: woynam <woyna@...>
                          To: scrumdevelopment@yahoogroups.com
                          Sent: Monday, October 31, 2011 12:25 PM
                          Subject: [scrumdevelopment] Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac


                          In Nicolas' case, I don't think they had any input on the design and development of the software, as they signed a contract to provide production support to an existing product.

                          I'm curious. Nicolas, did your company (code) review the software before bidding on the project? Did you ask to see a list of bugs known at the time? Did you ask to see the reports from running unit and/or acceptance tests? Does the software have a set of automated tests?

                          If not, what type of due diligence did the management of the company perform before bidding on the project?

                          Mark


                          --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                          >
                          > > A little off-topic but I do have a concern with your final statement:
                          >
                          > >> As ER doctors, we have the ability to directly influence
                          > >> the amount of emergencies coming in the door.
                          >  
                          > > I
                          >  assume you meant the opposite? I don't suppose any ER doctor really can
                          >  or will be willing
                          >
                          > > to refrain from treating an emergency case, but
                          > would rather need to find creative ways to accommodate them and quickly
                          > remove any impediments.
                          >
                          > > I assume this is also the case in Nicolas's example - where bugs needed to be addresses ASAP and at all costs.
                          >
                          > My point here was that, as software developers(I said "ER Doctors" but I was still speaking in the metaphor), we have the ability to influence how many emergencies come through the door (by better design/quality, paying off technical debt that causes emergencies, etc).  That is the one key difference that we should always remember and where the ER metaphor breaks down.  Oh sure, doctors and firefighters can have 'indirect' influence over health and safety, but usually never direct influence.  We software developers can have direct influence.
                          >
                          >  
                          > -------
                          > Charles Bradley, CSM, PSM I
                          > Experienced Scrum Coach
                          > My blog: http://scrumcrazy.wordpress.com/
                          >
                          >
                          > >________________________________
                          > >From: avinap77 <avi_a@...>
                          > >To: scrumdevelopment@yahoogroups.com
                          > >Sent: Saturday, October 29, 2011 2:16 PM
                          > >Subject: [scrumdevelopment] Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac
                          > >
                          > >Hi Charles.
                          > >
                          > >--- Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@> wrote:
                          > >>
                          > >> Avi,
                          > >>
                          > >> You make some good points.  I'm just not convinced that Kanban is
                          > >> the best answer.  It might be the best answer of the widely known
                          > >> processes though.
                          > >>
                          > >I'm not extremely acquainted with the subtleties of Kanban - so I'll have to assume you're correct here and let others comment.
                          > >
                          > >
                          > >A little off-topic but I do have a concern with your final statement:
                          > >
                          > >> As ER doctors, we have the ability to directly influence
                          > >> the amount of emergencies coming in the door.
                          > >>
                          > >I assume you meant the opposite? I don't suppose any ER doctor really can or will be willing to refrain from treating an emergency case, but would rather need to find creative ways to accommodate them and quickly remove any impediments.
                          > >
                          > >I assume this is also the case in Nicolas's example - where bugs needed to be addresses ASAP and at all costs.
                          > >
                          > >Avi
                          > >
                          > >
                          > >
                          > >
                          > >------------------------------------
                          > >
                          > >To Post a message, send it to:  scrumdevelopment@...
                          > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                          > >
                          > >
                          > >
                          > >
                          > >
                          > >
                          >




                          ------------------------------------

                          To Post a message, send it to:  scrumdevelopment@...
                          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                          <*> To visit your group on the web, go to:
                              http://groups.yahoo.com/group/scrumdevelopment/

                          <*> Your email settings:
                              Individual Email | Traditional

                          <*> To change settings online go to:
                              http://groups.yahoo.com/group/scrumdevelopment/join
                              (Yahoo! ID required)

                          <*> To change settings via email:
                              scrumdevelopment-digest@yahoogroups.com
                              scrumdevelopment-fullfeatured@yahoogroups.com

                          <*> To unsubscribe from this group, send an email to:
                              scrumdevelopment-unsubscribe@yahoogroups.com

                          <*> Your use of Yahoo! Groups is subject to:
                              http://docs.yahoo.com/info/terms/



                        • nicolaslochet
                          Sorry for the delay answering. I have a lot to do at the moment and not enough time to come back here. To give some added context: The TV channel company
                          Message 12 of 15 , Oct 31, 2011
                          • 0 Attachment
                            Sorry for the delay answering. I have a lot to do at the moment and not enough time to come back here.

                            To give some added context:
                            The TV channel company specifically asked for a TMA Agile (TMA for Third Maintenance Application). The Agile idea came from their side since they had a good experience with a Scrum project in another department with another software.
                            My company has an interest in Agility so they were willing to accomodate but Agile would not have been their first answer for that. They would have gone with a classical maitenance contract.
                            We had limited information available to us and were in competition with others. I'm not sure my company got the project in the end (I was only there to help on the proposal but then moved to other projects).
                            To get more information about the situation we asked for their bug report and went there to discuss with their managers. I don't remember the details but I know that we could interfere from the figures that they were accumulating technical debt.
                            We had the situation regarding their validation process and knew about the general release plan they had (there still had a bit of development on the software and were spreading the tool among two different TV channels).

                            I know that they had no automatic tests. In fact, we proposed to implement some but I don't really remember if their application was here to last or if they had to kind of survive until something new, so I don't know if it was economically interesting.

                            We had no input in the design of the previous software but had some limited room to suggest improvements if we were to win the contract.

                            > > > I assume this is also the case in Nicolas's example - where bugs needed to be addresses ASAP and at all costs.

                            Indeed in case of blocking bugs those were to be fixed at all costs.

                            As for the Kanban I was thinking of I think from reading Jeff Sutherland post that it was in fact very close if not the same as the Scrum process he is using.
                            The idea was to keep everything from Scrum. Remove the Sprint and add work-limits (I'm not sure Jeff removes the Sprint notion though).

                            Cheers

                            Nicolas
                          • Gary Brown
                            Hello, David! If a feature has a defect, it is not done. There are a couple of ways to handle it, fix it or put it on a list somewhere. My preference is to
                            Message 13 of 15 , Oct 31, 2011
                            • 0 Attachment
                              Hello, David!

                              If a feature has a defect, it is not done. There are a couple of ways
                              to handle it, fix it or put it on a list somewhere. My preference is
                              to fix it, then inspect our engineering practices to identify ways to
                              improve and adapt so that we don't release defects to our customers.

                              We will never be perfect, but we can get better! 8^)

                              GB.


                              Quoting David A Barrett <dave.barrett@...>:

                              >> Now in this situation when you have a bug in the
                              >> process you cannot wait: it has to be fixed now
                              >> (within the minute for critical things and most often
                              >> within the day)
                              >
                              > One thing strikes me about this. A bug that can be fixed "within a
                              > minute" is by definition trivial. Any bug that has an urgency level of
                              > "fix within a minute" is also going to require handling outside of any
                              > formal project management methodology (other than tell the users, "Here's
                              > the number you call when this happens"), simply because there won't be any
                              > time to do any project management.
                              >
                              > So it seems that as long as your team has the ability to determine whether
                              > or not something is trivial, or whether or not the business really does
                              > need it fixed "right now", you shouldn't have trouble with Scrum.
                              >
                              > Seriously, a problem that you can fix "within a minute" isn't going to
                              > tank your Sprint. Nor would 60 of them a week; if they really only took a
                              > minute resolve. But what you'd probably want to do is figure out what's
                              > really happening to cause all these emergencies, and get the PO to
                              > prioritize a proper correction to the problem so that they don't happen
                              > any more.
                              >
                              > In my experience, what kills you is the programmers getting wound up in
                              > some problem that isn't urgent, isn't important (or at least urgent
                              > enough, or improtant enough) and takes a significant amount of time to
                              > fix. I had that happen last week. One of the programmers spent a whole
                              > day on a support request that (he thought) the CIO had passed on to him,
                              > and he was prepared to spend another half day on it. No way was it more
                              > important than the project that we're working on. When it came up at the
                              > Scrum as an impediment, I told him to stop working on it and I'd make sure
                              > the parties involved knew they'd have to figure it out without him. But
                              > the day was lost. Where the hell did I put my Tardis?
                              >
                              > So here's the thing: Yes, the business has to keep going and the
                              > programmers will need to drop everything and put out a fire when the
                              > business is stopped. But beyond that, the programmers are delivering the
                              > greatest value to the business when they are working on the things that
                              > the organization has identified are the most important things - in other
                              > words, the Sprint Backlog. The most common situation that arises,
                              > however, is where the business isn't stopped or put a great risk, but a
                              > problem has been identified. The other thing that happens is that
                              > there's a quick fix, but the programmer sees a bigger, systematic, problem
                              > which isn't quick and decides to solve that, so the problem won't happen
                              > again. In those cases, when the developers spend too much time (or any
                              > time) on those issues, they are actually usurping the PO's right to make
                              > prioritization decisions about the product.
                              >
                              > My guess is that anyone having trouble with maintenance issues tanking
                              > Sprint deliverables has a team that hasn't got a handle on determining
                              > what really is mission critical for the business, and funnelling anything
                              > non-trivial that isn't mission critical into the PB. It might help to
                              > make sure that the developers understand that they'll pretty much only get
                              > measured or evaluated on their ability to deliver Sprint after Sprint on
                              > the Sprint deliverables.
                              >
                              >
                              >
                              >
                              > Dave Barrett
                              >
                              >
                              > This e-mail may be privileged and/or confidential, and the sender does not
                              > waive any related rights and obligations. Any distribution, use or copying
                              > of this e-mail or the information it contains by other than an intended
                              > recipient is unauthorized. If you received this e-mail in error, please
                              > delete it and advise me (by return e-mail or otherwise) immediately.
                              >
                              > Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
                              > renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
                              > utilisation ou copie de ce message ou des renseignements qu'il contient
                              > par une personne autre que le (les) destinataire(s) désigné(s) est
                              > interdite. Si vous recevez ce courrier électronique par erreur, veuillez
                              > le supprimer et m'en aviser immédiatement, par retour de courrier
                              > électronique ou par un autre moyen.



                              ----------------------------------------------------------------
                              This message was sent using IMP, the Internet Messaging Program.
                            Your message has been successfully submitted and would be delivered to recipients shortly.