Problem Description: How to apply scrum in a mixed feature development and SLA-bould bug fixing team?

[Martin Häntzschel]

Hello people!
I have an interesting problem in a new company I'm working for and I'd
like your help on this. This company develops, mantains and hosts
ecommerce websites for different kind of companies (clothes,
electronic devices, furniture carpets, etc). There is currently no
formal development process, bugs on the live site and new feature
received by the client are developed by request. I want to introduce a
sort of tailored scrum process, but the problem is that the same team
resolves bugs and works on features, and some weeks there are many
bugs and some there are really few. Bugs from the live site have to be
resolved ASAP if they are high priority. There is a sort of SLA with
the client as we're dealing with transactional ecommerce sites, hence
money might be lost, so there's no way to add bugs to a backlog and
plan them for the next sprint, they need to be resolved straight away.
Moreover, the structure is the following: there's a project manager
that is working on the new features and a support person that gets the
bugs from the client, and both assign work to the same team, to the
same tech lead!
How can I improve the structure there to add scrum? I can track bug
fixes during the sprints as unplanned work. I can also play with the
capacity of the team, have them all at 50% or another sort of
capacity, but this will never be the same. The velocity will always
fluctuate, as the capacity of the team will always change due to the
bug fixes, therefore no proper release planning can be done.
Is having the same team working on bugs and working on features the
problem? I know that having two different people assigning work for
the team is not right.
I know there must be a way to apply scrum here, even though many
changes might need to be done, they are willing to listen.
Looking forward for your comments and help!
Thanks in advance!

[Albert Arul Prakash Rajendran]

Hi Martin,

This is a normal scenario in most of the product based companies. In our company we had the same type of problem and we solved as below.

Pick one or two members from team in a rotation basis and assign them to fix the Sustaining Engineering (bug fixes/old bug fixes) issues. 

This way your core team will not be juggling between tasks and each member of the team will work on the SE issues on a rotation basis. This avoids people getting demotivated (i am doing only SE no feature development) also gives perspective on what the customer faces.

Another one is to reduce the sprints to 1 or 2 weeks duration. This will enable you to achieve the SLA (in case a large influx of bugs) faster.

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

--

with luv, 
Albert Arul Prakash
http://www.bepenfriends.com/ a free online dating web site

http://www.facebook.com/yourdatingguru - your dating guru

There are only 3 colors, 10 digits, 26 letters, 7 notes and 118 elements; its what we do with them that's important.

[Kamlesh]

Hi Martin,

The situation at hand may sound bit tricky, as you've described - still, it could be addressed.

If you take a step back and think for a moment, how will this situation change/improve when we've lesser unplanned work to handle?

Why we've so many bugs coming in from live application? - specially when it's handling monetary transactions. and how could we minimize bugs from going to production?

Do we put in enough efforts testing the functionality? what about automating some of it (or  even better most of it) ? -if not doing that already.

Observe how much (more) effort and money you guys have to spend to fix the bugs in this reactive way - You could even share your observations with your team/leadership and the potential cost savings if bugs were fixed during development.

As far as addressing current situation, time boxed development may not be the ideal solution considering the unknown. You may consider how Albert is already handling it  or alternately, consider Kanban approach, where you (/those who are responsible for addressing customer requests) prioritize the list of bugs/features and the team members pull from there.

Hope that helps, what are your thoughts?

Best,
Kamlesh Ravlani, CSP

[Steven Voyles]

Hi Martin,

It sounds like in addition to the unpredictable level of support issues coming in to the team, you also have an environment where multiple product lines are competing for the team's capacity. Is that the case?

I agree with Kamlesh. I would work with the team to identify and mitigate the root causes of your quality issues over time to reduce the impact of unplanned work caused by bug fixes. Until the amount of unplanned work is reduced, it will be difficult to plan and a continuous flow model using some sort of kanban might be best. 

Once you address the quality issues and reduce the amount of unplanned work to a minimum, you can begin to investigate whether or not the time boxed, predictable cadence of releases that scrum helps provide are valuable to your organization.

Steven

[Ran Nyman]

Hello Martin, couple of question popped in my mind.

Which problem do you try to solve by introducing Scrum?
What benefits do you expect and how do plan to measure them?

Ran

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

--
Ran Nyman
+358 44 3410 124
http://rannicon.com

[John Miller]

How many team members on the team?

If large enough you could consider splitting the teams. One for focused development/engineering work(plan driven) and the other for operational maintenance and incident driven work. 

If not, one of our teams chose to work this way. 

They split their Sprints to 50% capacity to do engineering and improvement work, as well as major problems, using Scrum. The other 50% is incident driven work through the ticketing system. One person each sprint is designated as "eyes on glass" for routing new incidents and monitoring.   The great thing is they all work on engineering as a team and in incident resolution as a team, pairing frequently for continuous learning and quality.

The tickets and SLA's are brought into the Scrum ceremonies just as the development stories. For example, there may be a story to improve response times to meet SLA.  The team will review if they met SLA goals during the Sprint Reviews, through ticket metrics.  It works great.  The team also has ITIL built in as part of their definition of done and as part of their Scrum Board. Scheduled tasks are also created as a reusable story and goes through the Scrum process  Their needs to be more flexibility here to change goals during the Sprint if required, in case there is a major incident mid Sprint. But, if you calibrate allocating capacity between plan driven work and incident driven work good enough, you will rarely have reprioritize mid sprint based on major incidents. 

Thank You,

John 

Sent from my iPhone. It likes to sabotage my grammar. 

[Martin Häntzschel]

Hi Albert, Thanks for the reply!
I'm afraid the team is too small to rotate for bugfixing (3 people,
different technologies). Also, sometimes more than one team member has
to be assigned to bugs, we need to react day by day to the issues we
get if they are high priority due to the SLA (and we do not only get
one at a time most of the time). We cannot wait even one week.
Any other suggestions with this additional information? Thanks in
advance!

On Apr 26, 6:37 pm, Albert Arul Prakash Rajendran

> Albert Arul Prakashhttp://www.bepenfriends.com/a free online dating web sitehttp://www.facebook.com/yourdatingguru- your dating guru

[Martin Häntzschel]

Hi Kamlesh, thanks for the reply!

We're working on finding the root causes of the bugs, assigning
rafactors to enhance maintainability. We also want to start with
automated testing in Selenium by QA and unit tests by developers. As
you can see the situation is not good from a technical point of view,
but meanwhile, I want to see which is the best way to:

- Deliver new features for ongoing projects following a plan, without
breaking commitments with clients. Achieve a predictable feature
development velocity.
- At the same time resolve any issues in the ongoing projects
following the SLA

Kanban sounds like a great idea. The problem I see is that we won't be
able to create a release plan, but with the actual situation, I cannot
create one as my velocity is not predictible at all. How do you
suggest convincing the client into accepting that? :)

Looking forward to your feedback!

[Martin Häntzschel]

Hi Steven,
Thanks for your comment! Yep, as I told Kamlesh:
---

We're working on finding the root causes of the bugs, assigning
rafactors to enhance maintainability. We also want to start with
automated testing in Selenium by QA and unit tests by developers. As
you can see the situation is not good from a technical point of view,
but meanwhile, I want to see which is the best way to:

- Deliver new features for ongoing projects following a plan,
without breaking commitments with clients. Achieve a predictable
feature development velocity.
- At the same time resolve any issues in the ongoing projects
following the SLA

Kanban sounds like a great idea. The problem I see is that we won't be
able to create a release plan, but with the actual situation, I cannot
create one as my velocity is not predictible at all. How do you
suggest convincing the client into accepting that? :)

---
However I still needs to find a way to establish a process from as
soon as possible, so If you can give me some ideas on how to introduce
kanban in the meantime, let me know!
Thanks in advance!

[Martin Häntzschel]

Ran,
My objectices are, given the current situation:

- Deliver new features for ongoing projects following a plan, without
breaking commitments with clients. Achieve a predictable feature
development velocity.
- At the same time resolve any issues in the ongoing projects
following the SLA

As some guys said, Scrum might not be the best for this case, but
Kanban.
What do you think?

Looking forward to your feedback!

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

[Lisa Hoover]

Hi everyone,

This is a great question and the answers are very informative. Would anyone be willing to write this up as an article that we could post on the Scrum Alliance website and perhaps feature in our newsletter?

Lisa Hoover

Managing Editor,
ScrumAlliance.org
twitter: @scrumalliance

[Martin Häntzschel]

Hi John, thanks for your feedback!
We have three team members, we cannot spit the team unfortunately :(
Cnocerning the idea of the 50%/50% it seems great, but I think it
would not work here as we need to react day by day to the issues we
get if they are high priority due to the SLA. Sometimes all the team
is working on high priority issues. We'll not able to keep the 50% for
feature development, and we won't achieve a predictible velocity.
any ideas?

Thanks in advance!

On Apr 27, 6:20 pm, John Miller <agilescho...@gmail.com> wrote:
> How many team members on the team?
> If large enough you could consider splitting the teams. One for focused development/engineering work(plan driven) and the other for operational maintenance and incident driven work.
>
> If not, one of our teams chose to work this way.
> They split their Sprints to 50% capacity to do engineering and improvement work, as well as major problems, using Scrum. The other 50% is incident driven work through the ticketing system. One person each sprint is designated as "eyes on glass" for routing new incidents and monitoring.   The great thing is they all work on engineering as a team and in incident resolution as a team, pairing frequently for continuous learning and quality.
>
> The tickets and SLA's are brought into the Scrum ceremonies just as the development stories. For example, there may be a story to improve response times to meet SLA.  The team will review if they met SLA goals during the Sprint Reviews, through ticket metrics.  It works great.  The team also has ITIL built in as part of their definition of done and as part of their Scrum Board. Scheduled tasks are also created as a reusable story and goes through the Scrum process  Their needs to be more flexibility here to change goals during the Sprint if required, in case there is a major incident mid Sprint. But, if you calibrate allocating capacity between plan driven work and incident driven work good enough, you will rarely have reprioritize mid sprint based on major incidents.
>
> Thank You,
> John
> Sent from my iPhone. It likes to sabotage my grammar.
>

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

>
> > --
> > with luv,
> > Albert Arul Prakash

> >http://www.bepenfriends.com/a free online dating web site
> >http://www.facebook.com/yourdatingguru- your dating guru

[Martin Häntzschel]

Hi Lisa, as soon as I find the proper solution, I could prepare the
article :)

[Lisa Hoover]

That would be wonderful, Martin. Thanks!

Lisa

[Albert Arul Prakash Rajendran]

Martin,

I second the method told by John Miller. Since your team is very small, I would prefer not to go in lengthier scrum time box way rather Kanban or a One Day Scrum. 

One Day Scrum Starts every morning and ends at the evening. It might have small deliverable (a.k.a. bug fixes and a very small portion of item from future plan) of the commitment. This model does not have daily stand-up but a hourly update on task to the team (e.g hey i fixed this issue and can go live) and review is like checking whether the fix is working properly in staging server. 

This way you attack the issue of SLA and building incremental portions of your future software and can still be in agile process (i believe).

To calculate your velocity you need to use Miller's way of 50% Engineering and 50% Maintenance effort calculation. 

Also I understand from the conversations that you are moving towards strengthening product through automation which is Good. 

I also Recommend a Hardening project (based on automation test results) that will fix most of your issues (which can be an Maintenance Release) of your product.

Do let us know how you fixed this issue which can be a wonderful use case 

Thanks,

Albert Arul Prakash

 http://www.agilecafe.in  What's Brewing today 

http://www.bepenfriends.com/ a free online dating web site

http://www.facebook.com/yourdatingguru - your dating guru

There are only 3 colors, 10 digits, 26 letters, 7 notes and 118 elements; its what we do with them that's important.

[Mark Levison]

Martin - why do you have a team of three? 

- Is your company small? In which case Scrum maybe a heavy process.

- Does your company start lots of projects? In which case you may have Portfolio Management problem.

As you've already noted you're having trouble creating a cross functional team from three people. That's probably a hint.

Cheers

Mark Levison

[Ran Nyman]

Hello Martin,

I would dig little bit more deeper how your development is currently
working and what problems there are. E.g. How long is your development
cycle from customer to customer? What is preventing your currently
from planning? Who needs the plans? Why are the plans not created or
followed?

When you have clear view on the problems in current system you have
much better change on introducing changes that will help your company.

Best Regards,
Ran

> For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

[Jim Bird]

Martin,

I don't see how you can have a predictable feature development
capability and avoid breaking commitments with your customers until
you at least get the support break/fix work under control. When fixing
bugs becomes a small part of your workload, then you could plan ahead
and assume some percentage of the team's work is going to be on
support (this is what we do) and you can look ahead and try to make
bigger commitments. I agree with the idea of using Kanban to focus the
team and your customers (the project manager and support lead) on
issues that are important and urgent - if you can't be predictable, at
least make sure that the team is always working on what is important
to the customers. It's much better than making plans that you can't
keep.

Spend most of your effort getting the support and bug fixing issues
under control, and fix the code and how you are delivering code before
you dig a deeper hole. This means that you will need to slow down for
a bit. Work with your customers to get them to understand that this is
necessary, that you need to make some improvements but once this is
done they will have less problems in production (good!) and you will
be able to deliver software on a more predictable and faster basis
(also good!).

Ask for a bit of time, and then make sure you deliver on your promise
to get better. You need to look at bug clustering (where are the bugs
coming from in the code, what needs to be rewritten), try to put in
pairing or code reviews (hard on a team of only 3 people working on
different technologies, but see if you can do it at least for high-
risk code), get some more time for testing (on a team of 3 people, who
is doing the testing?). Convince everyone that you need to slow down
for a little while and get better, and then get better. Otherwise I
don't see how you will be able to hit your goals.

[Martin Häntzschel]

Hi all, thanks for the answers,and apologies for the late answer to this thread.
Unfortunately there were many factors that made it not possible to apply scrum so quickly in that company. Mostly political. I'm not there anymore.
They are now moving slowly, first with implementing jira and some workflows, then finally greenhopper, but it seems that the answer is Kanban, but they don't want to implement it.
Kind regards,
Martin

> > > scrumalliance+unsubscribe@googlegroups.com.