8

I am a project manager working with a product development team. We are using SCRUM with our development team. We have a heavy backlog list, that we are working on.

The issue that I am having is, we have now released several versions of our product and we need to have a team on maintenance mode as well. This is mainly due to the fact that from the previous releases we have done, there are customers who are using the product.

I have got a separate team and added two of my existing development team members to work with that maintenance team. We rotate two people after every release from the development team to the maintenance team and bring the previous two back to the development team.

The issue I have is with the new comers in the maintenance team, it is very difficult to get them to work independently on LIVE bugs, small requirements etc., and the development team personnel eventually end up working on bugs, client requirements etc. This impacts sprint delivery and the development team is now missing the sprint deadlines.

I have researched and read articles on this subject, but still I am not 100% confident on what is theoretically explained.

Any help from anyone who has faced similar situation would be greatly appreciated.

Aziz Shaikh
  • 3,217
  • 24
  • 40
IndikaM
  • 181
  • 1
  • 3

8 Answers8

8

SCRUM is not an acronym.

You do not need two teams. Try running textbook style Scrum.

It sounds like you're not properly respecting the velocity of the team. If the team does not deliver all of the stories for the sprint then you should attempt fewer stories next time.

You incorporate the distraction of maintaining releases in the velocity of your team. All work, including small features and bugs should be product backlog items.

Try to get the basics of a Scrum team working before changing processes (Scrum Buts).

Dave Hillier
  • 760
  • 3
  • 12
  • 1
    Hi Dave, One issue I have in my situation is we need to be able to build the items that are high priority and in the product backlog, which will have multiple releases. However with each release we may add several clients to use our released product. So for example, release 1 of the product will be bundled and given to several customers to deploy on their site. So one release may result is many clients finding issues and needing quick fixes as well as they may have small customization that needs to be done to them ASAP. So how do I tackle that without impacting the mainstream development? – IndikaM Dec 17 '13 at 23:01
  • 5
    Create a single order priority backlog and be strict about this. This will ensure that the highest priority items are delivered first. If release patching is more important they will make it to the top of the backlog. Limit work in progress, if something is very important get several members of your team to work together by pair programming and or splitting into smaller tasks. If customer needs are more important than continuous releases then you would have to suspend work anyway. This just simplifies the process. – Dave Hillier Dec 18 '13 at 11:41
  • @IndikaM: You might want to check what ASAP really means for those customizations if a price tag is attached (e.g. delivery in a release within 3 months is free, delivery in the release in two weeks is x k$, delivery outside the release schedule is y k$, with y > x). You might be surprised how long ASAP can suddenly take and that you can actually start to plan that work. Critical bugs in the release are obviously something else, but the really critical ones should be relatively rare. – Bart van Ingen Schenau Oct 08 '17 at 12:41
8

What You're Doing Wrong

[T]he development team personnel eventually end up working on bugs, client requirements etc. This impacts sprint delivery and the development team is now missing the sprint deadlines.

By failing to protect the development team from unscheduled work, and not following the rules of Scrum by calling for an Early Termination and a return to Sprint Planning as soon as you learn that the Sprint Goal can't be met, you have gotten exactly the results you should expect from your current process.

Sometimes sprints fail. Sometimes unscheduled work happens. However, there are well-defined Scrum procedures for dealing with those events. If you don't follow them, why are you expecting success?

Why You're Doing It Wrong

Your organization is not prioritizing work, and it's not acknowledging real-world velocity or work-in-progress limitations. In your comments you say:

So one release may result is many clients finding issues and needing quick fixes as well as they may have small customization that needs to be done to them ASAP. So how do I tackle that without impacting the mainstream development?

In other words, the organization is not making wise strategic choices about how to spend its time, money, or resources. Support and change-requests will add drag to your new-feature velocity, and that should be clearly reflected in the priority of items in the Product Backlog and in your teams' velocity metrics.

It is the Product Owner's job to prioritize, and the teams' responsibility to only accept as much work into each sprint as they realistically expect to complete. Meanwhile, the Scrum Master must ensure that everyone is playing by the same set of rules.

  1. If the Product Owner tells you support and new features are both of equal priority, that person is not fulfilling the requirements of the role. The Product Owner's job is to allocate available capacity to whatever is most important to the organization for the duration of the current Sprint.

  2. If the teams aren't saying "no" to work that they know they can't accomplish, they aren't fulfilling the requirements of their roles either. The job of a Scrum team is to estimate the work involved as accurately as possible, and only commit to the volume of work they can complete at a sustainable pace.

  3. If the Scrum Master isn't educating the organization about how to apply Scrum, or is not playing referee and calling a time-out when the Product Owner or the team aren't fulfilling their roles properly, then the Scrum Master isn't fulfilling that role either. A process failure isn't the Scrum Master's fault, but not making the process failure visible and transparent is.

What To Do Instead

Don't flog your team until morale improves. Don't turn every sprint into a death march. Instead, fix your process by:

  1. Making sure everyone understands their roles.
  2. Making sure that the organization continually inspects-and-adapts its process.
  3. Teaching everyone from the CEO down to the mailroom clerk the differences between estimates, targets, and money-back guarantees.
  4. Pulling the emergency brake when the process is failing, and fix the underlying problems before restarting the assembly line.
  5. Making all work (planned or unplanned) a visible cost to the project.
  6. Making the cost of not planning the work or addressing the process issues visible.

Basically, stop basing your project plans on the hope that unplanned work will get done during the night by magic pixies without impacting your schedule or consuming project resources. There is no magic pixie dust; just visibility, transparency, realistic estimates, and continual process improvement.

Community
  • 1
Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
1

Maintenance team skills are mainly significant recreating the bug, analyis and then coding, testing(unit, regression, UAT, BAT etc...) and deployment. They do the same in the development projects too. Domain knowledge is also very important for Maintenance team. As there is no root cause mentioned not sure why your developers are unable to perform this. Discuss with them what is their challenges individually and plan your solutioins for each individual accordingly. The basics for maintenance and development both are same. In fact as the requirements are small it should be easier in maintenance space.

Sreedhar Nadadur
  • 737
  • 1
  • 5
  • 12
  • Thanks Sreedhar, The thing is that when a product release is done, the development team sarts working on the next release in a sprint time box. So when they have to attend client issues, small client customization, it impacts the sprint. I am trying to see what would be the best way of getting this done so there is minimum impact for sprint, but at the same time we have ample support for maintenance. – IndikaM Dec 17 '13 at 10:01
  • 2
    It goes back to the planning. You need to give a best shot of estimation how much effort the maintenance issues consume and arrange your team efforts accordingly. Priorities also need to visit as maintenance bugs are important to fix as users are already using it, where as new features are yet to develop and use it. Planning and Priortization should take care of this. – Sreedhar Nadadur Dec 17 '13 at 10:06
1

I would assign a fixed capacity bandwith for each major workstream, and manage this in a timeboxed fashion. In your case, this might be

  • New developemnt
  • Support
  • New user setup

I have written about it here and here on this list. Please check those answers out.

Good Luck, Stephan

Community
  • 1
Stephan
  • 5,252
  • 1
  • 21
  • 31
1

Depending on the total number of developers you have available in your dev and maintenance teams it may make sense to re-combine them into a single team, some or all of whom work on both maintenance and on-going development. You can then handle maintenence in one of two ways.

1) Add all the tasks into the backlog, estimate them and add them to sprints as you would any other task [this won't work for ad-hoc, urgent work of course].

2) Keep the tasks separate from the backlog and work on them as required along with the remainder of your sprint tasks.

The key to the latter one is to make an estimate of how many hours/days (or equivalent story points) the maintenance takes during a typical sprint period and make sure this is factored in when you are planning your sprint goal. For example, if an ideal two week sprint allows you to complete 100 story points but maintenance is likely to use up 20 story points of effort then you can only commit to 80 story points from your backlog in each sprint. This will take a while to balance out but this is really what velocity is a measure of - how much project work you can get done once you've factored in all the other interruptions that take place in reality. Maintenance can just become another one of those interruptions.

The benefit of this approach is that everyone is working on both dev and product maintenance. You'll make sure you don't make the same mistakes again if you're the one fixing it every time it breaks! It also lets your team scale up or down on the maintenance requirements during each sprint (e.g. 'this week we've got to deploy patches to 12 clients and upgrade a server so there's no way we can commit to more than 60 story points on product dev')

You might also want to consider 'Scrumban' (or even pure Kanban) as an approach - I've found this quite effective when dealing with lots of bug fixing while continuing to build new features/products.

Willl
  • 2,071
  • 11
  • 29
0

Rotate all of the developers

Looks like you have created what Roman Pichler calls "a two-class society with the cool feature developer doing rad innovation work, and the poor old maintenance guys slaving away at mind-numbingly boring bug fixes".

Rotate all of the developers, including the new comers in the maintenance team. It will do way with the stigma as well as help with knowledge sharing. This should help improve productivity and collective ownership.

Ashok Ramachandran
  • 11,082
  • 1
  • 22
  • 50
  • Hi Ashok, One issue I have in my situation is we need to be able to build the items that are high priority and in the product backlog, which will have multiple releases. However with each release we may add several clients to use our released product. So for example, release 1 of the product will be bundled and given to several customers to deploy on their site. So one release may result is many clients finding issues and needing quick fixes as well as they may have small customization that needs to be done to them ASAP. So how do I tackle that without impacting the mainstream development? – IndikaM Dec 17 '13 at 23:02
  • I don't see how this answers the question as the question already says that it is going to have rotation. "We then rotate after every release two people from the development team to the maintenance team and bring the previous two back to development team." – Dave Hillier Dec 18 '13 at 12:11
  • @Dave Hillier My understanding is that the maintenance team is fixed and from the development team two different people are rotated in each time. OP can clarify if that is not the case. – Ashok Ramachandran Dec 18 '13 at 14:07
  • Yes, that is how we have it planned now, We have a fixed maintenance team and we rotate 2 development team members after each release. But what I am not sure is, is that the best way to handle this scenario. – IndikaM Dec 18 '13 at 23:00
0

Thank you for all your inputs in this challenge that I have.

What I plan to do is following.

I have 6 members in the development team who are practicing SCRUM process and 10 members in the maintenance team who are not following any agile methodology.

What I am planning to do is combine both teams and create 3 teams. I will combine development and maintenance team members and plan each sprint with 2 teams for development and 1 team on implementation and maintenance. This maintenance team will rotate every sprint. That will give us more predictability.

Also I will need to see what I need to do in order to make sure the maintenance team also plan their work in order to minimize the impact to clients.

IndikaM
  • 181
  • 1
  • 3
0

We had a team of 4 developers working on delivering new functionality to the product in iterations. At some point, when the product was introduced to the end-users, we also faced the constant flow of bugfixes and small feature requests or UX improvements. The product was in active selling phase so the client did not accept the solution to include these "bugfixes" to the next iterations. So we did the following:

  • pulled out one developer from the main team and assigned all the ongoing requests to him;

  • created a separate board for "bugfixes", prioritized and estimated them. QA team did periodically check whether the issues are still reproduced.

  • continued the new features delivery with the team of 3 people. It influenced the delivery speed, but for the client this was more acceptable than not having the bugs fixed asap.

I don't see any reason to rotate developers between the teams, in fact, that slows down the progress. At least in our case this would have worsened the situation because of additional time to understand the new piece of work.

Julia
  • 71
  • 3