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

Re: [scrumdevelopment] Does anyone have experience in adopting Scrum in Software Maintenance?

Expand Messages
  • Ali moghadam
    Hi As mentioned in the Scrum Guide, scrum is a suitable for complex adaptive problems. So I don t suggest scrum for a team who is dedicated to maintenance, as
    Message 1 of 21 , Sep 28, 2012
    View Source
    • 0 Attachment
      Hi
      As mentioned in the Scrum Guide, scrum is a suitable for complex adaptive problems. So I don't suggest scrum for a team who is dedicated to maintenance, as usually they need more discipline.  Kanban may be a better tool. 
      -alix

      Sent from my iPad

      On Sep 28, 2012, at 6:04 AM, "lixiaozhou" <lixiaozhou725@...> wrote:

       

      Greetings

      My name is Xiaozhou Li, a student in University of Tampere in Finland. And i'm a total rookie in scrum development area. Recently, i've been working on my master thesis concerning adopting Scrum in software maintenance and relevant issues. And so far i have some general questions including:

      How do you feel about using scrum in software maintenance compared with traditional software maintenance process (personally)?

      In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?

      Are there any drawbacks that bothering you if any?

      What are the best practices you think would be concerning scrum in software maintenance?

      ......

      I would bring up more specific questions about it later on as i'm a bit stuck so far. Thanks a lot for your kind responses including all constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...

      ps. feel free to contact me with any sort of ideas
      email: lixiaozhou725@...

    • lixiaozhou
      Hi, Steve Thank you for your time replying. I kind of screwed myself up by choosing this topic when i have no actual experience in a real-life scrum project.
      Message 2 of 21 , Sep 28, 2012
      View Source
      • 0 Attachment
        Hi, Steve

        Thank you for your time replying. I kind of screwed myself up by choosing this topic when i have no actual experience in a real-life scrum project. Anyway,long story :D

        And concerning what you've brought up, that's the thing i'm interested in. And what i would also like to know is that how a PO prioritize the sprint backlog and maintenance backlog simultaneously.Are there any models to follow or universal guidelines? And what are the factors that might influence the priority of maintenance stories compared to original user stories? That would be the spot i could write something about. And do you by any chance know some projects that I might use as a case?

        Many Thanks for your time. And sorry for my lack of knowledge.

        Best wishes.

        --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
        >
        > Hi
        >
        > My first question is how come you are doing a masters in 'advanced' Scrum when you are still a rookie! But that's acedemia for you!
        >
        > The way I have implemented it has always been with developers that are also maintainers.
        >
        > They work 3 week Sprints on developement during which time maintenance requests come in and are added to a Maintenance Backlog (I even managed to get the users to write requests in User Story format for one implementation!).
        >
        > On the Monday of the fourth week all the relevant people gather for a maintenance Sprint planning workshop where the requests are prioritised, estimated and planned.
        >
        > The team work their way through the plan for the rest of the week and have a demo on the pm of the Friday; then they go back to development on the next Monday.
        >
        > This has had the effect that some low priority maintenance requests never get done; some increase in priority as time goes on.
        >
        > Of course 'showstopper' maintenance requests are dealt with immediately; the team allow for such possibilities in their development sprint planning but it happens very rarely.
        >
        > So that's one way. I have never seen a dedicated maintenance team.
        >
        > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@> wrote:
        > >
        > > Greetings
        > >
        > > My name is Xiaozhou Li, a student in University of Tampere in Finland. And i'm a total rookie in scrum development area. Recently, i've been working on my master thesis concerning adopting Scrum in software maintenance and relevant issues. And so far i have some general questions including:
        > >
        > > How do you feel about using scrum in software maintenance compared with traditional software maintenance process (personally)?
        > >
        > > In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?
        > >
        > > Are there any drawbacks that bothering you if any?
        > >
        > > What are the best practices you think would be concerning scrum in software maintenance?
        > >
        > > ......
        > >
        > > I would bring up more specific questions about it later on as i'm a bit stuck so far. Thanks a lot for your kind responses including all constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
        > >
        > > ps. feel free to contact me with any sort of ideas
        > > email: lixiaozhou725@
        > >
        >
      • Steve
        Hi again I need to clarify something with you before I can answer your questions properly. Are the backlogs for the same project/system/product or are they for
        Message 3 of 21 , Oct 1, 2012
        View Source
        • 0 Attachment
          Hi again

          I need to clarify something with you before I can answer your questions properly.

          Are the backlogs for the same project/system/product or are they for different ones?

          In my example, the product being developed in the 3 week sprints is different from the products being maintained in the 1 week maniternance sprints.

          If the 'maintenance' requests are for a project/system/product that is being developed (ie after the first release), then the requests get added to the Product Backlog and are ordered in the normal way. I am assuming that this is your situation given that you refer to 'prioritising both backlogs simultaneously'; is my assumption correct?

          If I am correct, then stop thinking of the 'change requests' as 'maintenance', they are just new requirements.

          BTW, Scrum no longer speaks about 'prioritisation', the OK worf now is 'ordering'.

          --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou@...> wrote:

          > And concerning what you've brought up, that's the thing i'm interested in. And what i would also like to know is that how a PO prioritize the sprint backlog and maintenance backlog simultaneously.Are there any models to follow or universal guidelines? And what are the factors that might influence the priority of maintenance stories compared to original user stories? That would be the spot i could write something about. And do you by any chance know some projects that I might use as a case?
        • Kevin Callahan
          Hi Xiaozhou, Here s what the team I work with is doing these days; I would say we re an intermediate-level adoption and constantly striving to improve. We have
          Message 4 of 21 , Oct 1, 2012
          View Source
          • 0 Attachment
            Hi Xiaozhou,

            Here's what the team I work with is doing these days; I would say we're an intermediate-level adoption and constantly striving to improve. We have several scrum teams working toward a web oriented architecture, meaning that teams write features required by other teams and then expose that functionality via external API calls. One of the pain points is the conflict between planned feature development and unplanned emergent work, a nice way to say production issues; all of these are tracked in the same backlog on a per-team basis. We used to call all production issues bugs, though over time it's become more and more clear that this is not the case. Yes, some of these are due to defects in the software, though more often they are due to unforeseen use contexts, changes to behavior of external data APIs (the app is a sort of middleware), or volume that is outside of the design parameters.

            Because of these latter points, we now treat production issues as research spikes, and they are added to the current sprint as for us, responding to production trumps all other work, and you may start to see why so many folks have suggested Kanban for maintenance, because technically in Scrum, we can't just mess with the committed sprint backlog. Customers who want their apps to work as expected though tend not to care a whole lot how technically correct our Scrum implementation is :) Anyhow, so after the devs have dug into the issue a bit they can give an overview of what's going on. With that information we can decide if this is truly a bug or an emergent feature, what it's relative size is, and the PO can use this to decide the priority of fixing it now or adding a new item into the product backlog for future attention.

            Obviously, this situation requires a renegotiation of the sprint backlog, with previously-committed items falling out of the sprint. While this is a scrum anti-pattern of itself, to me the more important thing is the communication within our organization, that information is flowing into and out of the team, that there is alignment and agreement on priorities and current dev actions, and that we are maintaining a sustainable pace of development, and of course, that we are continuously improving the quality of our software and the value it delivers to our customers.

            Anyhow, I hope that helps a bit; I don't think I can give you much more info on our internals for a use case though you're welcome to contact me off-list if you'd like more specifics…

            Thanks,

            -kevin


            On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:

             

            Hi, Steve

            Thank you for your time replying. I kind of screwed myself up by choosing this topic when i have no actual experience in a real-life scrum project. Anyway,long story :D

            And concerning what you've brought up, that's the thing i'm interested in. And what i would also like to know is that how a PO prioritize the sprint backlog and maintenance backlog simultaneously.Are there any models to follow or universal guidelines? And what are the factors that might influence the priority of maintenance stories compared to original user stories? That would be the spot i could write something about. And do you by any chance know some projects that I might use as a case?

            Many Thanks for your time. And sorry for my lack of knowledge.

            Best wishes.

            --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
            >
            > Hi
            >
            > My first question is how come you are doing a masters in 'advanced' Scrum when you are still a rookie! But that's acedemia for you!
            >
            > The way I have implemented it has always been with developers that are also maintainers.
            >
            > They work 3 week Sprints on developement during which time maintenance requests come in and are added to a Maintenance Backlog (I even managed to get the users to write requests in User Story format for one implementation!).
            >
            > On the Monday of the fourth week all the relevant people gather for a maintenance Sprint planning workshop where the requests are prioritised, estimated and planned.
            >
            > The team work their way through the plan for the rest of the week and have a demo on the pm of the Friday; then they go back to development on the next Monday.
            >
            > This has had the effect that some low priority maintenance requests never get done; some increase in priority as time goes on.
            >
            > Of course 'showstopper' maintenance requests are dealt with immediately; the team allow for such possibilities in their development sprint planning but it happens very rarely.
            >
            > So that's one way. I have never seen a dedicated maintenance team.
            >
            > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@> wrote:
            > >
            > > Greetings
            > >
            > > My name is Xiaozhou Li, a student in University of Tampere in Finland. And i'm a total rookie in scrum development area. Recently, i've been working on my master thesis concerning adopting Scrum in software maintenance and relevant issues. And so far i have some general questions including:
            > >
            > > How do you feel about using scrum in software maintenance compared with traditional software maintenance process (personally)?
            > >
            > > In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?
            > >
            > > Are there any drawbacks that bothering you if any?
            > >
            > > What are the best practices you think would be concerning scrum in software maintenance?
            > >
            > > ......
            > >
            > > I would bring up more specific questions about it later on as i'm a bit stuck so far. Thanks a lot for your kind responses including all constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
            > >
            > > ps. feel free to contact me with any sort of ideas
            > > email: lixiaozhou725@
            > >
            >


            Kevin Callahan, CSP
            Scrum Master
            mobile: 207-691-2997
            AIM: kevmocal


          • Charles Bradley - Scrum Coach CSP CSM PSM
            Xiaozhou, I ve been following your question/thread. You mentioned this extra bit of your context. ... features added in, bug fixing, refactoring, new platform
            Message 5 of 21 , Oct 1, 2012
            View Source
            • 0 Attachment

              Xiaozhou,

              I've been following your question/thread.

              You mentioned this extra bit of your context.

              >> all kinds of development after the first release, including new features added in, bug fixing, refactoring, new platform adapting, etc. And what i was wondering is how to prioritize various stories to maximize the benefits for all stakeholders and whether this is based on only experience or there are some models to follow.

              For teams doing the things you mentioned, I've coached multiple teams that do a combination of the several activities just as you described.
               
              Firstly, I think Scrum can probably work for your context just fine, since there is much software development involved.  One important deciding point would be the time horizon for which your team's prioritization holds mostly true.  If your team's environment would not be too complex over a week long horizon, then I think Scrum would be a good fit.  If there is a lot of thrashing and complexity within a one week sprint, that is a different subject altogether.  I'll assume that is not the case.

              > how to prioritize various stories to
              maximize the benefits for all stakeholders

              To my knowledge, there is no way to maximize the benefits for *all* stakeholders, and I don't think that's relevant anyway.  The key, IMO, is to maximize the value delivered for the *organization as a whole*, based in large part on organizational goals.  The Scrum PO orders the product backlog based on many factors(value, risk, priority, dependencies, etc), all with the purpose of maximizing the value created by organizational goals. 

              There are some models for assessing value, discussed in chapters 9-11 of Agile Estimating and Planning by Cohn.  There may be more models or related info in Pichler's Agile Product Management with Scrum: Creating Products that Customers Love (I can't remember off hand if he talks about models or not, but it's still useful PO information).  I'm not aware of any specific models that take into account fixes vs. new features vs. new platorms, other than to consider their financial value as in the models above.

              If we're talking about one team here, then I would suggest that all kinds of changes to the system under development (regardless of the nature of the work -- new features, fixes, etc) be ordered in the same product backlog.  The main reason for this is so that the relative value of each of the product backlog items (PBI's) can be quickly compared against each other.

              >> In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?

              IMO, and in my ~15 years of software development experience, doing software maintenance(of the kind described in this thread)with Scrum delivers more value quicker, than any other method I've seen. 

              I think the main benefits over other strategies come from:
              1. One place to order/prioritize the work (Product Backlog) so that the most value is delivered the quickest.
                • Other Scrum principles support this as well:  Sprints, Sprint Reviews, Product Backlog grooming, Remaining work towards a milestone.
              2. One place to order/prioritize the work (Product Backlog) so that the Dev Team and organization has a simple view into the upcoming and current work.
                • Other Scrum principles support this as well:  Sprints, Sprint Reviews, Product Backlog grooming, Remaining work towards a milestone.
              3. One single person who is responsible for ordering the Product Backlog(the PO).
              4. The person responsible for ordering *and defining* the Product Backlog interacts with the team directly and often.
              5. Doing production support and new product development helps hold the Dev Team accountable for software quality(definition of done) and technical debt.
              6. Due to the unified view of work, the impacts of Scrum Team and Stakeholder decisions are much simpler to see (transparency), and much quicker visible.
              > > Are there any drawbacks that bothering you if any?

              A couple of the biggest challenges in this type of situation, no matter what strategy you use is:
              1. Being aware of team focus.  If your team is constantly changing focus, then productivity decreases dramatically.
              2. Getting the organization to build some consensus around what is the most valuable PBI's to work on.  This is often a very big challenge, and has more to do with organizational dysfunction, and less to do with Scrum or any other approach.  OTOH, Scrum, when done well, will tend to shine some transparency on the organizational dysfunction, and this can lead to further challenges.
              The only other thing you might consider a "drawback" is that Scrum, while fairly easy to learn, is difficult to master.  I'm assuming you've seen the "Scrum is like Chess" metaphor.  If not, you can read more about that here:
              http://kenschwaber.wordpress.com/2010/09/08/scrum-as-a-framework/

              -------
              Charles Bradley
              http://www.ScrumCrazy.com




              From: lixiaozhou <lixiaozhou@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Friday, September 28, 2012 6:16 PM
              Subject: [scrumdevelopment] Re: Does anyone have experience in adopting Scrum in Software Maintenance?

              Hi, Steve

              Thank you for your time replying. I kind of screwed myself up by choosing this topic when i have no actual experience in a real-life scrum project. Anyway,long story :D

              And concerning what you've brought up, that's the thing i'm interested in. And what i would also like to know is that how a PO prioritize the sprint backlog and maintenance backlog simultaneously.Are there any models to follow or universal guidelines? And what are the factors that might influence the priority of maintenance stories compared to original user stories? That would be the spot i could write something about. And do you by any chance know some projects that I might use as a case?

              Many Thanks for your time. And sorry for my lack of knowledge.

              Best wishes. 

              --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
              >
              > Hi
              >
              > My first question is how come you are doing a masters in 'advanced' Scrum when you are still a rookie!  But that's acedemia for you!
              >
              > The way I have implemented it has always been with developers that are also maintainers.
              >
              > They work 3 week Sprints on developement during which time maintenance requests come in and are added to a Maintenance Backlog (I even managed to get the users to write requests in User Story format for one implementation!).
              >
              > On the Monday of the fourth week all the relevant people gather for a maintenance Sprint planning workshop where the requests are prioritised, estimated and planned.
              >
              > The team work their way through the plan for the rest of the week and have a demo on the pm of the Friday; then they go back to development on the next Monday.
              >
              > This has had the effect that some low priority maintenance requests never get done; some increase in priority as time goes on.
              >
              > Of course 'showstopper' maintenance requests are dealt with immediately; the team allow for such possibilities in their development sprint planning but it happens very rarely.
              >
              > So that's one way.  I have never seen a dedicated maintenance team.
              >
              > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@> wrote:
              > >
              > > Greetings
              > >
              > > My name is Xiaozhou Li, a student in University of Tampere in Finland. And i'm a total rookie in scrum development area. Recently, i've been working on my master thesis concerning adopting Scrum in software maintenance and relevant issues. And so far i have some general questions including:
              > >
              > > How do you feel about using scrum in software maintenance compared with traditional software maintenance process (personally)?
              > >
              > > In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?
              > >
              > > Are there any drawbacks that bothering you if any?
              > >
              > > What are the best practices you think would be concerning scrum in software maintenance?
              > >
              > > ......
              > >
              > > I would bring up more specific questions about it later on as i'm a bit stuck so far. Thanks a lot for your kind responses including all constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
              > >
              > > ps. feel free to contact me with any sort of ideas
              > > email: lixiaozhou725@
              > >
              >




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

              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/



            • Charles Bradley - Scrum Coach CSP CSM PSM
              Good post, Kevin. What you described is a very similar to the approach the one I ve used several times myself for production support and bugs.  Whether it is
              Message 6 of 21 , Oct 3, 2012
              View Source
              • 0 Attachment
                Good post, Kevin.

                What you described is a very similar to the approach the one I've used several times myself for production support and bugs.  Whether it is true to Scrum or not, I'll leave that judgement to others.

                http://www.scrumcrazy.com/bugs
                 
                -------
                Charles Bradley
                http://www.ScrumCrazy.com




                From: Kevin Callahan <kcallahan@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Monday, October 1, 2012 8:42 AM
                Subject: Re: [scrumdevelopment] Re: Does anyone have experience in adopting Scrum in Software Maintenance?



                Hi Xiaozhou,

                Here's what the team I work with is doing these days; I would say we're an intermediate-level adoption and constantly striving to improve. We have several scrum teams working toward a web oriented architecture, meaning that teams write features required by other teams and then expose that functionality via external API calls. One of the pain points is the conflict between planned feature development and unplanned emergent work, a nice way to say production issues; all of these are tracked in the same backlog on a per-team basis. We used to call all production issues bugs, though over time it's become more and more clear that this is not the case. Yes, some of these are due to defects in the software, though more often they are due to unforeseen use contexts, changes to behavior of external data APIs (the app is a sort of middleware), or volume that is outside of the design parameters.

                Because of these latter points, we now treat production issues as research spikes, and they are added to the current sprint as for us, responding to production trumps all other work, and you may start to see why so many folks have suggested Kanban for maintenance, because technically in Scrum, we can't just mess with the committed sprint backlog. Customers who want their apps to work as expected though tend not to care a whole lot how technically correct our Scrum implementation is :) Anyhow, so after the devs have dug into the issue a bit they can give an overview of what's going on. With that information we can decide if this is truly a bug or an emergent feature, what it's relative size is, and the PO can use this to decide the priority of fixing it now or adding a new item into the product backlog for future attention.

                Obviously, this situation requires a renegotiation of the sprint backlog, with previously-committed items falling out of the sprint. While this is a scrum anti-pattern of itself, to me the more important thing is the communication within our organization, that information is flowing into and out of the team, that there is alignment and agreement on priorities and current dev actions, and that we are maintaining a sustainable pace of development, and of course, that we are continuously improving the quality of our software and the value it delivers to our customers.

                Anyhow, I hope that helps a bit; I don't think I can give you much more info on our internals for a use case though you're welcome to contact me off-list if you'd like more specifics…

                Thanks,

                -kevin


                On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:

                 
                Hi, Steve

                Thank you for your time replying. I kind of screwed myself up by choosing this topic when i have no actual experience in a real-life scrum project. Anyway,long story :D

                And concerning what you've brought up, that's the thing i'm interested in. And what i would also like to know is that how a PO prioritize the sprint backlog and maintenance backlog simultaneously.Are there any models to follow or universal guidelines? And what are the factors that might influence the priority of maintenance stories compared to original user stories? That would be the spot i could write something about. And do you by any chance know some projects that I might use as a case?

                Many Thanks for your time. And sorry for my lack of knowledge.

                Best wishes.

                --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
                >
                > Hi
                >
                > My first question is how come you are doing a masters in 'advanced' Scrum when you are still a rookie! But that's acedemia for you!
                >
                > The way I have implemented it has always been with developers that are also maintainers.
                >
                > They work 3 week Sprints on developement during which time maintenance requests come in and are added to a Maintenance Backlog (I even managed to get the users to write requests in User Story format for one implementation!).
                >
                > On the Monday of the fourth week all the relevant people gather for a maintenance Sprint planning workshop where the requests are prioritised, estimated and planned.
                >
                > The team work their way through the plan for the rest of the week and have a demo on the pm of the Friday; then they go back to development on the next Monday.
                >
                > This has had the effect that some low priority maintenance requests never get done; some increase in priority as time goes on.
                >
                > Of course 'showstopper' maintenance requests are dealt with immediately; the team allow for such possibilities in their development sprint planning but it happens very rarely.
                >
                > So that's one way. I have never seen a dedicated maintenance team.
                >
                > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@> wrote:
                > >
                > > Greetings
                > >
                > > My name is Xiaozhou Li, a student in University of Tampere in Finland. And i'm a total rookie in scrum development area. Recently, i've been working on my master thesis concerning adopting Scrum in software maintenance and relevant issues. And so far i have some general questions including:
                > >
                > > How do you feel about using scrum in software maintenance compared with traditional software maintenance process (personally)?
                > >
                > > In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?
                > >
                > > Are there any drawbacks that bothering you if any?
                > >
                > > What are the best practices you think would be concerning scrum in software maintenance?
                > >
                > > ......
                > >
                > > I would bring up more specific questions about it later on as i'm a bit stuck so far. Thanks a lot for your kind responses including all constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
                > >
                > > ps. feel free to contact me with any sort of ideas
                > > email: lixiaozhou725@
                > >
                >


                Kevin Callahan, CSP
                Scrum Master
                mobile: 207-691-2997
                AIM: kevmocal






              • Charles Bradley - Scrum Coach CSP CSM PSM
                ... Should read ...   ... Charles Bradley http://www.ScrumCrazy.com ... Correction: Whether it is true to Scrum or not, I ll leave that judgement to others.
                Message 7 of 21 , Oct 3, 2012
                View Source
                • 0 Attachment
                  Correction:
                  > Whether it is true to Scrum or not, I'll leave that judgement to others.
                  Should read
                  > Whether it is true to Scrum or not, I'll leave that judgement to others, but I reserve the right to discuss/debate the judgement by others.  :-)
                   
                  -------
                  Charles Bradley
                  http://www.ScrumCrazy.com




                  From: Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...>
                  To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                  Sent: Wednesday, October 3, 2012 5:59 PM
                  Subject: Re: [scrumdevelopment] Re: Does anyone have experience in adopting Scrum in Software Maintenance?



                  Good post, Kevin.

                  What you described is a very similar to the approach the one I've used several times myself for production support and bugs.  Whether it is true to Scrum or not, I'll leave that judgement to others.

                  http://www.scrumcrazy.com/bugs
                   
                  -------
                  Charles Bradley
                  http://www.ScrumCrazy.com




                  From: Kevin Callahan <kcallahan@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Monday, October 1, 2012 8:42 AM
                  Subject: Re: [scrumdevelopment] Re: Does anyone have experience in adopting Scrum in Software Maintenance?



                  Hi Xiaozhou,

                  Here's what the team I work with is doing these days; I would say we're an intermediate-level adoption and constantly striving to improve. We have several scrum teams working toward a web oriented architecture, meaning that teams write features required by other teams and then expose that functionality via external API calls. One of the pain points is the conflict between planned feature development and unplanned emergent work, a nice way to say production issues; all of these are tracked in the same backlog on a per-team basis. We used to call all production issues bugs, though over time it's become more and more clear that this is not the case. Yes, some of these are due to defects in the software, though more often they are due to unforeseen use contexts, changes to behavior of external data APIs (the app is a sort of middleware), or volume that is outside of the design parameters.

                  Because of these latter points, we now treat production issues as research spikes, and they are added to the current sprint as for us, responding to production trumps all other work, and you may start to see why so many folks have suggested Kanban for maintenance, because technically in Scrum, we can't just mess with the committed sprint backlog. Customers who want their apps to work as expected though tend not to care a whole lot how technically correct our Scrum implementation is :) Anyhow, so after the devs have dug into the issue a bit they can give an overview of what's going on. With that information we can decide if this is truly a bug or an emergent feature, what it's relative size is, and the PO can use this to decide the priority of fixing it now or adding a new item into the product backlog for future attention.

                  Obviously, this situation requires a renegotiation of the sprint backlog, with previously-committed items falling out of the sprint. While this is a scrum anti-pattern of itself, to me the more important thing is the communication within our organization, that information is flowing into and out of the team, that there is alignment and agreement on priorities and current dev actions, and that we are maintaining a sustainable pace of development, and of course, that we are continuously improving the quality of our software and the value it delivers to our customers.

                  Anyhow, I hope that helps a bit; I don't think I can give you much more info on our internals for a use case though you're welcome to contact me off-list if you'd like more specifics…

                  Thanks,

                  -kevin


                  On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:

                   
                  Hi, Steve

                  Thank you for your time replying. I kind of screwed myself up by choosing this topic when i have no actual experience in a real-life scrum project. Anyway,long story :D

                  And concerning what you've brought up, that's the thing i'm interested in. And what i would also like to know is that how a PO prioritize the sprint backlog and maintenance backlog simultaneously.Are there any models to follow or universal guidelines? And what are the factors that might influence the priority of maintenance stories compared to original user stories? That would be the spot i could write something about. And do you by any chance know some projects that I might use as a case?

                  Many Thanks for your time. And sorry for my lack of knowledge.

                  Best wishes.

                  --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
                  >
                  > Hi
                  >
                  > My first question is how come you are doing a masters in 'advanced' Scrum when you are still a rookie! But that's acedemia for you!
                  >
                  > The way I have implemented it has always been with developers that are also maintainers.
                  >
                  > They work 3 week Sprints on developement during which time maintenance requests come in and are added to a Maintenance Backlog (I even managed to get the users to write requests in User Story format for one implementation!).
                  >
                  > On the Monday of the fourth week all the relevant people gather for a maintenance Sprint planning workshop where the requests are prioritised, estimated and planned.
                  >
                  > The team work their way through the plan for the rest of the week and have a demo on the pm of the Friday; then they go back to development on the next Monday.
                  >
                  > This has had the effect that some low priority maintenance requests never get done; some increase in priority as time goes on.
                  >
                  > Of course 'showstopper' maintenance requests are dealt with immediately; the team allow for such possibilities in their development sprint planning but it happens very rarely.
                  >
                  > So that's one way. I have never seen a dedicated maintenance team.
                  >
                  > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@> wrote:
                  > >
                  > > Greetings
                  > >
                  > > My name is Xiaozhou Li, a student in University of Tampere in Finland. And i'm a total rookie in scrum development area. Recently, i've been working on my master thesis concerning adopting Scrum in software maintenance and relevant issues. And so far i have some general questions including:
                  > >
                  > > How do you feel about using scrum in software maintenance compared with traditional software maintenance process (personally)?
                  > >
                  > > In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?
                  > >
                  > > Are there any drawbacks that bothering you if any?
                  > >
                  > > What are the best practices you think would be concerning scrum in software maintenance?
                  > >
                  > > ......
                  > >
                  > > I would bring up more specific questions about it later on as i'm a bit stuck so far. Thanks a lot for your kind responses including all constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
                  > >
                  > > ps. feel free to contact me with any sort of ideas
                  > > email: lixiaozhou725@
                  > >
                  >


                  Kevin Callahan, CSP
                  Scrum Master
                  mobile: 207-691-2997
                  AIM: kevmocal










                • Cass Dalton
                  Kevin, With your backlog consisting of a significant percentage of maintenance type stories, is there any reason that your organization wouldn t also move to
                  Message 8 of 21 , Oct 3, 2012
                  View Source
                  • 0 Attachment

                    Kevin,
                    With your backlog consisting of a significant percentage of maintenance type stories, is there any reason that your organization wouldn't also move to Kanban?  Or do you feel that the maintenance type work is resulting from systemic issues in your org/process that you'd like to understand and address before making that type of change?

                    On Oct 3, 2012 7:51 PM, "Kevin Callahan" <kcallahan@...> wrote:
                     

                    Hi Xiaozhou,

                    Here's what the team I work with is doing these days; I would say we're an intermediate-level adoption and constantly striving to improve. We have several scrum teams working toward a web oriented architecture, meaning that teams write features required by other teams and then expose that functionality via external API calls. One of the pain points is the conflict between planned feature development and unplanned emergent work, a nice way to say production issues; all of these are tracked in the same backlog on a per-team basis. We used to call all production issues bugs, though over time it's become more and more clear that this is not the case. Yes, some of these are due to defects in the software, though more often they are due to unforeseen use contexts, changes to behavior of external data APIs (the app is a sort of middleware), or volume that is outside of the design parameters.

                    Because of these latter points, we now treat production issues as research spikes, and they are added to the current sprint as for us, responding to production trumps all other work, and you may start to see why so many folks have suggested Kanban for maintenance, because technically in Scrum, we can't just mess with the committed sprint backlog. Customers who want their apps to work as expected though tend not to care a whole lot how technically correct our Scrum implementation is :) Anyhow, so after the devs have dug into the issue a bit they can give an overview of what's going on. With that information we can decide if this is truly a bug or an emergent feature, what it's relative size is, and the PO can use this to decide the priority of fixing it now or adding a new item into the product backlog for future attention.

                    Obviously, this situation requires a renegotiation of the sprint backlog, with previously-committed items falling out of the sprint. While this is a scrum anti-pattern of itself, to me the more important thing is the communication within our organization, that information is flowing into and out of the team, that there is alignment and agreement on priorities and current dev actions, and that we are maintaining a sustainable pace of development, and of course, that we are continuously improving the quality of our software and the value it delivers to our customers.

                    Anyhow, I hope that helps a bit; I don't think I can give you much more info on our internals for a use case though you're welcome to contact me off-list if you'd like more specifics…

                    Thanks,

                    -kevin


                    On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:

                     

                    Hi, Steve

                    Thank you for your time replying. I kind of screwed myself up by choosing this topic when i have no actual experience in a real-life scrum project. Anyway,long story :D

                    And concerning what you've brought up, that's the thing i'm interested in. And what i would also like to know is that how a PO prioritize the sprint backlog and maintenance backlog simultaneously.Are there any models to follow or universal guidelines? And what are the factors that might influence the priority of maintenance stories compared to original user stories? That would be the spot i could write something about. And do you by any chance know some projects that I might use as a case?

                    Many Thanks for your time. And sorry for my lack of knowledge.

                    Best wishes.

                    --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
                    >
                    > Hi
                    >
                    > My first question is how come you are doing a masters in 'advanced' Scrum when you are still a rookie! But that's acedemia for you!
                    >
                    > The way I have implemented it has always been with developers that are also maintainers.
                    >
                    > They work 3 week Sprints on developement during which time maintenance requests come in and are added to a Maintenance Backlog (I even managed to get the users to write requests in User Story format for one implementation!).
                    >
                    > On the Monday of the fourth week all the relevant people gather for a maintenance Sprint planning workshop where the requests are prioritised, estimated and planned.
                    >
                    > The team work their way through the plan for the rest of the week and have a demo on the pm of the Friday; then they go back to development on the next Monday.
                    >
                    > This has had the effect that some low priority maintenance requests never get done; some increase in priority as time goes on.
                    >
                    > Of course 'showstopper' maintenance requests are dealt with immediately; the team allow for such possibilities in their development sprint planning but it happens very rarely.
                    >
                    > So that's one way. I have never seen a dedicated maintenance team.
                    >
                    > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@> wrote:
                    > >
                    > > Greetings
                    > >
                    > > My name is Xiaozhou Li, a student in University of Tampere in Finland. And i'm a total rookie in scrum development area. Recently, i've been working on my master thesis concerning adopting Scrum in software maintenance and relevant issues. And so far i have some general questions including:
                    > >
                    > > How do you feel about using scrum in software maintenance compared with traditional software maintenance process (personally)?
                    > >
                    > > In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?
                    > >
                    > > Are there any drawbacks that bothering you if any?
                    > >
                    > > What are the best practices you think would be concerning scrum in software maintenance?
                    > >
                    > > ......
                    > >
                    > > I would bring up more specific questions about it later on as i'm a bit stuck so far. Thanks a lot for your kind responses including all constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
                    > >
                    > > ps. feel free to contact me with any sort of ideas
                    > > email: lixiaozhou725@
                    > >
                    >


                    Kevin Callahan, CSP
                    Scrum Master
                    mobile: 207-691-2997
                    AIM: kevmocal


                  • Charles Bradley - Scrum Coach CSP CSM PSM
                    Cass, How do you define maintenance type stories ? My guess is if I asked 10 different developers at 10 different orgs, I d get wildly different answers. So,
                    Message 9 of 21 , Oct 4, 2012
                    View Source
                    • 0 Attachment
                      Cass,

                      How do you define "maintenance type stories"?

                      My guess is if I asked 10 different developers at 10 different orgs, I'd get wildly different answers.

                      So, how do you define that?
                       
                      -------
                      Charles Bradley
                      http://www.ScrumCrazy.com




                      From: Cass Dalton <cassdalton73@...>
                      To: scrumdevelopment@yahoogroups.com
                      Sent: Wednesday, October 3, 2012 6:26 PM
                      Subject: Re: [scrumdevelopment] Re: Does anyone have experience in adopting Scrum in Software Maintenance?



                      Kevin,
                      With your backlog consisting of a significant percentage of maintenance type stories, is there any reason that your organization wouldn't also move to Kanban?  Or do you feel that the maintenance type work is resulting from systemic issues in your org/process that you'd like to understand and address before making that type of change?
                      On Oct 3, 2012 7:51 PM, "Kevin Callahan" <kcallahan@...> wrote:
                       
                      Hi Xiaozhou,

                      Here's what the team I work with is doing these days; I would say we're an intermediate-level adoption and constantly striving to improve. We have several scrum teams working toward a web oriented architecture, meaning that teams write features required by other teams and then expose that functionality via external API calls. One of the pain points is the conflict between planned feature development and unplanned emergent work, a nice way to say production issues; all of these are tracked in the same backlog on a per-team basis. We used to call all production issues bugs, though over time it's become more and more clear that this is not the case. Yes, some of these are due to defects in the software, though more often they are due to unforeseen use contexts, changes to behavior of external data APIs (the app is a sort of middleware), or volume that is outside of the design parameters.

                      Because of these latter points, we now treat production issues as research spikes, and they are added to the current sprint as for us, responding to production trumps all other work, and you may start to see why so many folks have suggested Kanban for maintenance, because technically in Scrum, we can't just mess with the committed sprint backlog. Customers who want their apps to work as expected though tend not to care a whole lot how technically correct our Scrum implementation is :) Anyhow, so after the devs have dug into the issue a bit they can give an overview of what's going on. With that information we can decide if this is truly a bug or an emergent feature, what it's relative size is, and the PO can use this to decide the priority of fixing it now or adding a new item into the product backlog for future attention.

                      Obviously, this situation requires a renegotiation of the sprint backlog, with previously-committed items falling out of the sprint. While this is a scrum anti-pattern of itself, to me the more important thing is the communication within our organization, that information is flowing into and out of the team, that there is alignment and agreement on priorities and current dev actions, and that we are maintaining a sustainable pace of development, and of course, that we are continuously improving the quality of our software and the value it delivers to our customers.

                      Anyhow, I hope that helps a bit; I don't think I can give you much more info on our internals for a use case though you're welcome to contact me off-list if you'd like more specifics…

                      Thanks,

                      -kevin


                      On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:

                       
                      Hi, Steve

                      Thank you for your time replying. I kind of screwed myself up by choosing this topic when i have no actual experience in a real-life scrum project. Anyway,long story :D

                      And concerning what you've brought up, that's the thing i'm interested in. And what i would also like to know is that how a PO prioritize the sprint backlog and maintenance backlog simultaneously.Are there any models to follow or universal guidelines? And what are the factors that might influence the priority of maintenance stories compared to original user stories? That would be the spot i could write something about. And do you by any chance know some projects that I might use as a case?

                      Many Thanks for your time. And sorry for my lack of knowledge.

                      Best wishes.

                      --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
                      >
                      > Hi
                      >
                      > My first question is how come you are doing a masters in 'advanced' Scrum when you are still a rookie! But that's acedemia for you!
                      >
                      > The way I have implemented it has always been with developers that are also maintainers.
                      >
                      > They work 3 week Sprints on developement during which time maintenance requests come in and are added to a Maintenance Backlog (I even managed to get the users to write requests in User Story format for one implementation!).
                      >
                      > On the Monday of the fourth week all the relevant people gather for a maintenance Sprint planning workshop where the requests are prioritised, estimated and planned.
                      >
                      > The team work their way through the plan for the rest of the week and have a demo on the pm of the Friday; then they go back to development on the next Monday.
                      >
                      > This has had the effect that some low priority maintenance requests never get done; some increase in priority as time goes on.
                      >
                      > Of course 'showstopper' maintenance requests are dealt with immediately; the team allow for such possibilities in their development sprint planning but it happens very rarely.
                      >
                      > So that's one way. I have never seen a dedicated maintenance team.
                      >
                      > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@> wrote:
                      > >
                      > > Greetings
                      > >
                      > > My name is Xiaozhou Li, a student in University of Tampere in Finland. And i'm a total rookie in scrum development area. Recently, i've been working on my master thesis concerning adopting Scrum in software maintenance and relevant issues. And so far i have some general questions including:
                      > >
                      > > How do you feel about using scrum in software maintenance compared with traditional software maintenance process (personally)?
                      > >
                      > > In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?
                      > >
                      > > Are there any drawbacks that bothering you if any?
                      > >
                      > > What are the best practices you think would be concerning scrum in software maintenance?
                      > >
                      > > ......
                      > >
                      > > I would bring up more specific questions about it later on as i'm a bit stuck so far. Thanks a lot for your kind responses including all constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
                      > >
                      > > ps. feel free to contact me with any sort of ideas
                      > > email: lixiaozhou725@
                      > >
                      >


                      Kevin Callahan, CSP
                      Scrum Master
                      mobile: 207-691-2997
                      AIM: kevmocal






                    • Adam Sroka
                      I m partial to the Pragmatic Programmers definition. All development is maintenance. It s particularly true if you are aggressive about refactoring. On Thu,
                      Message 10 of 21 , Oct 4, 2012
                      View Source
                      • 0 Attachment
                        I'm partial to the Pragmatic Programmers definition. All development is maintenance. It's particularly true if you are aggressive about refactoring. 

                        On Thu, Oct 4, 2012 at 7:36 AM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                         

                        Cass,

                        How do you define "maintenance type stories"?

                        My guess is if I asked 10 different developers at 10 different orgs, I'd get wildly different answers.

                        So, how do you define that?

                         
                        -------
                        Charles Bradley
                        http://www.ScrumCrazy.com




                        From: Cass Dalton <cassdalton73@...>
                        To: scrumdevelopment@yahoogroups.com
                        Sent: Wednesday, October 3, 2012 6:26 PM

                        Subject: Re: [scrumdevelopment] Re: Does anyone have experience in adopting Scrum in Software Maintenance?



                        Kevin,
                        With your backlog consisting of a significant percentage of maintenance type stories, is there any reason that your organization wouldn't also move to Kanban?  Or do you feel that the maintenance type work is resulting from systemic issues in your org/process that you'd like to understand and address before making that type of change?
                        On Oct 3, 2012 7:51 PM, "Kevin Callahan" <kcallahan@...> wrote:
                         
                        Hi Xiaozhou,

                        Here's what the team I work with is doing these days; I would say we're an intermediate-level adoption and constantly striving to improve. We have several scrum teams working toward a web oriented architecture, meaning that teams write features required by other teams and then expose that functionality via external API calls. One of the pain points is the conflict between planned feature development and unplanned emergent work, a nice way to say production issues; all of these are tracked in the same backlog on a per-team basis. We used to call all production issues bugs, though over time it's become more and more clear that this is not the case. Yes, some of these are due to defects in the software, though more often they are due to unforeseen use contexts, changes to behavior of external data APIs (the app is a sort of middleware), or volume that is outside of the design parameters.

                        Because of these latter points, we now treat production issues as research spikes, and they are added to the current sprint as for us, responding to production trumps all other work, and you may start to see why so many folks have suggested Kanban for maintenance, because technically in Scrum, we can't just mess with the committed sprint backlog. Customers who want their apps to work as expected though tend not to care a whole lot how technically correct our Scrum implementation is :) Anyhow, so after the devs have dug into the issue a bit they can give an overview of what's going on. With that information we can decide if this is truly a bug or an emergent feature, what it's relative size is, and the PO can use this to decide the priority of fixing it now or adding a new item into the product backlog for future attention.

                        Obviously, this situation requires a renegotiation of the sprint backlog, with previously-committed items falling out of the sprint. While this is a scrum anti-pattern of itself, to me the more important thing is the communication within our organization, that information is flowing into and out of the team, that there is alignment and agreement on priorities and current dev actions, and that we are maintaining a sustainable pace of development, and of course, that we are continuously improving the quality of our software and the value it delivers to our customers.

                        Anyhow, I hope that helps a bit; I don't think I can give you much more info on our internals for a use case though you're welcome to contact me off-list if you'd like more specifics…

                        Thanks,

                        -kevin


                        On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:

                         
                        Hi, Steve

                        Thank you for your time replying. I kind of screwed myself up by choosing this topic when i have no actual experience in a real-life scrum project. Anyway,long story :D

                        And concerning what you've brought up, that's the thing i'm interested in. And what i would also like to know is that how a PO prioritize the sprint backlog and maintenance backlog simultaneously.Are there any models to follow or universal guidelines? And what are the factors that might influence the priority of maintenance stories compared to original user stories? That would be the spot i could write something about. And do you by any chance know some projects that I might use as a case?

                        Many Thanks for your time. And sorry for my lack of knowledge.

                        Best wishes.

                        --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
                        >
                        > Hi
                        >
                        > My first question is how come you are doing a masters in 'advanced' Scrum when you are still a rookie! But that's acedemia for you!
                        >
                        > The way I have implemented it has always been with developers that are also maintainers.
                        >
                        > They work 3 week Sprints on developement during which time maintenance requests come in and are added to a Maintenance Backlog (I even managed to get the users to write requests in User Story format for one implementation!).
                        >
                        > On the Monday of the fourth week all the relevant people gather for a maintenance Sprint planning workshop where the requests are prioritised, estimated and planned.
                        >
                        > The team work their way through the plan for the rest of the week and have a demo on the pm of the Friday; then they go back to development on the next Monday.
                        >
                        > This has had the effect that some low priority maintenance requests never get done; some increase in priority as time goes on.
                        >
                        > Of course 'showstopper' maintenance requests are dealt with immediately; the team allow for such possibilities in their development sprint planning but it happens very rarely.
                        >
                        > So that's one way. I have never seen a dedicated maintenance team.
                        >
                        > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@> wrote:
                        > >
                        > > Greetings
                        > >
                        > > My name is Xiaozhou Li, a student in University of Tampere in Finland. And i'm a total rookie in scrum development area. Recently, i've been working on my master thesis concerning adopting Scrum in software maintenance and relevant issues. And so far i have some general questions including:
                        > >
                        > > How do you feel about using scrum in software maintenance compared with traditional software maintenance process (personally)?
                        > >
                        > > In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?
                        > >
                        > > Are there any drawbacks that bothering you if any?
                        > >
                        > > What are the best practices you think would be concerning scrum in software maintenance?
                        > >
                        > > ......
                        > >
                        > > I would bring up more specific questions about it later on as i'm a bit stuck so far. Thanks a lot for your kind responses including all constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
                        > >
                        > > ps. feel free to contact me with any sort of ideas
                        > > email: lixiaozhou725@
                        > >
                        >


                        Kevin Callahan, CSP
                        Scrum Master
                        mobile: 207-691-2997
                        AIM: kevmocal







                      • Kevin Callahan
                        Hi Cass, ... It s certainly been discussed, though we value the stability granted through scrum s sprint/timebox structure, particularly since we are a nearly
                        Message 11 of 21 , Oct 4, 2012
                        View Source
                        • 0 Attachment
                          Hi Cass,

                          > With your backlog consisting of a significant percentage of maintenance type stories, is there any reason that your organization wouldn't also move to Kanban?
                          >

                          It's certainly been discussed, though we value the stability granted through scrum's sprint/timebox structure, particularly since we are a nearly completely distributed organization. All of us are in the US, though spread out pretty good, so we miss out a lot on the benefit and gains of being able to ask a question across the room, huddle around a whiteboard, etc. Add to that a high degree of inter-team dependencies and things start to get more interesting and benefit from structured over on-demand planning, development, and inspection/adaptation. We have eliminated (masked?) a lot of pain by syncing up the teams' schedules within a day or so. Of course more than 4 or 5 teams and this latter approach breaks down, well, a lot of things break down at that scale and require a new approach. So yes, as you suggest there are some inefficiencies, though we feel that overall where we are it's more valuable to the enterprise to stick with scrum for now. We do continue to inspect and adapt this, and there are places in the org where we're implementing kanban boards to make visible WIP and bottlenecks both within and between teams.

                          > Or do you feel that the maintenance type work is resulting from systemic issues in your org/process that you'd like to understand and address before making that type of change?
                          >

                          Of course :) As long as our devs are also production support, there will be some degree of interrupt-driven work. Though I agree it is a smell of some deeper issues. For example some of the scalability issues we're working through is a weakness due to a sort of evolution of patches, of over and over putting a simple solution in place for a complex problem even though it's known (or suspected) to be imperfect in ways that could hurt down the road. Simplicity is good when it lowers costs and increases revenue; it gets a little tricker when the deeper costs begin to emerge and it's clear that collectively, we've let some things slide that we probably shouldn't have; hindsight is, of course, always perfect and being able to more clearly perceive what to let go and what to dig in on and fix is tough. I've started coaching to this point, and attempting to shift mindsets away from a more reactive patch approach toward designing and building more robust systems from the get go even if it takes more effort and thus expense (the Oz Principle at work, really). This is, of course, a tricky balance because we don't want to be architecting the end-all perfect system, just the one that maximizes quality and performs enough to get it out the door and generate value. It's a bit of a juggling act for sure, though at this point I think we're too far into the territory of blaming external APIs for sucking (which they absolutely do) rather than acknowledging that the engineering problems are a bit tricky to solve and seeking a higher level of innovation. Then again, it's not like we're writing software to fly space craft, airplanes, or planetary exploration robots; there are much, much more difficult problems in the software universe that have been solved...

                          Additionally, we've identified some solid paths toward improvement of our releases, which historically tend to be pain points; some of these are process-related milestones counting back from the release date that will give better early warning that things are slipping. Again this is a patch, a reactive band-aid that does little to solve the problem though enables us to better detect it. More importantly though, is *why* they're slipping, which gets into much more interesting conversations about how the teams are estimating and committing to work, how production issues (often resulting from lack of alignment, poorly-planned work, etc) are pushing the schedule out, and how user stories and acceptance criteria are being too broadly written that either create pockets for unknowns and risk to hide in, or strive to decompose proposed work into the smallest independent chunks to minimize the effect of one piece hanging up grinding the whole feature development to a halt; again it's a balancing act driven by productive communication and alignment. We're investing heavily in learning about the latter (among other improvements in engineering practice and integration of test roles into the dev team), and it's really starting to pay off as all quarters of engineering step up their game; pretty exciting, really.

                          Anyhow, hope that's helpful; good questions for sure!!!

                          -kevin



                          On Oct 3, 2012, at 8:26 PM, Cass Dalton wrote:

                          >
                          > Kevin,
                          > With your backlog consisting of a significant percentage of maintenance type stories, is there any reason that your organization wouldn't also move to Kanban? Or do you feel that the maintenance type work is resulting from systemic issues in your org/process that you'd like to understand and address before making that type of change?
                          >
                          > On Oct 3, 2012 7:51 PM, "Kevin Callahan" <kcallahan@...> wrote:
                          >
                          >
                          > Hi Xiaozhou,
                          >
                          > Here's what the team I work with is doing these days; I would say we're an intermediate-level adoption and constantly striving to improve. We have several scrum teams working toward a web oriented architecture, meaning that teams write features required by other teams and then expose that functionality via external API calls. One of the pain points is the conflict between planned feature development and unplanned emergent work, a nice way to say production issues; all of these are tracked in the same backlog on a per-team basis. We used to call all production issues bugs, though over time it's become more and more clear that this is not the case. Yes, some of these are due to defects in the software, though more often they are due to unforeseen use contexts, changes to behavior of external data APIs (the app is a sort of middleware), or volume that is outside of the design parameters.
                          >
                          > Because of these latter points, we now treat production issues as research spikes, and they are added to the current sprint as for us, responding to production trumps all other work, and you may start to see why so many folks have suggested Kanban for maintenance, because technically in Scrum, we can't just mess with the committed sprint backlog. Customers who want their apps to work as expected though tend not to care a whole lot how technically correct our Scrum implementation is :) Anyhow, so after the devs have dug into the issue a bit they can give an overview of what's going on. With that information we can decide if this is truly a bug or an emergent feature, what it's relative size is, and the PO can use this to decide the priority of fixing it now or adding a new item into the product backlog for future attention.
                          >
                          > Obviously, this situation requires a renegotiation of the sprint backlog, with previously-committed items falling out of the sprint. While this is a scrum anti-pattern of itself, to me the more important thing is the communication within our organization, that information is flowing into and out of the team, that there is alignment and agreement on priorities and current dev actions, and that we are maintaining a sustainable pace of development, and of course, that we are continuously improving the quality of our software and the value it delivers to our customers.
                          >
                          > Anyhow, I hope that helps a bit; I don't think I can give you much more info on our internals for a use case though you're welcome to contact me off-list if you'd like more specifics…
                          >
                          > Thanks,
                          >
                          > -kevin
                          >
                          >
                          > On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:
                          >
                          >>
                          >> Hi, Steve
                          >>
                          >> Thank you for your time replying. I kind of screwed myself up by choosing this topic when i have no actual experience in a real-life scrum project. Anyway,long story :D
                          >>
                          >> And concerning what you've brought up, that's the thing i'm interested in. And what i would also like to know is that how a PO prioritize the sprint backlog and maintenance backlog simultaneously.Are there any models to follow or universal guidelines? And what are the factors that might influence the priority of maintenance stories compared to original user stories? That would be the spot i could write something about. And do you by any chance know some projects that I might use as a case?
                          >>
                          >> Many Thanks for your time. And sorry for my lack of knowledge.
                          >>
                          >> Best wishes.
                          >>
                          >> --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
                          >> >
                          >> > Hi
                          >> >
                          >> > My first question is how come you are doing a masters in 'advanced' Scrum when you are still a rookie! But that's acedemia for you!
                          >> >
                          >> > The way I have implemented it has always been with developers that are also maintainers.
                          >> >
                          >> > They work 3 week Sprints on developement during which time maintenance requests come in and are added to a Maintenance Backlog (I even managed to get the users to write requests in User Story format for one implementation!).
                          >> >
                          >> > On the Monday of the fourth week all the relevant people gather for a maintenance Sprint planning workshop where the requests are prioritised, estimated and planned.
                          >> >
                          >> > The team work their way through the plan for the rest of the week and have a demo on the pm of the Friday; then they go back to development on the next Monday.
                          >> >
                          >> > This has had the effect that some low priority maintenance requests never get done; some increase in priority as time goes on.
                          >> >
                          >> > Of course 'showstopper' maintenance requests are dealt with immediately; the team allow for such possibilities in their development sprint planning but it happens very rarely.
                          >> >
                          >> > So that's one way. I have never seen a dedicated maintenance team.
                          >> >
                          >> > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@> wrote:
                          >> > >
                          >> > > Greetings
                          >> > >
                          >> > > My name is Xiaozhou Li, a student in University of Tampere in Finland. And i'm a total rookie in scrum development area. Recently, i've been working on my master thesis concerning adopting Scrum in software maintenance and relevant issues. And so far i have some general questions including:
                          >> > >
                          >> > > How do you feel about using scrum in software maintenance compared with traditional software maintenance process (personally)?
                          >> > >
                          >> > > In which way do you think it's more efficient and profitable (if you indeed think it's efficient and profitable)?
                          >> > >
                          >> > > Are there any drawbacks that bothering you if any?
                          >> > >
                          >> > > What are the best practices you think would be concerning scrum in software maintenance?
                          >> > >
                          >> > > ......
                          >> > >
                          >> > > I would bring up more specific questions about it later on as i'm a bit stuck so far. Thanks a lot for your kind responses including all constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
                          >> > >
                          >> > > ps. feel free to contact me with any sort of ideas
                          >> > > email: lixiaozhou725@
                          >> > >
                          >> >
                          >>
                          >
                          > Kevin Callahan, CSP
                          > Scrum Master
                          > mobile: 207-691-2997
                          > AIM: kevmocal
                          > email: kcallahan@...
                          >
                          >
                          >
                          >
                          >
                          >

                          Kevin Callahan, CSP
                          Scrum Master
                          mobile: 207-691-2997
                          AIM: kevmocal
                          email: kcallahan@...
                        • woynam
                          That s funny. I take the complete opposite viewpoint: There is *no* such thing as software maintenance. The term was obviously coined by someone in the
                          Message 12 of 21 , Oct 5, 2012
                          View Source
                          • 0 Attachment
                            That's funny. I take the complete opposite viewpoint: There is *no* such thing as software maintenance. The term was obviously coined by someone in the Accounting Department who didn't understand software, and was trying to figure out how to depreciate the costs associated with it.

                            Unlike a building's roof, a furnace, or an automobile, software does not wear out. It has *no* moving parts. Given a piece of software and a piece of hardware, it will continue to function as built indefinitely.

                            Every change to a piece of software is made to accomplish some *new* feature.

                            Do you want you software to run under Windows 7, when it was not designed for it? Well, that's a *new* feature. It's not "maintenance".

                            Mark


                            --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                            >
                            > I'm partial to the Pragmatic Programmers definition. All development is
                            > maintenance. It's particularly true if you are aggressive about
                            > refactoring.
                            >
                            > On Thu, Oct 4, 2012 at 7:36 AM, Charles Bradley - Scrum Coach CSP CSM PSM I
                            > <chuck-lists2@...> wrote:
                            >
                            > > **
                            > >
                            > >
                            > > Cass,
                            > >
                            > > How do you define "maintenance type stories"?
                            > >
                            > > My guess is if I asked 10 different developers at 10 different orgs, I'd
                            > > get wildly different answers.
                            > >
                            > > So, how do you define that?
                            > >
                            > >
                            > > -------
                            > > Charles Bradley
                            > > http://www.ScrumCrazy.com <http://www.scrumcrazy.com/>
                            > >
                            > >
                            > > ------------------------------
                            > > *From:* Cass Dalton <cassdalton73@...>
                            > > *To:* scrumdevelopment@yahoogroups.com
                            > > *Sent:* Wednesday, October 3, 2012 6:26 PM
                            > >
                            > > *Subject:* Re: [scrumdevelopment] Re: Does anyone have experience in
                            > > adopting Scrum in Software Maintenance?
                            > >
                            > >
                            > >
                            > > Kevin,
                            > > With your backlog consisting of a significant percentage of maintenance
                            > > type stories, is there any reason that your organization wouldn't also move
                            > > to Kanban? Or do you feel that the maintenance type work is resulting from
                            > > systemic issues in your org/process that you'd like to understand and
                            > > address before making that type of change?
                            > > On Oct 3, 2012 7:51 PM, "Kevin Callahan" <kcallahan@...> wrote:
                            > >
                            > > **
                            > >
                            > > Hi Xiaozhou,
                            > >
                            > > Here's what the team I work with is doing these days; I would say we're an
                            > > intermediate-level adoption and constantly striving to improve. We have
                            > > several scrum teams working toward a web oriented architecture, meaning
                            > > that teams write features required by other teams and then expose that
                            > > functionality via external API calls. One of the pain points is the
                            > > conflict between planned feature development and unplanned emergent work, a
                            > > nice way to say production issues; all of these are tracked in the same
                            > > backlog on a per-team basis. We used to call all production issues bugs,
                            > > though over time it's become more and more clear that this is not the case.
                            > > Yes, some of these are due to defects in the software, though more often
                            > > they are due to unforeseen use contexts, changes to behavior of external
                            > > data APIs (the app is a sort of middleware), or volume that is outside of
                            > > the design parameters.
                            > >
                            > > Because of these latter points, we now treat production issues as research
                            > > spikes, and they are added to the current sprint as for us, responding to
                            > > production trumps all other work, and you may start to see why so many
                            > > folks have suggested Kanban for maintenance, because technically in Scrum,
                            > > we can't just mess with the committed sprint backlog. Customers who want
                            > > their apps to work as expected though tend not to care a whole lot how
                            > > technically correct our Scrum implementation is :) Anyhow, so after the
                            > > devs have dug into the issue a bit they can give an overview of what's
                            > > going on. With that information we can decide if this is truly a bug or an
                            > > emergent feature, what it's relative size is, and the PO can use this to
                            > > decide the priority of fixing it now or adding a new item into the product
                            > > backlog for future attention.
                            > >
                            > > Obviously, this situation requires a renegotiation of the sprint backlog,
                            > > with previously-committed items falling out of the sprint. While this is a
                            > > scrum anti-pattern of itself, to me the more important thing is the
                            > > communication within our organization, that information is flowing into and
                            > > out of the team, that there is alignment and agreement on priorities and
                            > > current dev actions, and that we are maintaining a sustainable pace of
                            > > development, and of course, that we are continuously improving the quality
                            > > of our software and the value it delivers to our customers.
                            > >
                            > > Anyhow, I hope that helps a bit; I don't think I can give you much more
                            > > info on our internals for a use case though you're welcome to contact me
                            > > off-list if you'd like more specifics…
                            > >
                            > > Thanks,
                            > >
                            > > -kevin
                            > >
                            > >
                            > > On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:
                            > >
                            > >
                            > > Hi, Steve
                            > >
                            > > Thank you for your time replying. I kind of screwed myself up by choosing
                            > > this topic when i have no actual experience in a real-life scrum project.
                            > > Anyway,long story :D
                            > >
                            > > And concerning what you've brought up, that's the thing i'm interested in.
                            > > And what i would also like to know is that how a PO prioritize the sprint
                            > > backlog and maintenance backlog simultaneously.Are there any models to
                            > > follow or universal guidelines? And what are the factors that might
                            > > influence the priority of maintenance stories compared to original user
                            > > stories? That would be the spot i could write something about. And do you
                            > > by any chance know some projects that I might use as a case?
                            > >
                            > > Many Thanks for your time. And sorry for my lack of knowledge.
                            > >
                            > > Best wishes.
                            > >
                            > > --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@> wrote:
                            > > >
                            > > > Hi
                            > > >
                            > > > My first question is how come you are doing a masters in 'advanced'
                            > > Scrum when you are still a rookie! But that's acedemia for you!
                            > > >
                            > > > The way I have implemented it has always been with developers that are
                            > > also maintainers.
                            > > >
                            > > > They work 3 week Sprints on developement during which time maintenance
                            > > requests come in and are added to a Maintenance Backlog (I even managed to
                            > > get the users to write requests in User Story format for one
                            > > implementation!).
                            > > >
                            > > > On the Monday of the fourth week all the relevant people gather for a
                            > > maintenance Sprint planning workshop where the requests are prioritised,
                            > > estimated and planned.
                            > > >
                            > > > The team work their way through the plan for the rest of the week and
                            > > have a demo on the pm of the Friday; then they go back to development on
                            > > the next Monday.
                            > > >
                            > > > This has had the effect that some low priority maintenance requests
                            > > never get done; some increase in priority as time goes on.
                            > > >
                            > > > Of course 'showstopper' maintenance requests are dealt with immediately;
                            > > the team allow for such possibilities in their development sprint planning
                            > > but it happens very rarely.
                            > > >
                            > > > So that's one way. I have never seen a dedicated maintenance team.
                            > > >
                            > > > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@>
                            > > wrote:
                            > > > >
                            > > > > Greetings
                            > > > >
                            > > > > My name is Xiaozhou Li, a student in University of Tampere in Finland.
                            > > And i'm a total rookie in scrum development area. Recently, i've been
                            > > working on my master thesis concerning adopting Scrum in software
                            > > maintenance and relevant issues. And so far i have some general questions
                            > > including:
                            > > > >
                            > > > > How do you feel about using scrum in software maintenance compared
                            > > with traditional software maintenance process (personally)?
                            > > > >
                            > > > > In which way do you think it's more efficient and profitable (if you
                            > > indeed think it's efficient and profitable)?
                            > > > >
                            > > > > Are there any drawbacks that bothering you if any?
                            > > > >
                            > > > > What are the best practices you think would be concerning scrum in
                            > > software maintenance?
                            > > > >
                            > > > > ......
                            > > > >
                            > > > > I would bring up more specific questions about it later on as i'm a
                            > > bit stuck so far. Thanks a lot for your kind responses including all
                            > > constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
                            > > > >
                            > > > > ps. feel free to contact me with any sort of ideas
                            > > > > email: lixiaozhou725@
                            > > > >
                            > > >
                            > >
                            > >
                            > > Kevin Callahan, CSP
                            > > Scrum Master
                            > > mobile: 207-691-2997
                            > > AIM: kevmocal
                            > > email: kcallahan@...
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            >
                          • Cass Dalton
                            I believe you are arguing semantics. The use of the word maintenance comes.from the fact that the work appears after the main development is done, not from
                            Message 13 of 21 , Oct 5, 2012
                            View Source
                            • 0 Attachment

                              I believe you are arguing semantics.  The use of the word maintenance comes.from the fact that the work appears after the main development is done, not from any wear and tear on the software.  The reason that such work is relevant to the discussion is that this work often comes in unexpectedly and is high priority because it is a defect that is preventing a downstream consumer of the software (customer, integration team, etc.) from working effectively.  Whereas normal development has a flow that lends itself well to scrum's fixed length iterations of immutable work (I.e. not changing work/scope/priorities for work assigned to a Sprint), this so called "maintenance" work can throw a wrench in the process.  The organization is faces with the choice between sticking to the ideals of scrum or responding to their downstream customers.  Customers usually win.  In this discussion thread, it appears that is the case for the OP.  While this is not a catastrophic problem, it detracts from some of the value you get from following the scrum process the way it was intended.  The team focus is degraded and the information radiators may be affected.

                              > Every change to a piece of software is made to accomplish some *new* feature.

                              Really?? You've never made a code change for the sole purpose of fixing an existing feature?  I want to give you the benefit of the doubt, but that statement makes it sound like you've never written code in a production environment.
                              On Oct 5, 2012 10:08 AM, "woynam" <woyna@...> wrote:
                               


                              That's funny. I take the complete opposite viewpoint: There is *no* such thing as software maintenance. The term was obviously coined by someone in the Accounting Department who didn't understand software, and was trying to figure out how to depreciate the costs associated with it.

                              Unlike a building's roof, a furnace, or an automobile, software does not wear out. It has *no* moving parts. Given a piece of software and a piece of hardware, it will continue to function as built indefinitely.

                              Every change to a piece of software is made to accomplish some *new* feature.

                              Do you want you software to run under Windows 7, when it was not designed for it? Well, that's a *new* feature. It's not "maintenance".

                              Mark

                              --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                              >
                              > I'm partial to the Pragmatic Programmers definition. All development is
                              > maintenance. It's particularly true if you are aggressive about
                              > refactoring.
                              >
                              > On Thu, Oct 4, 2012 at 7:36 AM, Charles Bradley - Scrum Coach CSP CSM PSM I
                              > <chuck-lists2@...> wrote:
                              >
                              > > **
                              > >
                              > >
                              > > Cass,
                              > >
                              > > How do you define "maintenance type stories"?
                              > >
                              > > My guess is if I asked 10 different developers at 10 different orgs, I'd
                              > > get wildly different answers.
                              > >
                              > > So, how do you define that?
                              > >
                              > >
                              > > -------
                              > > Charles Bradley
                              > > http://www.ScrumCrazy.com <http://www.scrumcrazy.com/>
                              > >
                              > >
                              > > ------------------------------
                              > > *From:* Cass Dalton <cassdalton73@...>
                              > > *To:* scrumdevelopment@yahoogroups.com
                              > > *Sent:* Wednesday, October 3, 2012 6:26 PM
                              > >
                              > > *Subject:* Re: [scrumdevelopment] Re: Does anyone have experience in
                              > > adopting Scrum in Software Maintenance?
                              > >
                              > >
                              > >
                              > > Kevin,
                              > > With your backlog consisting of a significant percentage of maintenance
                              > > type stories, is there any reason that your organization wouldn't also move
                              > > to Kanban? Or do you feel that the maintenance type work is resulting from
                              > > systemic issues in your org/process that you'd like to understand and
                              > > address before making that type of change?
                              > > On Oct 3, 2012 7:51 PM, "Kevin Callahan" <kcallahan@...> wrote:
                              > >
                              > > **
                              > >
                              > > Hi Xiaozhou,
                              > >
                              > > Here's what the team I work with is doing these days; I would say we're an
                              > > intermediate-level adoption and constantly striving to improve. We have
                              > > several scrum teams working toward a web oriented architecture, meaning
                              > > that teams write features required by other teams and then expose that
                              > > functionality via external API calls. One of the pain points is the
                              > > conflict between planned feature development and unplanned emergent work, a
                              > > nice way to say production issues; all of these are tracked in the same
                              > > backlog on a per-team basis. We used to call all production issues bugs,
                              > > though over time it's become more and more clear that this is not the case.
                              > > Yes, some of these are due to defects in the software, though more often
                              > > they are due to unforeseen use contexts, changes to behavior of external
                              > > data APIs (the app is a sort of middleware), or volume that is outside of
                              > > the design parameters.
                              > >
                              > > Because of these latter points, we now treat production issues as research
                              > > spikes, and they are added to the current sprint as for us, responding to
                              > > production trumps all other work, and you may start to see why so many
                              > > folks have suggested Kanban for maintenance, because technically in Scrum,
                              > > we can't just mess with the committed sprint backlog. Customers who want
                              > > their apps to work as expected though tend not to care a whole lot how
                              > > technically correct our Scrum implementation is :) Anyhow, so after the
                              > > devs have dug into the issue a bit they can give an overview of what's
                              > > going on. With that information we can decide if this is truly a bug or an
                              > > emergent feature, what it's relative size is, and the PO can use this to
                              > > decide the priority of fixing it now or adding a new item into the product
                              > > backlog for future attention.
                              > >
                              > > Obviously, this situation requires a renegotiation of the sprint backlog,
                              > > with previously-committed items falling out of the sprint. While this is a
                              > > scrum anti-pattern of itself, to me the more important thing is the
                              > > communication within our organization, that information is flowing into and
                              > > out of the team, that there is alignment and agreement on priorities and
                              > > current dev actions, and that we are maintaining a sustainable pace of
                              > > development, and of course, that we are continuously improving the quality
                              > > of our software and the value it delivers to our customers.
                              > >
                              > > Anyhow, I hope that helps a bit; I don't think I can give you much more
                              > > info on our internals for a use case though you're welcome to contact me
                              > > off-list if you'd like more specifics…
                              > >
                              > > Thanks,
                              > >
                              > > -kevin
                              > >
                              > >
                              > > On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:
                              > >
                              > >
                              > > Hi, Steve
                              > >
                              > > Thank you for your time replying. I kind of screwed myself up by choosing
                              > > this topic when i have no actual experience in a real-life scrum project.
                              > > Anyway,long story :D
                              > >
                              > > And concerning what you've brought up, that's the thing i'm interested in.
                              > > And what i would also like to know is that how a PO prioritize the sprint
                              > > backlog and maintenance backlog simultaneously.Are there any models to
                              > > follow or universal guidelines? And what are the factors that might
                              > > influence the priority of maintenance stories compared to original user
                              > > stories? That would be the spot i could write something about. And do you
                              > > by any chance know some projects that I might use as a case?
                              > >
                              > > Many Thanks for your time. And sorry for my lack of knowledge.
                              > >
                              > > Best wishes.
                              > >
                              > > --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@> wrote:
                              > > >
                              > > > Hi
                              > > >
                              > > > My first question is how come you are doing a masters in 'advanced'
                              > > Scrum when you are still a rookie! But that's acedemia for you!
                              > > >
                              > > > The way I have implemented it has always been with developers that are
                              > > also maintainers.
                              > > >
                              > > > They work 3 week Sprints on developement during which time maintenance
                              > > requests come in and are added to a Maintenance Backlog (I even managed to
                              > > get the users to write requests in User Story format for one
                              > > implementation!).
                              > > >
                              > > > On the Monday of the fourth week all the relevant people gather for a
                              > > maintenance Sprint planning workshop where the requests are prioritised,
                              > > estimated and planned.
                              > > >
                              > > > The team work their way through the plan for the rest of the week and
                              > > have a demo on the pm of the Friday; then they go back to development on
                              > > the next Monday.
                              > > >
                              > > > This has had the effect that some low priority maintenance requests
                              > > never get done; some increase in priority as time goes on.
                              > > >
                              > > > Of course 'showstopper' maintenance requests are dealt with immediately;
                              > > the team allow for such possibilities in their development sprint planning
                              > > but it happens very rarely.
                              > > >
                              > > > So that's one way. I have never seen a dedicated maintenance team.
                              > > >
                              > > > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@>
                              > > wrote:
                              > > > >
                              > > > > Greetings
                              > > > >
                              > > > > My name is Xiaozhou Li, a student in University of Tampere in Finland.
                              > > And i'm a total rookie in scrum development area. Recently, i've been
                              > > working on my master thesis concerning adopting Scrum in software
                              > > maintenance and relevant issues. And so far i have some general questions
                              > > including:
                              > > > >
                              > > > > How do you feel about using scrum in software maintenance compared
                              > > with traditional software maintenance process (personally)?
                              > > > >
                              > > > > In which way do you think it's more efficient and profitable (if you
                              > > indeed think it's efficient and profitable)?
                              > > > >
                              > > > > Are there any drawbacks that bothering you if any?
                              > > > >
                              > > > > What are the best practices you think would be concerning scrum in
                              > > software maintenance?
                              > > > >
                              > > > > ......
                              > > > >
                              > > > > I would bring up more specific questions about it later on as i'm a
                              > > bit stuck so far. Thanks a lot for your kind responses including all
                              > > constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
                              > > > >
                              > > > > ps. feel free to contact me with any sort of ideas
                              > > > > email: lixiaozhou725@
                              > > > >
                              > > >
                              > >
                              > >
                              > > Kevin Callahan, CSP
                              > > Scrum Master
                              > > mobile: 207-691-2997
                              > > AIM: kevmocal
                              > > email: kcallahan@...
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              >

                            • woynam
                              Lol. Yes, I ve written plenty of code for a production environment. I don t consider fixing a bug maintenance . The bug didn t magically appear. It was there
                              Message 14 of 21 , Oct 5, 2012
                              View Source
                              • 0 Attachment
                                Lol. Yes, I've written plenty of code for a production environment.

                                I don't consider fixing a bug "maintenance". The bug didn't magically appear. It was there all along, but the lack of a test case obviously allowed it to escape into production.

                                That said, you've raised good points about the affects of unplanned work on the team. Like any unplanned work, bug fixes have to be prioritized along with any "new" work. Sadly, there are plenty of bugs that won't get fixed because there's a perceived greater ROI in developing new features.

                                Mark

                                --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
                                >
                                > I believe you are arguing semantics. The use of the word maintenance
                                > comes.from the fact that the work appears after the main development is
                                > done, not from any wear and tear on the software. The reason that such
                                > work is relevant to the discussion is that this work often comes in
                                > unexpectedly and is high priority because it is a defect that is preventing
                                > a downstream consumer of the software (customer, integration team, etc.)
                                > from working effectively. Whereas normal development has a flow that lends
                                > itself well to scrum's fixed length iterations of immutable work (I.e. not
                                > changing work/scope/priorities for work assigned to a Sprint), this so
                                > called "maintenance" work can throw a wrench in the process. The
                                > organization is faces with the choice between sticking to the ideals of
                                > scrum or responding to their downstream customers. Customers usually win.
                                > In this discussion thread, it appears that is the case for the OP. While
                                > this is not a catastrophic problem, it detracts from some of the value you
                                > get from following the scrum process the way it was intended. The team
                                > focus is degraded and the information radiators may be affected.
                                >
                                > > Every change to a piece of software is made to accomplish some *new*
                                > feature.
                                > Really?? You've never made a code change for the sole purpose of fixing an
                                > existing feature? I want to give you the benefit of the doubt, but that
                                > statement makes it sound like you've never written code in a production
                                > environment.
                                > On Oct 5, 2012 10:08 AM, "woynam" <woyna@...> wrote:
                                >
                                > > **
                                > >
                                > >
                                > >
                                > > That's funny. I take the complete opposite viewpoint: There is *no* such
                                > > thing as software maintenance. The term was obviously coined by someone in
                                > > the Accounting Department who didn't understand software, and was trying to
                                > > figure out how to depreciate the costs associated with it.
                                > >
                                > > Unlike a building's roof, a furnace, or an automobile, software does not
                                > > wear out. It has *no* moving parts. Given a piece of software and a piece
                                > > of hardware, it will continue to function as built indefinitely.
                                > >
                                > > Every change to a piece of software is made to accomplish some *new*
                                > > feature.
                                > >
                                > > Do you want you software to run under Windows 7, when it was not designed
                                > > for it? Well, that's a *new* feature. It's not "maintenance".
                                > >
                                > > Mark
                                > >
                                > > --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@>
                                > > wrote:
                                > > >
                                > > > I'm partial to the Pragmatic Programmers definition. All development is
                                > > > maintenance. It's particularly true if you are aggressive about
                                > > > refactoring.
                                > > >
                                > > > On Thu, Oct 4, 2012 at 7:36 AM, Charles Bradley - Scrum Coach CSP CSM
                                > > PSM I
                                > > > <chuck-lists2@> wrote:
                                > > >
                                > > > > **
                                > > > >
                                > > > >
                                > > > > Cass,
                                > > > >
                                > > > > How do you define "maintenance type stories"?
                                > > > >
                                > > > > My guess is if I asked 10 different developers at 10 different orgs,
                                > > I'd
                                > > > > get wildly different answers.
                                > > > >
                                > > > > So, how do you define that?
                                > > > >
                                > > > >
                                > > > > -------
                                > > > > Charles Bradley
                                > > > > http://www.ScrumCrazy.com <http://www.scrumcrazy.com/>
                                > > > >
                                > > > >
                                > > > > ------------------------------
                                > > > > *From:* Cass Dalton <cassdalton73@>
                                > > > > *To:* scrumdevelopment@yahoogroups.com
                                > > > > *Sent:* Wednesday, October 3, 2012 6:26 PM
                                > > > >
                                > > > > *Subject:* Re: [scrumdevelopment] Re: Does anyone have experience in
                                > > > > adopting Scrum in Software Maintenance?
                                > > > >
                                > > > >
                                > > > >
                                > > > > Kevin,
                                > > > > With your backlog consisting of a significant percentage of maintenance
                                > > > > type stories, is there any reason that your organization wouldn't also
                                > > move
                                > > > > to Kanban? Or do you feel that the maintenance type work is resulting
                                > > from
                                > > > > systemic issues in your org/process that you'd like to understand and
                                > > > > address before making that type of change?
                                > > > > On Oct 3, 2012 7:51 PM, "Kevin Callahan" <kcallahan@> wrote:
                                > > > >
                                > > > > **
                                > > > >
                                > > > > Hi Xiaozhou,
                                > > > >
                                > > > > Here's what the team I work with is doing these days; I would say
                                > > we're an
                                > > > > intermediate-level adoption and constantly striving to improve. We have
                                > > > > several scrum teams working toward a web oriented architecture, meaning
                                > > > > that teams write features required by other teams and then expose that
                                > > > > functionality via external API calls. One of the pain points is the
                                > > > > conflict between planned feature development and unplanned emergent
                                > > work, a
                                > > > > nice way to say production issues; all of these are tracked in the same
                                > > > > backlog on a per-team basis. We used to call all production issues
                                > > bugs,
                                > > > > though over time it's become more and more clear that this is not the
                                > > case.
                                > > > > Yes, some of these are due to defects in the software, though more
                                > > often
                                > > > > they are due to unforeseen use contexts, changes to behavior of
                                > > external
                                > > > > data APIs (the app is a sort of middleware), or volume that is outside
                                > > of
                                > > > > the design parameters.
                                > > > >
                                > > > > Because of these latter points, we now treat production issues as
                                > > research
                                > > > > spikes, and they are added to the current sprint as for us, responding
                                > > to
                                > > > > production trumps all other work, and you may start to see why so many
                                > > > > folks have suggested Kanban for maintenance, because technically in
                                > > Scrum,
                                > > > > we can't just mess with the committed sprint backlog. Customers who
                                > > want
                                > > > > their apps to work as expected though tend not to care a whole lot how
                                > > > > technically correct our Scrum implementation is :) Anyhow, so after the
                                > > > > devs have dug into the issue a bit they can give an overview of what's
                                > > > > going on. With that information we can decide if this is truly a bug
                                > > or an
                                > > > > emergent feature, what it's relative size is, and the PO can use this
                                > > to
                                > > > > decide the priority of fixing it now or adding a new item into the
                                > > product
                                > > > > backlog for future attention.
                                > > > >
                                > > > > Obviously, this situation requires a renegotiation of the sprint
                                > > backlog,
                                > > > > with previously-committed items falling out of the sprint. While this
                                > > is a
                                > > > > scrum anti-pattern of itself, to me the more important thing is the
                                > > > > communication within our organization, that information is flowing
                                > > into and
                                > > > > out of the team, that there is alignment and agreement on priorities
                                > > and
                                > > > > current dev actions, and that we are maintaining a sustainable pace of
                                > > > > development, and of course, that we are continuously improving the
                                > > quality
                                > > > > of our software and the value it delivers to our customers.
                                > > > >
                                > > > > Anyhow, I hope that helps a bit; I don't think I can give you much more
                                > > > > info on our internals for a use case though you're welcome to contact
                                > > me
                                > > > > off-list if you'd like more specifics…
                                > > > >
                                > > > > Thanks,
                                > > > >
                                > > > > -kevin
                                > > > >
                                > > > >
                                > > > > On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:
                                > > > >
                                > > > >
                                > > > > Hi, Steve
                                > > > >
                                > > > > Thank you for your time replying. I kind of screwed myself up by
                                > > choosing
                                > > > > this topic when i have no actual experience in a real-life scrum
                                > > project.
                                > > > > Anyway,long story :D
                                > > > >
                                > > > > And concerning what you've brought up, that's the thing i'm interested
                                > > in.
                                > > > > And what i would also like to know is that how a PO prioritize the
                                > > sprint
                                > > > > backlog and maintenance backlog simultaneously.Are there any models to
                                > > > > follow or universal guidelines? And what are the factors that might
                                > > > > influence the priority of maintenance stories compared to original user
                                > > > > stories? That would be the spot i could write something about. And do
                                > > you
                                > > > > by any chance know some projects that I might use as a case?
                                > > > >
                                > > > > Many Thanks for your time. And sorry for my lack of knowledge.
                                > > > >
                                > > > > Best wishes.
                                > > > >
                                > > > > --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@> wrote:
                                > > > > >
                                > > > > > Hi
                                > > > > >
                                > > > > > My first question is how come you are doing a masters in 'advanced'
                                > > > > Scrum when you are still a rookie! But that's acedemia for you!
                                > > > > >
                                > > > > > The way I have implemented it has always been with developers that
                                > > are
                                > > > > also maintainers.
                                > > > > >
                                > > > > > They work 3 week Sprints on developement during which time
                                > > maintenance
                                > > > > requests come in and are added to a Maintenance Backlog (I even
                                > > managed to
                                > > > > get the users to write requests in User Story format for one
                                > > > > implementation!).
                                > > > > >
                                > > > > > On the Monday of the fourth week all the relevant people gather for a
                                > > > > maintenance Sprint planning workshop where the requests are
                                > > prioritised,
                                > > > > estimated and planned.
                                > > > > >
                                > > > > > The team work their way through the plan for the rest of the week and
                                > > > > have a demo on the pm of the Friday; then they go back to development
                                > > on
                                > > > > the next Monday.
                                > > > > >
                                > > > > > This has had the effect that some low priority maintenance requests
                                > > > > never get done; some increase in priority as time goes on.
                                > > > > >
                                > > > > > Of course 'showstopper' maintenance requests are dealt with
                                > > immediately;
                                > > > > the team allow for such possibilities in their development sprint
                                > > planning
                                > > > > but it happens very rarely.
                                > > > > >
                                > > > > > So that's one way. I have never seen a dedicated maintenance team.
                                > > > > >
                                > > > > > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou"
                                > > <lixiaozhou725@>
                                > > > > wrote:
                                > > > > > >
                                > > > > > > Greetings
                                > > > > > >
                                > > > > > > My name is Xiaozhou Li, a student in University of Tampere in
                                > > Finland.
                                > > > > And i'm a total rookie in scrum development area. Recently, i've been
                                > > > > working on my master thesis concerning adopting Scrum in software
                                > > > > maintenance and relevant issues. And so far i have some general
                                > > questions
                                > > > > including:
                                > > > > > >
                                > > > > > > How do you feel about using scrum in software maintenance compared
                                > > > > with traditional software maintenance process (personally)?
                                > > > > > >
                                > > > > > > In which way do you think it's more efficient and profitable (if
                                > > you
                                > > > > indeed think it's efficient and profitable)?
                                > > > > > >
                                > > > > > > Are there any drawbacks that bothering you if any?
                                > > > > > >
                                > > > > > > What are the best practices you think would be concerning scrum in
                                > > > > software maintenance?
                                > > > > > >
                                > > > > > > ......
                                > > > > > >
                                > > > > > > I would bring up more specific questions about it later on as i'm a
                                > > > > bit stuck so far. Thanks a lot for your kind responses including all
                                > > > > constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
                                > > > > > >
                                > > > > > > ps. feel free to contact me with any sort of ideas
                                > > > > > > email: lixiaozhou725@
                                > > > > > >
                                > > > > >
                                > > > >
                                > > > >
                                > > > > Kevin Callahan, CSP
                                > > > > Scrum Master
                                > > > > mobile: 207-691-2997
                                > > > > AIM: kevmocal
                                > > > > email: kcallahan@
                                > > > >
                                > > > >
                                > > > >
                                > > > >
                                > > > >
                                > > > >
                                > > > >
                                > > > >
                                > > > >
                                > > >
                                > >
                                > >
                                > >
                                >
                              Your message has been successfully submitted and would be delivered to recipients shortly.