Global Agile Delivery Model: Agile Practices in Integration and System Integration Testing Phase

 

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

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

Note: Integration Testing – Interfaces are being tested; System Integration – End-to-End business process being tested

This phase is very crucial due to fact that 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 them to ‘lack of design time’ or ‘refer-this-email-chain’ or at the worst case to compromise on the software engineering practices to do a ‘quick-fix’. Traditionally software development vendors may trim the development team size during the development support phase, which does not help either.

Enough was said on the problem statement, what is the way out? Truly speaking, the solution is yet to be derived. . I have tried to package a set of practices based on my experience that would help us in this context. Each practice is categorized with a specific problem statement that the practice can directly target to solve and provide additional data to help you to decide on using the practice.

Note: If you are getting into 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 Defect Retrospective (practice no. 5) to know the trend and choose the right practice.

1. Defects (Fix) Showcase

Problem Addressed: Too many re-opened defects

Solution description: 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 email to the development lead to review the code changes.
   1. Development lead provides feedback (if any)
   2. Development lead sends an approval email on the code
2. Development sends an email 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 longer time period, but if you trace back the reason for defect re-opening it could be due to the oversight in unit testing and functional (mis)understanding. It will be a worthy effort and in due course of time and, the development team will soon be accustomed to the practice.

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

2. Defects Stand-ups

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

Solution description: This is similar to the daily stand-up with a specific focus on defects. The questions asked in the meet could be:

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

It is on such discussions/meetings we would realize a surprising factor that more than one person would be working on a same defect or someone will be working on a defect that is considered as closed (may be funny but true).

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

3. Defect (Daily) Iteration

Problem Addressed: Too many defects to manage and it appears as if the development team is not making any progress. Team is not being very productive.

Solution description: The worst situation you may want to be in is to have a very-busy testing team and not-so-busy development team. It is absolutely important to work very closely with the development team if you are expecting considerable amount (100, 200 or say 1000) of defects.

You may need to :

• Organize your development team in shifts (to enable fix round the clock defects)
• Have once a day check-point (preferably mid-day)
• Have the defect closure plan as defined below

Date	Start of day	During the Day	Close of Day
Open	Raised	Fixes provided	Currently Open	Closure Plan	Actual Closure	Planned Open	Actual Open
Date n+1
Date n
Date n - 1

• 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 – defects fix/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 bit complex, but once implemented you can experience good and productive results.

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

4. Defect Scrum

Problem Addressed: Too many design Issues or requirement gaps.

Solution description: This is very relevant while you encounter 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 (Defect Retrospective can help here).

This scenario would require the development and design team to call for a 30 minutes meeting to understand the critical / high defects and agree on the implementation. The defects scrum needs to be extended to Product Owner / Business to close the ‘Requirement Gap’.

Suggestion: You need to setup a standard time regularly for defects scrum.

5. Defects (Fix) Retrospective

Problem Addressed: Eliminate unwanted closure codes.

Solution description: Most of the time the defect root cause does not yield valid details due to the various invalid closure code, sometime the list of closure code exceeds the count of defects (may be funny but true). This practice deals with consolidating the defects of all kinds and generating a report on a weekly basis to look at the split-up of defects by closure codes.

This will help you to ensure:

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

Suggestion: See if this process of report generation can be automated.

Global Agile Delivery Model: Agile Accelerators for offshore based Agile Development

Agile development requires strong collaboration. If you are operating a delivery model of 90:10 (90% - offshore and 10% onsite) or similar 80:20 models, implementing the agile practices could be very challenging. To speed up the offshore agile development with a thin onsite team may require some deviation from the standard thought process.

At Virtusa, we create a set of custom process as agile accelerators that will help offshore team to overcome some of these challenges. . The key agile accelerators that benefit the team are detailed below.

Daily Standup-n-Syncup – It is a common habit that the onshore and offshore team discusses on issues only if a formal meeting has been facilitated for them. This gives an appearance that the entire team does not communicate offline. In Virtusa, we extend the daily stand-up meeting by 30 minutes to enable the team members to collaborate on their questions. This pattern of discussion can be followed as routine practice to ensure a proper team sync-up after every stand-up meet.

Sprint Zero – We need to plan for an iteration to receive the required access to onshore environment from offshore. In Virtusa, we engage an Infrastructure Engineer (in addition to the team) at the start of the project (named as Sprint Zero) to identify the IP addresses that we need to access and ensure that the offshore firewall is appropriately configured to access them. The Sprint Zero is also used to setup all the required standard tools as per the customer guidelines.

Leads Scrum – During sprints we may need to take key decisions that may or may not have impact on other teams. Especially in the onshore-offshore model, communication is the key factor to avoid gaps and embarrassments. In Virtusa, we conduct daily leads scrum, in which the representatives of onshore and offshore participate on agreed timings (mostly early morning onshore time). We discuss on key decisions being made and seek help as required. The participants generally include onshore leads, offshore Project Manager, Process Contact and Infrastructure engineer. Once a week, this scrum is convened as a status meeting and the customer is invited to attend.

Agile Process – Many of the current offshore vendors follow proven software practices which align to the CMMi model. While the focus remain on agile delivery, it is important that we leverage the benefits of the mature delivery model the vendor has. In Virtusa at the start of the project, we create a process tailoring record on the key process areas that we adhere in the course of the project. This will be agreed and signed0ff by Project Manager.

The Big Picture – The offshore development team does not find the opportunity to interact with the customer as much the onshore team. Similarly, the onshore team’s understanding on the Business value of the project will be limited. In Virtusa, we engage a Business Analyst to act as catalyst in helping the team to understand the Big Picture of the project, which helps them to prioritize the backlog items. The role of Business Analyst can be performed by a person who has just returned from onshore or sometime the customer itself.

Internal Quality Assurance – It is vital to have an internal quality gate to ensure if the offshore team has understood the requirements as perceived by customer. In Virtusa, we have an internal QA who works closely with the Business Analyst to break down the acceptance criteria as user stories. The internal QA has a dedicated QA machine, which is continuously integrated with SVN. The Internal QA represents the team on Sprint Reviews.

Many of the roles (Infrastructure Engineer, Business Analyst, Internal QA) suggested above need not be a dedicated contact for a specific sprint or project. However, having these roles will have a great benefit in offshore agile development.