Get certified - Transform your world of work today

Close

Global Delivery Model - Agile Practices in Defect Fix Phase

9 November 2009

Integration Testing Phase

I am sure most of us have gone through a rough development phase during which we would have considered implementing agile methodology. It is very disheartening to see our favorite project being trapped in the testing phase with a never ending loop of defect fixes and disrupting the whole idea of an agile delivery model.

The defects fix phase starts as the development team completes the coding and unit testing, and moves the code to the integration testing and/or system integration testing phase (Please refer to the figure below)

This phase is very crucial because the software is not yet stable and the test scenarios covered during integration / system integration are wider than the scope of unit testing. Once the defects are logged in large volume, the development team may point to a “lack of design time,” refer to an e-mail chain, or worst case, compromise on their software engineering practices to do a “quick-fix.” Traditionally, software development vendors may trim the size of the development team during the development support phase, which does not help either.

If that is the problem, then what is the solution? Frankly, there is no “one” solution to the problem. I have tried to present a set of best practices based on my experience that will help us address this issue. I’ve included a few example problems; each is paired with a best practice that can help address the problem. I have also included additional information to help you decide on the best course of action.

Note: If you are just entering the defect fix phase, you may want to adopt any / all of the below practices, but if you are already in the defect fix phase, I would recommend you start with the Defect Retrospective (practice no. 5) to better understand the trend and choose the right practice.

1. Defects (Fix) Showcase

Problem: Too many re-opened defects

Solution: This practice would enable the development team to demonstrate the defect fixes to an internal tester (can be another developer) using the developer test cases. The internal tester also runs through the developer test cases and validates the results. Therefore, the concern actually repeats the tests in the development environment independently.

         1. Developer sends an e-mail to the development lead to review the code changes.

                          a. Development lead provides feedback (if any)

                          b. Development lead sends an approval e-mail on the code

         2. Development sends an e-mail to internal tester (another developer) for a defect fix demo.

         3. Internal tester reviews the defect fix and approves it.

         4. Developer checks in the code on continuous build server.

This practice initially appears to consume more time, but a defect re-opening could be due to an oversight in unit testing and a functional (mis)understanding. It will be worth the time and effort, and the development team will soon be accustomed to the practice.

Suggestion: Choose the best person with domain knowledge for the internal tester role.

2. Defects Stand-ups

Problem: Lack of prioritization on defects and defects fixes span across multiple vendors.

Solution: This is similar to the daily Scrum, with a specific focus on defects. The questions asked in the meeting could be:

  • What defects have you fixed from yesterday to today? (defect – id and description)
  • What defects are you planning to fix today? (validate the priority)
  • Are there any issues that prevent you from fixing these defects?

During these discussions/meetings we could discover that more than one person is working on the same defect or that someone is working on a defect that is considered closed.

Suggestion: Update your defect- tracking tool after the stand-up.

3. Defect (Daily) Iteration

Problem: Too many defects to manage, and the development team is not making any progress. Team is not being very productive.

Solution: A worst case scenario involves a very busy testing team and a not-so-busy development team. It is absolutely important to work very closely with the development team if you are expecting a considerable amount (100, 200 or say 1000) of defects.

You may need to :

  • Organize your development team in shifts (to enable 24-hour fixing)
  • Have a daily progress review (preferably mid-day)
  • Use a defect closure plan as defined below
  • Date column: The latest date will be recorded as the first entry (insert a new row at the top)
  • The ‘During the day’ section tracks the defects fix velocity as defects fixed per day. It can be used to measure the testing velocity as well
  • The ‘Close of the Day’ section tracks the development team’s ability to maintain the velocity by tracking themselves towards planned and actual closure

It may look complex, but once implemented you can experience good and productive results.

Suggestion: Leverage the test manager to update and circulate the template

4. Defect Scrum

Problem: Too many design Issues or requirement gaps.

Solution: This is relevant while you deal with critical or “showstopper” defects, which are marked as ‘Design Issue’ or ‘Requirement Gap.’ You need to pay special attention and monitor the situation very closely (a Defect Retrospective can help here).

This scenario would require the development and design team to arrange a 30 minute meeting to understand the critical defects and agree on the implementation. The defects Scrum needs to include the Product/Business Owner to close the "Requirement Gap."

Suggestion: You need to establish a standard time for a regular Defects Scrum.

5. Defects (Fix) Retrospective

Problem: Unwanted closure codes.

Solution: Often, the defect root cause does not yield valid details due to the various invalid closure code, and sometimes the list of closure code exceeds the count of defects. This practice deals with consolidating defects of all kinds and generating a weekly report to review the spread of defects by closure code.

This will help you to ensure the following:

  • All defects are closed with a valid closure code
  • Logical grouping of closure codes – e.g. Invalid data, corrupt data, wrong data can be classified as invalid data
  • Take corrective actions to avoid recurring defects – e.g. Identify the reasons why we have invalid data

Suggestion: See if this report can be automated.

About the Author

Vetrivel Shanmgasundaram is a Senior Architect and Agile Consultant in Virtusa. Vetrivel has over eleven years of extensive experience in providing technical leadership to the analysis, technical architecture design, development and delivery of products and solutions across various domains. He is currently involved in delivering high risk projects based on agile methodology.

 

 

 


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: 1.5 (10 ratings)

Comments

Sanjay Sudhakar, CSM, 11/10/2009 1:20:47 AM
Fantastic showcasing of realistic problems and practical solutions in the current environment.
Regards,
Sanjay
Senior Agile Consultant
David Sabine, CSP,CSD,CSM,CSPO,REP, 4/6/2016 2:16:47 PM
Hello Vetrivel,

I respect that you have published your ideas -- it takes courage to share and I appreciate that.

However, I am writing to say that I have rated the article 1 out of 5 and I wanted to explain my rating:

1) Your article is focused on the symptoms of low-quality work (i.e. defects) and does not address the root issue at all -- that is: stop producing defects.
2) You have used phrases in the article like "the defect fix phase" and "the Defect Retrospective" and "the testing team". Those are not elements of the Scrum framework and, actually, Scrum explicitly dissallows such things: from the Scrum Guide, "Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule".
3) Scrum requires the team to create potentially-releasable product increment every Sprint -- as this relates to your article it means that (a) software with ZERO defects is potentially-releasable (b) and all activities of product development are happening within the team every Sprint and not in phases -- testing, design, and implementation occur continuously within the Scrum Team every Sprint. If defects are produced during implementation.
4) You have described ways to inspect, track, and report defects in a system -- the activities you describe are extremely time-consuming. The Scrum Guide contains this wonderful sentence: "inspection should not be so frequent that inspection gets in the way of the work". The inspection and reporting of defects in your process is apparently getting in the way of the work. Perhaps I am just pointing out the obvious, but, spend less time tracking defects and more time producing high-quality code. Stop the sequential "phasing" of the development activities -- there's never a "Defect Phase" or "UAT" period in Scrum. Instead, quality is utmost concern of every Scrum Team member -- continuously.

Overall, the contents of your article indicate that the work you're involved with is literally NOT SCRUM and the advice offered in the article is not likely to help readers to evolve toward Scrum. That is basically the reason for my low rating of your article. Perhaps you would consider publishing the article with Project Management Institute instead.
David Sabine, CSP,CSD,CSM,CSPO,REP, 4/6/2016 2:34:13 PM
Hello Vetrivel,

I respect that you have published your ideas -- it takes courage to share and I appreciate that.

However, I am writing to say that I have rated the article 1 out of 5 and I wanted to explain my rating:

1) Your article is focused on the symptoms of low-quality work (i.e. defects) and does not address the root issue at all -- that is: stop producing defects.
2) You have used phrases in the article like "the defect fix phase" and "the Defect Retrospective" and "the testing team". Those are not elements of the Scrum framework and, actually, Scrum explicitly dissallows such things: from the Scrum Guide, "Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule".
3) Scrum requires the team to create potentially-releasable product increment every Sprint -- as this relates to your article it means that (a) software with ZERO defects is potentially-releasable (b) and all activities of product development are happening within the team every Sprint and not in phases -- testing, design, and implementation occur continuously within the Scrum Team every Sprint. If defects are produced during implementation.
4) You have described ways to inspect, track, and report defects in a system -- the activities you describe are extremely time-consuming. The Scrum Guide contains this wonderful sentence: "inspection should not be so frequent that inspection gets in the way of the work". The inspection and reporting of defects in your process is apparently getting in the way of the work. Perhaps I am just pointing out the obvious, but, spend less time tracking defects and more time producing high-quality code. Stop the sequential "phasing" of the development activities -- there's never a "Defect Phase" or "UAT" period in Scrum. Instead, quality is utmost concern of every Scrum Team member -- continuously.

Overall, the contents of your article indicate that the work you're involved with is literally NOT SCRUM and the advice offered in the article is not likely to help readers to evolve toward Scrum. That is basically the reason for my low rating of your article. Perhaps you would consider publishing the article with Project Management Institute instead.

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

Subscribe