schedule compliance and keeping technical supports and resolving issues

Question

I am an entrepreneur of a small software developer company. The flagship product is developed by myself and my company grew up to 14 people. One of pride is that we've never have to be invested or loaned.

The core development team is 5 people. 3 are seniors and 2 are juniors.

After the first release, we've received many issues from our customers. Most of them are bug issues, customization needs, usage questions and upgrade requests.

The issues from customers are incoming many times everyday, so it takes little time or much time of our developers. Because of our product is a software development kit(SDK) so most of questions can be answered only from our developers. And, for resolving bug issues, developers must be involved. Estimating time to resolve bug is hard. I fully understand it. However, our developers insist they cannot set the any due date of each project because they are busy doing technical supports and bug fixes by issues from customers everyday. Of course, they never do overwork.

I suggested them an idea to divide the team into two parts: one for focusing on development by milestones, other for doing technical supports and bug fixes without setting due days. Then we could announce release plan officially. After the finish of release, two parts exchange the role for next milestone.

However, they say they "NO, because it is impossible to share knowledge and design document fully." They still say they cannot set the release date and they request me to alter the due date flexibly. They does not fix the due date of each milestone. Fortunately, our company is not loaned and invested so we are not chocked. But I think it is bad idea to keep this situation. I know the story of ant and grasshopper.

Our customers are tired of waiting forever of our release date. Companies consume limited time and money. If flexible due date without limit could be acceptable, could they accept flexible salary day?

What is the root cause of our problem? All that I want is to fix and achieve precisely due date of each milestone without losing frequent technical supports.

I think there must be solution for this situation. Please answer me.

Thanks in advance.

PS. Our tools and ways of project management are Trello, Mantis-like issue tracker, shared calendar software and scrum(collected cards into series of 'small and high completeness' projects).

Answer 1

This is not something that my team does today but it's a proposed change to our process that I've been floating by other people for a little while (and I'm curious what the community thinks about this, so all comments welcome)...

You said your team is already doing scrum and have a backlog of work represented by cards. To a developer working on a new feature (new development) and getting it to work, is very similar to working on an existing broken feature (bug fixing) and getting it to work. Work is work.

You, as a product owner, could treat bug fixing same way you treat new development tasks and prioritize them in the same backlog. Some bugs (or feature requests) can wait, others must be fixed. Some are very important, some can be fixed later. You can decide on these factors and put them in the appropriate place in the backlog and you can decide if they should be in current release or delayed till next one.

This way, as long as your team maintains point velocity, you should be able to get a rough idea of when the release is going to be completed. All you have to do is plot a graph with two lines that interpolate the following data sets:

1. Your team's story completion - how many cumulative points are completed each iteration
2. Your teams's scope creep - total number of points which are part of the release. this number will obviously go up when you add bugs to be part of the release, but that's just a reflection of reality.

At a point in time where the two lines intersect is your estimated release date.

I agree with your developers that splitting the team is not ideal. Personally, I would hate to be isolated in maintenance land while the other part of my team drove the architecture and major design decisions without me. At the same time, if you feel that 2/5 developers should be dedicated to bug fixing, what about simply requiring that 40% of time (no more, no less) in a given iteration be dedicated exclusively to bugs, but the whole team would be involved?

Aside from figuring out the scheduling problem, as other mentioned, you as a team should also figure out the root cause of so many bugs coming in that they are affecting the schedule. Don't look for a solution yourself, instead hold a series of retrospective meetings and let the team drive the discussion. Work together to set reasonable quality goals/targets and then ask them for ideas on how to achieve them.

Don't know if your team is doing any of these today, but here some ideas:

1. Design reviews - before jumping into work, have a quick peer review of the work ahead. This gives a chance for a second set of eyes to spot potential problems before they get into code, which is much more expensive to fix.
2. Code review - With a help of code review tools (some are open source), code review process can be run very effectively. It'll help you share knowledge and identify potential problem areas before they even get into production code.
3. QA - do you have a dedicated testing team or do developers do their own testing? I find that developers tend to get conditioned or "get used" to how software works and they start overlooking usability issues. Fresh set of eyes from end-user perspective can find all kinds of things.
4. TDD/Automated unit tests - this one isn't easy and many teams have tried and failed at it. But if done right, it'll let you deliver components which would be much more solid and would not require your guys to come back to them month after month. Also for some engineers, who are not as detailed oriented, TDD can work wonders. I've worked with some guys who write decent code and produce functionality, but they consistently miss boundaries and what-if cases. I would argue that spending time up-front of writing test code would be a great investment vs. time spent after each one of those boundary cases is encountered by the customer and requires a fix after the release. With TDD, it's another opportunity to verify use case scenarios and then simply let developers loose. When tests pass, you'll be much more comfortable that you are releasing something with quality.

Answer 2

This is a common and challenging problem. Many customer issues are genuinely lengthy research projects in their own right, and until they are fully understood, it is just not possible to estimate the effort required to fix them.

One solution to this is to dedicate two developers at a time strictly to issue resolution, rotating the assignment to another pair of developers every three or four weeks.

Answer 3

I see a few issues here:

• Your software seems excessively buggy if your developers are being swamped with bug reports. You need to take a look (Root Cause Analysis) at the bugs being raised and see why they're occuring. If you don't do this you'll merely run into the same issues at each release.

• Measure the bug fixing process. Record the date the bug was raised, the date the investigation began, the date a suggested fix was found. See if there are blockers here.

• Is your documentation bad? Are your UIs unintuitive?

• You don't seem to have the resources to support more than one version of your product. There comes a point when you stop maintaining old releases of products unless there are exceptional circumstances (critical/showstopper bugs), and if a customer wants something in an old product you have to know when to tell them No/It's not worth fixing.

• You're the boss, if you want your employees to work in a new way they should. Listen to their protests but explain to them why things need to change and ask them if they can see alternatives.

Answer 4

If you have too many bugs in your current version, then dedicating resources to the next version (before reducing the bug count) is going to only add more bugs.

I'd make it a priority to

1. prioritize the existing bugs
2. find and fix the high priority ones
3. perform a Root Cause Analysis to figure out why you're getting so many bugs

Tell your developers to SLOW DOWN. Writing buggy code quickly is more damaging than writing stable code slowly.

Answer 5

The scenario is:

• Your team is fourteen people, with five developers.
• You are privately help and debt free.
• Your customer likes your product enough to engage with you instead of going to someone else.
• You have a technical business, and a non-technical person can't support the product.
• Your developers need their focus for features and bug fixes.
• Your developers don't want to alternate between feature development and bug fixes.
• You are busy developing, but have not had recent releases to customers.
• You have been favoring the creation of features to the correction of defects, maybe for a while now.

The answer is simple, but depending on whether your team has a mature attitude, unpleasant.

• You need to pay the technical debt to fix the bugs.
• You need to support customers using members of the team.

Your original instinct was probably correct. Some team members need to work features and some bugs, alternating periodically. If you went through the bug database and traced the defect to its author, that would be a way to assign the bugs and perhaps determine the duration of each person's rotation. However, sometimes, the bug exists because the person writing the particular code didn't have the skill to write it. This may be where your distinction between junior and senior team members can be of benefit.

WRT customer support, I recommend that you rotate that function as well. If a small number of people work customer support, they will hear the same questions and provide the same answers, potentially building a database of FAQs. Once you have written collateral for support, you can use less technical people to share it with customers. There are many systems for automated customer support including Right Now Web which might be too expensive, but perhaps it can help you find leads to an open source alternative. Not everyone on your team will have the talents needed for working with customers, so you may find you need to bite the bullet and if you have the skill, do it yourself. At least for a while.