Oh, we have continuous builds and have working software we 'ship' regularly, as
well...

The idea of test launch/soft launch of a game is definitely a strategy but one
that might not be applicable for a high profile IP, because, if Halo was
launched in a region (assuming that was even possible) like Canada or SE Asia,
well, it'd be big news and blow the marketing release. THat was my point.

bernie


--- In scrumdevelopment@yahoogroups.com, Andrew Burrows <andy@...> wrote:
>
> The steps Adam outlined are how we develop social games. We challenge our
> teams to produce working software as quickly as possible, ideally by the
> end of the first day of our sprints (5 day sprints). We then iterate on
> working software.
>
> On Tue, Oct 2, 2012 at 11:35 AM, Adam Sroka <adam.sroka@...> wrote:
>
> > **
> >
> >
> > On Tue, Oct 2, 2012 at 7:34 AM, Charles Bradley - Scrum Coach CSP CSM
> > PSM I <chuck-lists2@...> wrote:
> > >
> > >
> > >
> > > Ron,
> > >
> > > I don't know. I think maybe it has been implied.
> > >
> > >
> > > Adam wrote:
> > >
> > > > 2) If you know exactly what you are going to build and when you are
> > > > going to have it built why are you literally
> > > > wasting your time with Scrum? You'd have more time to do what you
> > intend
> > > > to do anyway if you weren't making
> > > > your people go to pointless planning meetings. They are, in fact,
> > > > pointless, unless there is some possibility that
> > > > you will learn something and change the plan.
> > >
> > > I know what Adam is trying to get at, but it does seem we're being pretty
> > > hostile to a newcomer. That is not new for this list, but I'm afraid we
> > > might have gone over the "hostility line" here -- but not by much.
> > >
> >
> > Adam doesn't always pull his punches, especially when he is on the
> > wrong coast and having trouble sleeping. That said, my intent was to
> > stop diddling around and get to the heart of the matter. Hostility is
> > not what I was aiming for per se, but I was trying to get a reaction.
> >
> >
> > > CuriousChimp,
> > > My guess is that you have said several things on this list that imply
> > that
> > > you are not doing something that is close to Scrum, and that's why you're
> > > getting a lot of resistance. Whether you are doing Scrum correctly or
> > > incorrectly is probably still up for discussion, as you haven't provided
> > > much evidence that you are doing Scrum. Further, what evidence you have
> > > provided has been in non-Scrum terms. (What is a producer? What is a lead
> > > game designer? What is a business owner? What is a 'resource'? None of
> > > these are Scrum terms.) Maybe if you told us some more about your Scrum
> > > implementation, we might be able to help more.
> > >
> >
> > There was a lot of "we are different because..." That always gives me
> > pause. The game industry terminology is familiar to me.
> >
> >
> > > Earlier in this thread, you asked...
> > > > ...why is it that if I ask for a data tracking plugin to interpret the
> > > > same data provided in the burndown in a simple fashion, people have to
> > tell
> > > > me they 'smell' another problem?...
> > >
> >
> > And a bit before that:
> >
> >
> > >
> > > We have specific delivery requirements in terms of feature set, and we
> > > want to add some functionality beyond original product goals. We're
> > working
> > > on a high profile game in a competitive space, and this data will help us
> > > plan whether we need additional resources, etc.
> > >
> >
> > I don't know how to get the requested information from JIRA, but I
> > suspect if you can put it in you can get it back out. More importantly
> > however, if you had this information and you used it to make staff (or
> > equipment, or whatever "resource" means) decisions you would be making
> > a horrible mistake that I have seen fail many, many times.
> >
> > Here's something that works for me: build a playable version of the
> > game as quickly as you can -- days, weeks at most. Look at the
> > remaining features and slice them into tiny pieces that you expect to
> > be able to finish similarly quickly. Build the most important ones
> > first.
> >
> > Keep improving the artwork and the game play incrementally while you
> > are adding features. Automate your performance tests and run them all
> > the time. As soon as you have problems aggressively optimize.
> >
> > Whenever it is that you need to be done you will have a defect free,
> > performant, fun game. It may or may not have some feature that you
> > imagined when you started. You'll survive.
> >
> >
> > > Because we don't believe in giving addicts more drugs without a thorough
> > > examination first. I'm not saying you are a "command and control" addict.
> > > I'm just saying that you seem to be asking for more drugs without
> > letting us
> > > know that you're currently on the path to recovery. I suspect you'll get
> > > more support and more advice if you can tell us that you are on a good
> > Scrum
> > > path.
> > >
> >
> > That's a good way to put it, much better than anything I said, in fact.
> >
> >
> >
>
>
>
> --
> Andrew Burrows
> Managing Producer, Large Animal Games
> Call me: 212-989-4312
> Follow me: @readytoscrumble
> We're Hiring: http://largeanimal.com/jobs
>

Hi,

We use the greenhopper plugin for Jira.

Works fine for planning sprints and see what is done and what not.

Regards,

Angelo

privat: -------------------- www.oomentor.de --------------------------
Angelo Schneider         OOAD/UML         Angelo.Schneider@...
Putlitzstr. 24       Patterns/FrameWorks          Fon: +49 721 9812465
76137 Karlsruhe           C++/JAVA                Mob: +49 172 9873893

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?

Scope:  Large systems and distributed teams working on Lean/Agile/Scrum etc.

To date, I have not seen any tools for tracking Kanban/Scrum stories that
explicitly limit the size of story text or number of acceptance criteria.  With
many new teams using these tools, there is a tendancy for story size or the
collection of acceptance criteria to grow quickly.

A good coach will catch this trend, and some tools allow size of stories and
numbers of criteria to be controlled in some fashion, but that means more work
for the tool admin (or the Team).

Even systems that use virtual "card" spaces tend to have little or no control
out of the box for story size, though many limit the display size.

(An interesting option would be to scale the stories and criteria to fit on a
smartphone screen, but then w'd need two-sided phones to capture the backs of
the cards. <g> )

Comments, anyone?

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@...
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

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@...

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.

A good coach will catch this trend

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@
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>

As scrum dev suppports .net dont see any need of this. But it raised another q.does microsoft endroses scrum