Feedback

Tag cloud

what's your question? be descriptive.

By: [ Editor ] Asked

How Best to Turn Team Around?

We are an Agile team of five devs and three testers and we are caught in a bit of a loop at the moment.

We seem to be stuck fixing bugs for clients and we aren't getting any feature work done at all. Even though we have monthly releases to satisfy clients, we end up patching older versions as clients are raising issues as critical, that we wouldn't really deem critical.

Most of the devs time is spent on these bugs and it's not great for morale and it's not great for the continuous improvement of the product.

Would be interested in answers if anyone has faced this problem before and overcome it or just advice on how best an Agile team can swing this round and get back to feature work.

Thanks.

Add comment viewed 226 times Latest activity about 1 year ago

NN comments
or Cancel

4 answers

  • 2

marcin niebudek

I see at least three different aspects of your problem.

  1. Ho is your product owner? Or who is deciding on priorities for your product? You are saying that fixing those bugs is not so good for improvement of the product, but maybe it is. If you clients rise them as critical then maybe this is where they find the most value for them. After all we want to deliver the most possible value.

  2. Ar they really bugs or some small ad-hoc change requests? Again they might be more valuable to the clients.

  3. I assume that if you are posting this problem here then your clients are flooding you team with those requests but in the other hand they are not satisfied with the number of let's call them "real new features" you deliver at the end of your monthly iteration?

To handle no. 3 you may try to convince the clients and the product owner that you will for the next few iterations accept only some amount of those patches and leave space for 2-3 features. However this is risky for me, as you need to answer one more question:

Why are we flooded by those bugs? Why there are so many of them. Maybe there is some quality problem within the team/process and we should first find a way to stop those bugs from going out to production?

So to sum it up:

  1. Find the root cause of the so high number of bugs because it's paralyzing your team's velocity.
  2. Prioritize those requests withing your product backlog as you do with the features - you need to be sure that you clients really see them more valuable than the other items.

I know to little about the full context of your project to give some more detailed advice.

NN comments
steve conley
-

Thanks for the comments, I’ll add a bit more detail here. Our software is used by large companies, heavy usage and generally, not able to upgrade so easily, IT department barriers etc. When an issue comes in and is marked as critical, we have to drop everything and fix it. There is no scope to only allow so many through in each release and these are bugs, as opposed to small change requests sneaking in. I’ve not heard any client unrest about the lack of new features, it’s more unrest from within our team that we plan to do work and then don’t deliver it.

steve conley
-

When we’ve got these monthly release, it’s just nasty to keep patching. A lot of bugs coming in lately are from code produced even a couple of years ago that is just manifesting now as a problem, issues with huge amounts of data etc. I’d certainly love to investigate the bugs that are coming in and try to prevent this continuing but for the quick turnaround, I’d love to know best ways to start getting feature work in also, if this is even possible.

marcin niebudek
-

I think there is no way out unless your team get support or is allowed to for example rotate 2 of your 5 devs (or 4 out of 5 if its more appropriate) within a role of firefighting sub-team.

But it also looks to me that you clients are more interested in geting those fixes than getting new features. I would like (as a developer) to always do some new interesting features, but beware of the feature creep. If tuning existing features brings the most value to your clients, then as an agile team you need to accept that. But I would try to turn them to 1st class stories.

or Cancel
  • 1

kevin rutherford_18

It sounds as if your clients have tremendous power over you. Will they really not wait to the end of the month for the next scheduled release?

That said, how good is your automated regression testing? Do you write a test for each bug so that it can never return?

NN comments
steve conley
-

Hi kevin, thanks for commenting. Yes, the clients do have a lot of power as our system is so integral to a lot of what they do. If our system goes down or a bug is preventing carrying out their work, as long as that issue is classified as critical, we’re committed to a very quick fix turnaround and thus all else is dropped. It just seems like the critical bar is getting lower and lower, though this is something we are trying to kick back against. We have no automated reegression testing so a test is not written for each bug. All of our testing is manual.

kevin rutherford_18
-

One approach may be to try to rebuild the clients' confidence in your team and product. Meet with them and explain that raising everything as critical isn’t helping you fix their problems, and take responsibility by telling them you’re going to start root cause analysis, cluster analysis and regression testing for prevention. See if you can get them to help instead of hinder; maybe agree a limit on the number of fixes you’ll do each month, or outside of the release schedule.

kevin rutherford_18
-

I’ve seen this happen a lot, where the client loses patience and confidence and just raises everything as critical. You need to get the clients to believe that you’re on their side. Maybe even hire a couple of external firefighters in the short term to get some automated tests in place in the buggiest areas?

And how come it’s all hit the fan now, if some of the code is a couple of years old?

or Cancel
  • 1

steve ropa

Would it be possible to have a chat with whoever is deciding the priorities and to make a deal with them? "Here is a list of x number of defects and feature storis. This is the amount of work we feel we can accomplish this iteration. Can you please prioritize based on the estimates? The caveat is each iteration needs to contain at least one feature, so that you, the customer, don't have to stay in this defect chasing situation forever."
I also saw a yellow flag when you stated that patches are a pain. I wonder if it might be worth taking some time to make sure your automated unit and acceptance tests are in place and up to date. Continous Integration can really become your friend.

NN comments
or Cancel
  • 0

d. andré dhondt

Hi Steve-- I've come into environments like that--where "firefighting" was the main activity of developers. I agree that it's de-motivating... but within weeks I was able to turn it around. Have you taken a look at where these bugs are coming from? Can you do anything to stem the flow of new bugs? Do you have any form of regression/safety harness? One of the key mantras that worked for me is "it's our game". Customers can make as many requests as they want, but it's up to us to figure out how best to satisfy them. Just because there's a new bug today doesn't mean that we should stop working on yesterday's bug. When we were turning things around, we learned we needed to show empathy, clarify the impact, and then understand the priority. We needed to do things right the first time, because there was no time to come back and fix it later. This doesn't give us license to solve bigger or anticipated problems--just what's needed today. Does any of this resonate with you?

NN comments
or Cancel

Question's Contributors

Related Questions