Comments, Code and Qt. Some words about the wonderful world of software engineering


Non-sterile Agile: Comments on “Handling Bugs in an Agile Context”

In my earlier post I already wrote about experiences with agile development. I call these posts "non-sterile agile" because I feel that once agile principles are let loose into the corporate world, agile development changes its nature. I stumbled upon an interesting article by Elisabeth Hendrickson about bugs in agile development. In her article, Hendrickson talks about bug triaging in agile context. It's an interesting read and I agree with her - but only from an agile theoretical point of view. In agile context, it all makes sense that we don't have bugs (or we don't call the issues we observe as bugs at least). Normally we call software defects bugs, but in agile development we don't have bugs because we only create done backlog items. If an item has a bug in it, it will not be called done. Simple - in theory. An item is called done after the Product Owner has seen the piece of software running and can make the decision that the backlog item fulfilled the acceptance criteria that were set up for it. Let's assume this is the case and now a backlog item has been marked as done. Boom. The next day the tester in the team tests the product and finds a defect related to this backlog item. What now? Should the once done backlog item be re-opened and be revisited in some later sprint? In meantime the software evolves and the bug.. sorry, defect is being forgotten about since the team is busy doing something else. How should this defect be recorded in the backlog item? The tester knows how to reproduce the defect, but it might require certain steps which should be recorded somewhere. Should the product owner keep track of all the steps in the backlog item by updating the description. Or how should this really work in the ideal agile world? Hendrickson goes as far as to say that we don't need bug tracking systems in agile development. Again, I agree on a theoretical level since the product backlog should be your only tool to follow undone tasks. But there are several things which bug tracking systems, like Bugzilla, are good at. First of all they record the history of the bug. When using a bug tracking system, you can record exactly in which software version and platform the bug occurred, ask for advice on how to fix it or more needed information and have it all recorded in the context of the defect. Secondly, dependencies. I will return to this topic in another blog post, but in many cases the bug itself is not self contained. It might be caused only or partially by another bug in the system and keeping track of these dependencies is very important. I don't see how this can be handled in the agile context without a proper bug tracking system. How about "low priority issues" or "cosmetics" that do not add business value? She says that it is not worth dragging this information with us. So should we ignore the issues? I disagree with this. Even if an issue is not important to be fixed right away in the current sprint, it doesn't mean that the issue should be ignored and forgotten about. The priorities in the project change all the time and the issues might be sever enough that they need to be fixed before the product can ship, but they don't need to be worked on right away. A bug tracking system is an excellent place to record the issue in detail. She says that circumstances in which the completed stories don’t live up to the Product Owner’s expectations can be called bugs. But what does this mean? Does it mean that after the backlog item is implemented, the Product Owner realizes that the item wasn't good enough or is this the case of regression? In a large and complex system regression is something that is unfortunately common. A once Done and Accepted item can fall apart because of regression or because of dependencies to other components that introduced regression. Then this is a bug that should be recorded into the bug tracking system, with any dependencies, so that it will be fixed. How should this kind of information be recorded in a backlog item that was already done? These are just some thought on the article based on my experience in complex agile projects. I look for your comments on the subject too. I will continue this series by writing about dependencies in agile context and how the reality looks in practice. Update: I saw this response to the article too: It's more on a detailed level responding to individual pieces in the article. Very nice to read and I concur with the points that are made in the article. I currently work as the ScrumMaster for a development team for the third year while working as a software engineer in the team as well. I am a Scrum Alliance certified ScrumMaster. I have also done product owner duties and worked on backlog planning. I wrote my Master's Thesis on agile process assessment (link to Master's thesis here).

Technorati Tags: , , , , ,

  • This doesn’t answer your question, but in both of your scenarios (bug found after signoff, functionality broken due to new features) then I would hope and suggest that the team takes these very seriously indeed. Why wasn’t the bug found before, and what can we do to make sure that we don’t miss similar bugs in the future? Why didn’t the automated tests find that the functionality had been broken by the new code, why didn’t somebody figure out that the new story would affect the existing functionality, what do we have to change to avoid this happening again?

    And then on to your question about where to keep the bugs, in the past teams I’ve been on have handled this in two ways: one with a bug database, and a backlog story item to fix that (and possibly other) bugs, and the other treating them as ‘other’ sprint tasks, which also had things like upgrading hardware on test servers, meetings with support team, seeing what would happen if we ran on a different java version. I don’t think either of these were ideal solutions, and I like Elisabeth’s suggestion that everything goes into the same place, instead of having bugs as something separate – in my current job, where scrum is just being introduced, I plan to use Jira to track tasks, bugs, features, etc.

    • Thank you for your comment!

      While I agree in general with you, I must emphasize that my experience with scrum was in a very large project that was distributed over many stakeholders, teams, continents and timezones. I would argue scrum does not work out of the box in this environment. The bug tracking is a good example of this; having all the bugs just in the backlog simply does not work in a project that has other stakeholders than the team interested in the bugs.

      What comes to automated tests I can only say that they are still a myth and an academic curiosity when dealing with UIs. Many of them, complex ones and inter-operational.

      Don’t get me wrong, scrum and agile development are probably the best tools we have in the fight against failing software projects. But thinking that agile development and pure scrum where the team is isolated and given all the power simply doesn’t work in bigger real life real projects. For small in-house teams, prototyping and such, I would not even consider anything else than scrum.

      So this all boils down to the environment where scrum is being practiced. It all comes down once again to project management; there is no silver bullet and all team members cannot be code ninjas (as scrum assumes).

      But this – of course – just based on my experience and IMHO 🙂