How to allow developers to get enough quality development time while keeping to support & maintenance obligations

Question

I work for a small company of 6 multi-skilled developers where we have developed our own product which requires constant improvement but also maintenance and support, both for the current release from end users and from other areas of the business.

This results in developers having to dedicate time to both development work and responding to requests for support and maintenance. As a result, the quality time that can be spent on development is squeezed, thus putting more pressure on the developers.

As a company, we have adopted agile methodologies and are working in sprints; we specify our projects using user stories and use story points to do estimates. However, the significant amount of unplanned and unpredictable work that comes in due to end user support requests and requests from other areas of the business that the developers have to deal with makes it very difficult to plan effectively.

I need a better way to organize the development team's time to enable us to plan more effectively and get quality development time while still maintaining our obligations to respond to support requests, fix bugs and respond to requests from other areas of the business. Any suggestions for how to go about this would be greatly appreciated.

UPDATE

I posted an update here:

https://pm.stackexchange.com/a/9465/34

Answer 1

I'm a bit unclear how you are managing the management/support requests. Actually, I'm unclear whether you are managing them at all. You need to manage these requests, to protect your developers.

Software developers can only be productive if they have extensive time "in the zone". Interruptions are the number-one thing that can kill developer productivity and morale. If you're constantly in interrupt mode, where you are interrupting them for some new request, then you're probably doing it wrong.

Instead, it sounds like you need to have a queue for support/maintenance requests, where they are assigned a priority. Rather than immediately implementing them, why don't you let them wait in the queue until when you are scheduled to work on them?

Have you considered deciding what fraction of time you want to spend on maintenance vs new development, and then assigning your developers a schedule accordingly? For instance, if you want to spend 25% of your time on maintenance/support and 75% of your time on new development, then you have several options: you could assign each developer one week of the month where they are on maintenance/support and 3 weeks of the month where they are on new development. When a new support/maintenance request comes in, it goes into the queue, gets assigned a priority, and then when a developer has scheduled time for maintenance/support, they start pulling the highest items from the queue until their scheduled time is over.

One thing is clear: you need to start making some prioritizations. If any time someone sends you a maintenance/support request, you immediately "jump right on it", then you've implicitly made a priority decision: you've decided that every maintenance/support request (no matter how minor) is more important than new development (no matter how important). If that doesn't match the priorities that make the most sense for your business, maybe you need to re-consider how you are prioritizing and how those priorities are reflected in your team's work.

Once you start prioritizing, it's possible you may discover you can't do everything with your existing team. At that point, you have two choices: hire more developers, or accept that there are some tasks you cannot and will not do with your existing resources.

Answer 2

Use swimlanes on your board (or different coloured cards) to indicate the type of work.

One team I worked with divided their board horizontally into two parts - the top for new product development work, the bottom for support/maintenance. Each steam had a separately prioritised backlog that the teams would pull work from when ready. This meant we always had a mix of new dev and maintenance in progress.

Use work in progress limits to make it explicit how you balance the teams time.

In the team above, we had a work in progress limit of 3 stories for new product development and 1 for maintenance so it was clear what ratio of team time we were expecting to be spent on each type of work.

Use expedite cards to accelerate vital work.

We also allowed one expedite token (we just used a big red star) to be placed on cards by the Product Owner. It was expected that a card with an expedite token would get first priority to be worked on so would flow across the board quicker at the expense of other work being completed more slowly. This allowed the PO to get live issues resolved quickly and made it clear when we had something in play that was going to slow everything else down.

Watch how often this is used though. You need to train the PO to only use it when it's actually essential and not to get in the habit of just always having it in play on a story.

David Anderson's Kanban book explores these concepts in more detail and is highly recommended.

Answer 3

It's a bit unclear if you're asking about estimation or about prioritization.

I think lots of answers here tackle the prioritization aspect, so I won't go into that.

If you're asking how to estimate your efforts, given that much of them end up being unplanned work, then there are a bunch of things you can do, but a complete solution is probably impossible to find, for the simple reason that R&D projects by nature contain a high degree of uncertainty that cannot be easily quantified at the start of a project.

But first let's talk about what you can do.

Where is this unplanned work coming from?

It sometimes can seem like unplanned work is just dumped on your team from above, sideways and every other direction. But sometimes a team can bring it on itself. A trivial example: a team that ships in a big, big hurry and delivers buggy code naturally spends a lot of time putting out fires later. By the way, shipping buggy code isn't a way of saying "hey, you suck at coding" - sometimes it's really due to outside pressure no the team to sacrifice quality for cost.

How can you make unplanned work go away?

If you're looking to reduce the amount of time you spend on unplanned work, first you need to identify what sort of work it is, and then work to reduce it. For example, if your development team constantly gets pulled to assist field engineers in installing and configuring the system in production environments, then maybe you should prioritize automating those deployment tasks; redesigning them to be easier, less risky, etc.

Measuring unplanned work won't do you any good

It might seem like a good idea to measure how much time you've spent on unplanned work during the last few sprints and extrapolate from there, but it's a fool's errand. Predicting the unpredictable is futile. Your next sprint may go completely smoothly, and the one after that might be derailed by the biggest clusterf&ck production problem you've ever encountered. You're just not going to be able to predict that.

The problem is that software development, in almost all cases, contains a good portion of unplanned work. Sometimes you just don't count it as such. It's easy to see a delayed project as just under-estimated, but most of the time the problem isn't with how you're estimating, but with what you're estimating. Unless your development projects are completely repetitive (constantly developing the same product over and over) they'll have a high degree of uncertainty built into them, owing to using new tools, tackling new problems and so on. You start off with a great work-plan, but after two days you realize that the library you were going to use isn't really supported by the target platform, and now you have to find an alternative, or, heaven forbid, develop something on your own. Those are the real kickers - the things you just didn't count at all during planning.

So how do we estimate, given all this unavoidable unplanned work?

The whole idea of doing only what you planned on doing, with minimal unplanned work, is just not in the cards for most R&D teams. Obviously. That's why agile is so popular. You can try to minimize unplanned work, to some degree, but in the end your projects' schedules are always going to be dominated by the unplanned stuff. Once you realize that unplanned work is your bread and butter, you can now adapt your project management methods to handle it better:

• Drill down and plan your iterations in detail. It doesn't take a lot of time, if you have a decent PM tool. Break things down to hour-sized tasks, where applicable. This will flush out a lot of the "unplanned" stuff.
• Prioritize the risky stuff. When you break things down to small pieces, you immediately see where your uncertainty lies. It's in those tasks that you don't really know how to break down further, and that you're not really sure about how long they'll take at all. Start from those, if possible. This way your estimate will still be off, but it'll stabilize significantly as your iteration progresses. You won't find yourself at the last couple of days of the iteration suddenly realizing you need 10 more days to finish what you started.
• Negotiate with the project/product managers to work on the most common external source of unplanned work. e.g. would better documentation save your engineers a lot time explaining stuff to field engineers or customers? Then demand to allocate time for this as part of the development effort.

Answer 4

This is a very good question. We are in exactly the same boat as you in terms of our development team, the nature of our work, and the need to respond to support requests. In other words I can relate to how tricky it is to find this balance you seek.

Our solution - which is by no means perfect - has been to adopt a strict daily feedback cycle with our customers, which works as follows:

1. Each morning, the project manager reviews pending support requests and discusses them with the team. The team then gets to work on the support request at the front of the queue (last in last out), whilst the project manager responds to the client to confirm what's being worked on that day.
2. Each morning, if the previous day's support request is partially complete, and another support request comes in, this new support requests is added to the back of the queue of support requests. This must be explicitly communicated in the next morning's daily feedback email.
3. Each morning, if there are no outstanding support request, the team gets to work on product development. If during the day a support request comes in, do not address it until the next morning. That way you do not interrupt your team, but at the same time, because you've created a daily feedback routine with your clients, they know to only expect your email the next morning.

The key take-away point here is to manage expectations by creating (and enforcing) a daily routine of feedback every morning. If you're concerned about how to sell this idea to your customers, focus on explicitly communicating your uncompromising stance on quality.

You'll find that after a while your customers will learn to work with your morning feedback cycle and will grow fond of the sense of stability arising out of the daily routine.

Like I said, it's by no means perfect, but it works well for us.

Answer 5

There are a lot of opinions out there about multi-tasking and its effects on performance and productivity and maybe morale. The only definitive studies out there I have seen about multi-tasking is the stuff between men and women so I don't know that I would take a hard stance about having an individual wear both a development and support role hats. Either way, what is clear is that you need to adjust your estimates and planning values.

If you cannot hire more people, then you need to adjust the durations of your sprints, push them to the right, secondary to the lower than expected available developer utilization rates. Support is support. The supply needs to meet the demand; else you will have unhappy customers. And the demand the varies, so your planning value needs to be at the level to accommodate most of the supply.

Developing schedules can move and no one dies. Trying to control your response on support and someone dies...metaphorically, of course. So re-estimate the demand side of support, and build a case to either hire more talent so you can restructure and separate the roles or schedule development with whatever time remains for work.

Answer 6

This is where i would like to think the lean concepts work very well if practices.

Use a Kanban Board and commit to say 3 to 4 tasks to be done as part of support every day and use rest of the time on development work.

What this certainly means is that a choice between planning 28 hrs in a day and pushing something that may come back quick with chaos or agree to a continuous flow of delivery across both streams and eventually get the productivity factor up achieving the targets.

Answer 7

I've had some success with reviewing the amount of 'business as usual' and support work that is required over the next two weeks (from JIRA and other sources) during our sprint planning and reducing the time available for 'new' development accordingly. This avoids over-promising on your sprint and ensures that support needs are met.

There will obviously be an impact on your velocity if you've never done this before so you need to either review this over time and adjust future delivery dates as required or make a realistic assessment of the % of your development time that is used up with support and adjust on this basis. What you absolutely need to avoid is your Product Manager (or whoever) thinking that you can complete, say, 100 story points in a sprint when, in reality, you normally only complete 80.

It may be a little messy to begin with and it's possible that people will feel disappointed that deadlines need to be pushed back. You need to manage this by pointing out that realistic deadlines are more useful for everyone's sanity and explain the impact that multi-tasking and last-minute requests have on developers and on code quality.

The importance of good prioritisation - as others have pointed out - is also absolutely vital. A frank assessment of the business value of, for example, a bug fix over the development of a new feature needs to be made before your schedule changes.

Answer 8

There are various issues which should be clustered, some are cultural, some are process (or lack there of). I fully understand the situation you are in, I've been there too. Here's how you take care of it:

Process

1. Unit Testing - get 90%+ code coverage. This will allow your team to make bug fixes and system changes without worrying about breaking anything else. It will save you time by being automated and thorough, instead of manual testing.
2. Continuous Integration - automated launching of new code. I don't see if you are a web company or not. Regardless, there are ways of launching code out to the live product literally the second it is done.
3. Task Management - measure progress as it is done. Using one of these will ensure every developer, you, and any other managers, can see in real time exactly what is being done and who is assigned to what. There are multiple systems, and many plugin adapters for many IDE, in particular Eclipse.
4. Accurate Estimates - when estimating time, ask a developer, or the entire time, don't do it yourself as the project manager. Do not have them give you a response immediately, give them 1 day or more. If you don't, they will unconsciously try to people-please you, and they will not be able to estimate accurately since they have not thought of all the details of implementation. Making a cake is easy within 2 hours, but it assumes you have all the ingredients, cookware, etc.

Culture

1. Any time a team is being squeezed it is because of a "failure to meet expectations." The people above / next to you clearly have a lack of understanding of what your team is capable of. You need to teach them. Having a Task Management system in place will help with that. It will teach them how much time it takes to complete a given task and show them what is currently being done. Many people outside a department assume that department has 10+ hrs. per week of "open time". Show them that this is not the case.
2. Project planning should be done in smaller increments, with the expectation that 1/3 or more of the team will be spent on other things. The further you plan a project into the future, the less accurate that estimate will be. I prefer to plan on a monthly basis or less.
3. Prioritize incoming requests. I like to create an "idea bucket," and a "next version list" for feature requests. The idea bucket is good for general ideas that are either not business critical or would take a long time to implement. The next version list allows you to keep scope creep down. If you have 1 month to complete a given project, time gets lost to other things, you can offload some of the less important features to the next version list.
4. Focus on feedback from 1 department at a time. There is ramp-up time for any project, and having 3+ departments requesting features simultaneously means there is a lot of time spent on ramp-up instead of launching code. I have found it highly effective to focus on 1 department's requests every 4 weeks. One month for sales, next month for marketing, next month for editorial, etc.
5. Get a dedicated Customer Support person, even if it is an intern. Your developer's time is very valuable, they should not be interrupted since it takes them out of flow (deep thinking mode) for 15+ min every time they are asked to do something new. Developers are good at writing code, and should have an environment that lets them do that.
6. Make a wiki. This wiki will allow you and the team to post anything that takes more than 4 sentences to explain. Your default answer to any question will now become: Did you check the wiki? It will save time, share information, and make everyone happier.

Best of luck!

Answer 9

We apply two techniques to get this under control:

First is to decide upon the bandwith (capacity) you have available for doing all the work; this is your team capacity doing productive work (so extracting vacation, training, average illness days, etc.)

Next we devide this capacity into fixed buckets: ours is

• 60% Planned development: approved development work to create new stuff (investment); with this 60% available capacity, you can make a plan when all this new stuff will be delivered at the earliest (if the 60% is maintained).
• 20% ad-hoc customer requests: small changes and specific configurations
• 20% support and maintenance

When there is more support needed, the capacity of the customer requests is taken up first.

After each period (sprint, two-weekly, monthly, whatever) the actuals are reviewed and a decision is made upon the buckets for the next period, and this is accordingly planned. e.g.

• there was more support needed, and as a result approved customer requests are queing up, so for the next period we will assign 30% to customer requests and only 50% on development. This will have an impact on the delivery of the planned development, so this is replanned and the impact approved.
• it was a low period for support (rarely, but it happens :-) ) so we made some progress on the planned development, so either we go on as agreed (60-20-20), to remain ahead of schedule, or we do some more work on Customer requests.

If the capacity for support is consistently insufficient, you change the capacity allocation (with impact on the other two of course). Or decide to change the overall capacity by adding people to the team (if possible).

The point here is to keep the available capacity visible for all to see, that work is planned according to the buckets (and not on guesses), and that informed decisions are made regarding corrective actions.

The second technique we apply is more to keep the individual engineers happier, is to assign 1 (or more e.g. functional and technical) person each week to do support (We call him the "Geek of the Week" :-) ). He/she tries to fix all support issues independently; only if it is really complex he'll ask for help from the other teammembers. If support is low, he'll take up some other stuff like a small change or continue to work on planned development. This keeps the other teammembers more focused on their particular subjects, without being disturbed too often by support issues. As the role changes each week, it is considered fair for all.

This works well for us. Good luck!

Answer 10

Try dedicating some proportion of your developers to maintenance/support activities. This avoids issues associated with multitasking, the need to prioritize support vs new projects, removes a source of unpredictability from your sprint planning and should reduce stress on your team.

Exactly what proportion of your developers do maintenance/support work would depend on your average monthly volume of issues with current products compared to ongoing work. In any case if you try this approach you would likely want to rotate who is doing maintenance/support on a fairly frequent and regular basis so that everyone has a chance to do the "cool stuff".

Answer 11

As someone who works in an in-house team, this sounds very familiar. Apart from the possibility that you might simply not have enough resources to deal with all the work coming in, these are a few strategies that might work:

• Dedicate one or two developers to support work and rotate them on a somewhat regular basis, unless you have people who actually want to do support all the time. This has the advantage of making it very clear how much time is going to support tasks. If you dedicate 2 out of 6 developers to support and it turns out that isn't enough, you're at least aware of the simple fact that support eats up 50% or more of your development time.
• Use WIP-limits religiously. Expedite tokens/lanes are great, but should be limited, otherwise everything turns out being really urgent. Make sure WIP-limits are based on reality. See the previous point on how to determine that reality.
• Try to find out if your code is consistently being deployed while it's still bug-ridden and fix that. Rush jobs are a fact of life if/when the pressure is on, but you usually end up paying the price afterwards. In the face of overheated marketing people demanding immediate attention, my only advice is to keep your head cool and calmly but sternly stick to the 'a job worth doing is worth doing right' routine.
• If it eventually turns out you're in a company culture where speed trumps quality every time, return to my first point. Assign one or two devs to support, rotate them and deal with the really urgent stuff. If the backlog starts filling up, explain to management that you're spending 1/3 of your time on support already and maybe, just maybe, you can start turning that company culture around.

Basically, my advice amounts to getting people focused on what matters. If the constant demand of 'urgent' support jobs keeps getting in the way of real productive time, you need to remove that constant demand from as many people as you reasonably can.

Answer 12

Over-estimate the amount of time you will spend each time period on support and maintenance with a comfortable margin what your team would consider a heavy load. Set this time aside for maintenance and plan your available development time around that. You can always use leftover maintenance time on extra development and it will look good for the team to accomplish more than you expected. It is not possible to guess the exact time you will need for maintenance and perfectly plan every sprint.

Answer 13

Others have suggested adding padding to your development estimates to cover support/maintenance, this is a good first step.

To really communicate the issue and to justify your numbers you should have the developers track the amount of time they spend responding to customer support issues as opposed to code maintenance issues and actual new development.

Tracking your time at this level is definitely annoying but will help create a solid picture of where the team is spending their time.

A rougher granularity of estimate (instead of hours) may be the quantity of support tickets worked during a sprint. This doesn't require any additional time tracking from the developers just a field on the ticket to indicate it's a customer support issue instead of a normal development ticket. Then if you are falling behind on delivering new features you can look at the # of support tickets during your sprints and show management that it is e.g. 50% higher than normal and that you need to shift the schedule to the right.

Having these kinds of metrics will definitely help management see that the team is overburdened and may convince them to hire additional dedicated support.

Answer 14

UPDATE - Posted by the asker in the question and moved to a CW answer.

I am actually part of the development team but I am in a position to make suggestions to improve the situation. Everyone has given some very good suggestions so thank you to all, some points of note:

David Espina had some good points when he said "Developing schedules can move and no one dies. Trying to control your response on support and someone dies...metaphorically, of course." -- This is an issue for us, the support work needs to be done whether us developers like it or not.

Assaf Lavie mentioned un-planned work coming from buggy code in a hurry -- This is an issue for us also primarily as a result of the powers that be imposing deadlines from above, but also because of the uncertainty of our sprints meaning we cant get the required development time so we approach a deadline with too much to do.

Assaf also had a good point about not measuring unplanned work, this will be a difficult one to sell to the bosses as we are already required to record our time spent in a time tracking system but so far recording that has got us nowhere.

Ben's suggestions about using the swimlanes and the Expidite token I think could work for us, there is an amount of unplanned work which is setting up accounts, feeds and other services for clients. The sales team always want this done ASAP but probably need to take a chill pill now and again and only give things a hight priority absolutely necessary. The sales team also have direct contact with the development team, so we probably need to sever that line of communication and only allow work to come via the product owner.

D.W & Doug B suggested dedicating a percentage of time each sprint to maintenance & support. But I think the uncertainty will mean that some sprints the maintenance time is under subscribed and at others its over subscribed. So I think in our situation, that will only work some of the time.

Answer 15

To protect the developers try having people who can handle calls from users. More like level 1 support. These people(could be 1 person) should be trained to handle routine issues and should have ability to direct the users to the right person for issue resolution. This person will help in reducing the burden of development team. Also have 2 developers on rotation basis on support job dedicatedly. You can choose the number of developers on support job based on the volume of issues reported. This will enable rest of the gang to churn up new code and because of rotation most of the folks get to do development work every month.

Answer 16

There are a couple approaches that my teams have deployed, each with different pros/cons. I will outline these approaches below. Which one or a hybrid of any, all depends on your business and users.

The first rule of thumb is to tell a story with the data. How much time are you spending on support? If you do not know, start to measure. There could be deeper issues at play here and you need the data to tell the story.

1. Have each team member dedicate some hours every sprint to support. For example, each team member allocates 5 hours per sprint to work on support issues. The trick here is aligning on priorities within the team. Create SLAs/team working agreements for how support will be managed. For example, any H priority issue will be pulled into the current sprint. Medium priority tickets will be addressed in the following sprint. Measure cycle time of support issues by priority to determine volume and if more/less time is required each sprint.

2. Scrumban - all work is prioritized and pulled with work in-progress limits, e.g. no more than 2 stories in a given column of your board. As tickets come in, they are prioritized against all other work and pulled into the sprint. Works well with teams that do not have specific deadlines or support issues that typically need to be addresses as soon as they come in.

3. Develop a rapid response team - works better if you have larger volume of support requests/user questions that need to be answered. Works as follows. 2 members, typically a pair dev/QA do not task to any new work in a given sprint. For the entire sprint, they respond to any ticket that comes in and addresses immediately. For those issues that require more effort, the work is prioritized as work product (story or defect) for an upcoming sprint.

Hope this helps and gives you some ideas.

Answer 17

You mentioned that you are using agile methodologies and working in sprints, so i assume you use Scrum, as it is one of the most popular methodologies. In Scrum the work is somewhat constrained, team members are assigned tasks and those tasks have deadlines that need to be finished before each sprint ends. Unexpected tasks may hinder teams performance to finish tasks on time thus putting more pressure on the developers.

Using Scrumban may relieve some of the pressure as it combines both Scrum and Kanban features. Kanban has fewer constraints than Scrum and can handle a steady stream of incoming tasks like support or maintenance tasks better, its a more event driven agile methodology.