Does Agile work for bug squashing and software maintenance?
I have a question: can bug fixing be done using Agile methods? Currently, the project I am on is in the last few months leading up to delivering a final product (hopefully) and we are mostly doing bug fixing, performance and functional testing, and other such stuff that a team does in such circumstances. We have done away with IPM(Iteration Planning Meeting)s and retrospectives and are simply squashing bugs as quickly as we can.
This seems to be working, but I am not certain that it is the best way to proceed. On one hand, it frees us from committing to certain bugs allowing us to switch to more critical bugs as they come in and on the other hand, it makes it harder for us to track what we are doing since too much context switching can result in some bugs languishing in a half solved state for too long. Although this rarely actually happens since developers usually try to finish a bug before switching.
I think one of the biggest problems with this approach is that any pair is expected to pick the next highest bug on the list regardless of whether they are the best people to fix that bug. There is no real idea of self organization or the team decided who is going to work on what. For the most part, we are simply told what to work on.
I think this is what I dislike most about this format. There have been a few bugs that I have worked on that have taken several days to fix whereas a more experienced developer with domain knowledge could have fixed it in a few hours. I am not sure what business value this provides to the client?
Anyone else have any thoughts on this? Can bug squashing be done using Agile techniques or are they only good for the “real” development stage of development and not for delivery or maintenance?
Obviously a lot of it depends on the organization/structure of your workplace, but it’s working fine where I’m at.
regarding your example, what we do is have that developer with domain knowledge explain to who’s working on the bug what to do and check in with them at the end of the day to see 1) if it’s done and 2) if they’re heading in the right direction. This typically only takes 10-15 minutes to review what they did, and while it’s not ideal for the client to have someone without direct domain knowledge working on it, there is oversight and it works towards getting them up to speed.
YMMV
One of the best functioning agile teams I’ve ever participated in was solely working on fixing bugs.
It sounds like you have a communication problem for starters. You state that there is no self organization, but you don’t touch on why. You’re all sitting there together. If someone knows the domain really well, bring them in to pair with you. Later, when another bug comes in the same area, you’ll be better equipped to handle it. I recall switching pairs multiple times a day in some cases. Of course, there may be a nasty bug that requires a pair to stick with it for more than a day. In a team that communicates and trusts each other, that message will be conveyed.
I think I forgot to mention a few key points in my post. First, the team is highly distributed with the senior developers/domain knowledge holders in location A, a few relatively newbie developers in city B and the rest of the team on site with the client in city C.
In addition, we are set to deliver the product to the client in a few months and will then hand the maintenance over to the client. It makes more sense to me to have some of the client developers start pairing with us and bring them up to speed as opposed to having two new team developers start learning the domain only to leave in a few months. But maybe I am missing the point here.