Get certified - Transform your world of work today


Managing Defects in Agile

The role of the product owner

13 January 2016

Manojeet Chatterjee
L&T Infotech

Product owners, who also manage the cost of the product, frequently ask, "Why should I pay for bugs? The team introduced the bugs I did not ask for. It's their problem, not mine. I am not paying for it. I am ready to do it next sprint, but only if they commit to velocity as before." Have you heard this?

Waterfall bugs

Defects (or bugs) in software development create anxiety that leads to stress and instability within the team. This environment could potentially lead to more defects than anticipated. The blame game takes the front seat of the project, and the situation could get well out of hand rather quickly, if not contained.

The "defect panic syndrome" is prominent in Waterfall. It manifests into this likely scenario: The end user finally sees the product after a long wait, a few rounds of requirement-gathering sessions, and some design discussions. In the meantime, users are too busy with their regular jobs to reply to some email queries from the development team or business analysts. Finally, when they see the product completed just before user acceptance or during user acceptance, they want it to behave as they thought it should. But it does not and so the defect panic syndrome flares up.

Users start reporting defects, and the team begins to fix them as they arise. The project team was expecting few defects. They thought the time set aside for fixing defects was more than enough, but when users start testing, the fixes uncover more defects. Some defects affect the core design of the product, which unsettles the development team. They come up with some work-around overnight that could work as a patch. Time is running out, and the project manager announces that project funds are depleting, and soon this will be a major escalation, as the project might need more funds to keep it going.

The blame game starts now. The defects are categorized further to determine the team responsible for this known catastrophe. If multiple vendors are involved, we know where we are heading. At some point, the project manager has to prevent the teams from blaming each other and get the user acceptance completed as soon as possible.

I could go on, but this is a typical scenario of a Waterfall project. Readers might be thinking that defect prevention should be better, more learning should be sought, design flaws should be studied to deepen the teams' understanding of the subject, and so on. All of these are very good ideas, but by this time, it is too late in the game.

What answer should I give the product owner?

Product owners need to go through a paradigm shift. They need to be told the following:

Why should I pay for bugs? The team introduced the bugs that I did not ask for. It's their problem, not mine. I am not paying for it. I am ready to do it next sprint, but only if they commit to velocity as before.
In Waterfall, stakeholders are so removed or disconnected from the rest of team that most of the time, the us-versus-them culture is fueled. The beauty of Agile is that we all are a single team. This philosophy is so important to uphold in an Agile environment that I cannot stress it enough. It is the team that fails and not the individuals. We start with short sprints, and at the end of each sprint, we do a retrospective, including reflections on defects. We try to find the root cause of the defect and put in some measures to eliminate it.

The whole team matures with the process, including the product owner, who also realizes some problems arose because of how stories were being explained in different ways (e.g., more wireframes). These can help the development team grasp the functionality really well. Also, the team gets the functionality in piecemeal fashion, and this helps them focus on the work at hand. This is just the beginning of the benefits that a team can realize by holding the Scrum retrospective religiously. The product owner might realize that although the requirements were written for the Waterfall method, there was no way to mature the requirements the way he or she was able to do with the Agile process.

It's very important to realize that you can spend hours writing a perfect requirement, but it will take a fraction of that time to bring it to life as a working product increment in Agile. The team would move quickly to build what the product owner explains to them, and then if something is missed by the product owner, the development team picks it up in the next sprint.

If the team is hard working and produces enough quality stories, the product owner will have nothing to complain about. But if there are always gaps in the work product, then experienced ScrumMasters should streamline the process and try to eliminate such issues during the early sprints. We are at the beginning of the project, and this gives enough time to every one to inspect and adapt. If a team member is not capable enough, this incapability will also be exposed early in the project stage, and appropriate actions can be planned.

Why should I pay for bugs? The team introduced the bugs that I did not ask for. It's their problem, not mine. I am not paying for it. I am ready to do it next sprint, but only if they commit to velocity as before.
It could be a problem if the product owner has no project experience and starts directly with the Scrum team. I find it useful to go over some previous Waterfall challenges in the organization (trust me, they're not difficult to find), and try to explain, logically, the failure points. It is always good to keep new product owners updated on defect management in Agile, and why the effort is so useful because it helps avoid seeing defects at the end, when more damage is done.

Maybe a defect-free code could be written (eliminating human error) if a perfect requirement document could be drafted. First, it would take ages to build something fascinating like that, and second, a perfect requirement or design document is a myth. There are always ways to improve it and make it readable for all involved parties.

The price that product owners are paying for defects during a sprint is infinitely small in return to what they are receiving — a shippable, working piece of software.

Last but not least, everyone should understand that development without defects is also a myth. There are numerous examples whereby the best of the best have introduced bugs, sometimes as simples as the metric conversion that derailed the Mars Climate Orbiter NASA project, the Pentium chip that had failed math, and AT&T's failed long-distance calls that lost $60 million. But this does not mean that the team is free to introduce defects.

This is the beauty of inspecting and adapting. Some, but not all, major causes and recommendations are highlighted below:
  • Lack of system knowledge. Contact the product owner for clarification during the sprint.
  • Lack of technical knowledge. Organize proper training for the members. (Some organizations value skill upgrades and request planning for such training.).
  • Lack of motivation. Multiple factors exists that cannot be discussed here, but they could be resolved by experienced ScrumMasters.
  • Lack of testing time. Sprints are not correctly organized and planned, which should be looked into more closely. The sprint backlog is not planned well for execution.
  • Lack of coordination. Waiting on another team at the last moment. This is typical, but a good ScrumMaster can time some of the critical activities in the previous sprints that are heavily dependent on the next sprints.
I hope this article helps clarify the concept of defects in Agile. Agile is about learning, so please let me know if you have anything to share.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.9 (7 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up