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.

Scrum for your project – Yoga for your body & mind

After completing couple of years of daily practice in yoga, I could greatly appreciate the benefits that yoga provides. Having spent few years in implementing agile delivery model to various projects, I find a great deal of similarities in the structure and principle between Scrum and Yoga. Both of Scrum and Yoga are designed to deliver success.

Let’s take a closer look at the various aspects of these similarities

Product

The product in the case of yoga is your body. The product backlog is the list of ‘negatives’ that you carry in your body & mind. Backlog items or the ‘negatives’ could be physical problem or issues related to mind.

Roles

Product Owner – You are the owner of your body, so it is yourself!

The Team – It’s all your body parts, the hands, the legs, the head, the chest… (Imagine the level of collaboration!)

Scrum Master – your brain – serves and protects (so you do not break your joints) you during the class. Who can take more interest on yourself other than you!

Sprint

It is a daily sprint – your yoga classes. You would want a daily frequency to get your backlogs (negatives) cleared as early as possible!

Sprint Goal: To be Happy

Sprint planning meeting: Prayer in each class where you make the commitment to end your ‘negatives’. You also commit to not to add more items in the sprint till you clear the existing items (obviously you would not want more problems!)

The Scrum Cycle in Yoga

As a product owner you demand that you need the best fit body (product). You have a list of negatives (product backlogs) of which some of it you commit to a particular yoga class (sprint) . You want your body parts (the team) to work collaboratively to complete the asanas (tasks) that will help you get the best body (product).

Your Brain (The Scrum master), serves and protects you in each of the asana (task) by helping you removing the resistance and help you get through them. The more the collaboration of your body parts (team) the smoother completion of asanas (tasks)

Retrospective

As this is recommended to do in a more relaxed environment, in yoga you do those in more relaxed position (savasana) . You decide on the action that you can improve on the next sprint (yoga class).

It is very interesting to notice the practices of scrum which are adhered in yoga – tells a great deal of proven practices of Scrum. So get out and get yourself some Yoga and Scrum.