How to Handle O&M

[TonkaTruck]

I recently took on a project with a team that has been practicing
scrum for about three years now. The application itself is about 4
years old - going strong and still developing new and interesting
functionality. However, as with any "older" application, there is
beginning to be growing O&M (operations and maintenance) tale and I am
wondering what options are being suggested for handling this within a
scrum team?

Our Product Owner has little interest in our need for software
patches, code clean-up and hardware upgrades. He has traditionally
preferred that we manage this outside of our sprint commitments. As a
result, our velocity is shrinking. I have suggested to the team that
we point our O&M tasks but I am unsure of how to present these to our
Product Owner as he will likely not want to prioritize them. His
preference is to allow us x% of time per sprint to address O&M. The
team has tried this method for the past year but what I've noticed is
that as our O&M needs fluctuate it makes it difficult to keep our
sprint velocity consistent. Also, we are far exceeding the x% he has
allotted and as our velocity shrinks, the team feels they are getting
little credit for the work they are actually doing.

One suggestion was to split into two scrum teams - one team to commit
to the new sprint development and one to focus on O&M. The O&M team
could then pull from the backlog if they needed work but they would
never intially commit to formal points at the start of the sprint. I
suspect however that if I present this option to our Product Owner
that he will feel as if he is losing some control over what we are
working on since he will only be able to prioritize work for half the
team.

Anyone have any suggestions as to how to continue to practice scrum
with established projects?

[Kurt Häusler]

It think it is natural for velocity to go down as there is simply less time spent delivering new value and more time spent on unplannable O&M.

Try to see velocity as a planning tool, rather than credit.

I don't like the idea of splitting things into two teams, the craftsman in me suggests that the best people to maintain a system are those that have already built up a relationship with the software while developing it.

However if you have some team members that enjoy maintenance, and others that enjoy new development, you could consider a split.

How about letting the team decide, what points have they made during the retrospectives?

> --
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>

[Bachan Anand]

I like Kurt's idea about letting the team decide, it would be good to get the input of the PO also when making the decision. Looks like a potential situation to Apply Innovation Games or Open Space to find a solution.

Bachan Anand
WORK is GOOD
Tel  +1-949-232-8900

Contact Me

Work is GOOD How to get started on a right note in your Agile journey with an assessment

[Jeff Lindsey]

Sounds like two challenges - a PO who isn't interested in "not cool"
aspects such as O&M (commonly referred to around here as "burying your
head in the sand"), and how to structure the team for it.

One of the biggest benefits of Scrum is ongoing transparency for both
the team and customer/PO; my advice is to leverage that and provide
full visibility. Present data showing this loss/fluctuation in feature
velocity over a period of time, and if applicable, the increase in
cost (people-hours, dollars, ideally both) if the O&M items slip down
further in the backlog. Then push for him to help write and then
prioritize specific O&M stories along with the feature stories.

For the structure issue, I would lean towards keeping O&M and feature
stories mixed into the same team/backlog. It will prevent the teams
from burning out, and ensure that O&M is more clearly prioritized
based on its ROI compared to the other feature stories.

[Marko]

I had similar issue a while ago. Roger Brown suggested me these
solutions:

1. have separate support (O&M) team;
2. let the whole team work on new development and support jobs
simultaneously;
3. have support team member "role(s)" (not Scrum role) which would be
rotated every new sprint.

I have suggested these solutions to the team and they chose 3rd. We're
small team to split. We we working as described in 2nd, but there was
too context switching and now we chose 3rd. Now one team member is in
"support" role and others are working on new stories.

Regards,
Marko Majkic

[George Dinwiddie]

Hi, Tonka,

On 7/6/10 9:19 PM, TonkaTruck wrote:
> I recently took on a project with a team that has been practicing
> scrum for about three years now. The application itself is about 4
> years old - going strong and still developing new and interesting
> functionality. However, as with any "older" application, there is
> beginning to be growing O&M (operations and maintenance) tale and I am
> wondering what options are being suggested for handling this within a
> scrum team?
>
> Our Product Owner has little interest in our need for software
> patches, code clean-up and hardware upgrades. He has traditionally
> preferred that we manage this outside of our sprint commitments.

I agree with him. These are just part of doing business. This sort of
overhead needs to be a part of everything you do.

> As a result, our velocity is shrinking.

If it's continuing to shrink, that suggests to me that the technical
debt is being allowed to grow, and therefore the "clean up" gets bigger
and bigger over time.

It takes learning and commitment to "refactor mercilessly" to support
indefinite development.

> I have suggested to the team that
> we point our O&M tasks but I am unsure of how to present these to our
> Product Owner as he will likely not want to prioritize them. His
> preference is to allow us x% of time per sprint to address O&M. The
> team has tried this method for the past year but what I've noticed is
> that as our O&M needs fluctuate it makes it difficult to keep our
> sprint velocity consistent. Also, we are far exceeding the x% he has
> allotted and as our velocity shrinks, the team feels they are getting
> little credit for the work they are actually doing.

Story points are not "credit." They are just a measure of how much new
work you accomplished the past sprint, to be used to estimate how much
work to take on in the next sprint. If you pretend the overhead of
maintenance is the same as new work, you'll over-commit more and more,
and get further and further behind on keeping the code base in good shape.

> One suggestion was to split into two scrum teams - one team to commit
> to the new sprint development and one to focus on O&M. The O&M team
> could then pull from the backlog if they needed work but they would
> never intially commit to formal points at the start of the sprint. I
> suspect however that if I present this option to our Product Owner
> that he will feel as if he is losing some control over what we are
> working on since he will only be able to prioritize work for half the
> team.

I suspect that the quality problems will get worse if you do this, as
the "new work" team won't have to clean up its own messes. Any
shortcuts they take in coding will be the problem of the "second class"
maintenance team.

> Anyone have any suggestions as to how to continue to practice scrum
> with established projects?

Yes. Keep the code in good shape to support perpetual development. Do
everything in as small a step as possible. Continue to reflect on ways
to get better at both of these things.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[TonkaTruck]

Ah - thanks. I think your reminder about velocity being a planning
tool vice a tool for gaining credit may actually help us in talking
with our PO since one concern has been that he will feel that he is
getting less if we start increasing the visibility of our O&M.

We are actually planning on pointing some of the O&M tasks we
completed this sprint during our next retro so I was glad to see that
you have suggested that very thing.

J.

> > For more options, visit this group athttp://groups.google.com/group/scrumalliance?hl=en.- Hide quoted text -
>
> - Show quoted text -

[TonkaTruck]

Thanks Jeff - I think, in thinking it over the past few weeks, that a
lot of issues are coming from the fact that we have not maintained the
burning visibility that the team may have started with. I think you
are absolutely correct - we need to regain this visibility so that we
can accurately portray the time spent on O&M vice the time spent on
feature stories.

We are going to try to point out the O&M stories we are aware of this
coming sprint and see if we can put at least the big ones into the
mix.

Cheers,
J.

On Jul 7, 8:28 am, Jeff Lindsey <sleepingj...@gmail.com> wrote:
> Sounds like two challenges - a PO who isn't interested in "not cool"
> aspects such as O&M (commonly referred to around here as "burying your
> head in the sand"), and how to structure the team for it.
>
> One of the biggest benefits of Scrum is ongoing transparency for both
> the team and customer/PO; my advice is to leverage that and provide
> full visibility. Present data showing this loss/fluctuation in feature
> velocity over a period of time, and if applicable, the increase in
> cost (people-hours, dollars, ideally both) if the O&M items slip down
> further in the backlog. Then push for him to help write and then
> prioritize specific O&M stories along with the feature stories.
>
> For the structure issue, I would lean towards keeping O&M and feature
> stories mixed into the same team/backlog. It will prevent the teams
> from burning out, and ensure that O&M is more clearly prioritized
> based on its ROI compared to the other feature stories.
>

> > with established projects?- Hide quoted text -

[TonkaTruck]

George -

Thanks for your reply. Our team is actually quite focused on
refactoring their code and keeping it tight. The large majority of
our O&M is driven by policy changes, business rule changes, and
changes to the apps with interface with. But, perhaps the "part of
doing business" is the take-away I need to have here. The more we
grow and the more we interface with other apps, the more we need to
realize and demostrate that this "part" also grows and needs to be
assumed to exist.

Thanks,
J.

[George Dinwiddie]

Tonka,

On 7/8/10 9:28 PM, TonkaTruck wrote:
> The large majority of
> our O&M is driven by policy changes, business rule changes, and
> changes to the apps with interface with.

Hmmm... These sound like legitimate stories, to me. Are these changed
functionality, rather than simply maintenance?