Perfection is not attainable, but if we chase perfection we can catch excellence – Vince Lombardi
Perfection is a fallacy that leads to over planning, procrastination and failure to ship; agile is about focusing on delivering the best thing possible in a set time period.
Following are few unconventional practices which assisted scaling in the agile transition journey. For each of the practices, related technicalities are not discussed here, with the focus on the practices which were effective keeping the agility alive. These being context based, needs to be delved before reusing
An approach to controlling and managing the hotfixes to the product. This is similar to the Scrum board except that only hotfixes are shown on it. But applying a filter, contents on the JIRA board can be displayed for only hotfixes. This brings together representatives from each affected party (development, QA, vendors, management etc..) and were helpful as following:
- Raises visibility of changes and creep (if any) into the regular release. This way one can plan for feature merge or the code merge at appropriate time in the release cycle, as well. This helps in keeping intact of the fixes in production
- Reduces or controls the number of uncontrolled changes to the product
- This is a data-point in deciding the capacity to be allocated for hot-fixes or in another way, this becomes a factor in deciding the velocity of the sprint
Test Design as part of Backlog Grooming
This is time consuming activity. Note complete test design is not done during backlog grooming meetings, but having test design completed is one of story readiness criteria. Test scenarios in line with acceptance criteria are developed and given as an input to automation team, who them works on developing test cases and scripting as part of automation. This is not 100% complete, however during the sprint execution, testers focus on completing the automation (testing the automation) and executing the automation scripts as part of user story testing.
This helps by
- Integrating testing as part of sprint, (of course detects errors early)
- Avoids rework cost usually which is very high and eats away either the revenue or puts back the user story back to backlog.
It is a fine-grain approach to tracking and control when development and integration is involved from multiple vendors. Mini milestones are agreed by all vendors and tracked keeping in line with ART milestones of the organization.
This is helpful when
- Different life cycle models are adopted by different vendors and for the successful release of my ART one of the component delivered by the vendor getting integrated in the main code. This involves running of integration test , regression and performance test which is not part of any sprint.
- Improves status visibility, eliminates risk of uncontrolled, undetected schedule slippage, improved alignment
- Improved motivation
Separate Sprint for Integration or Outsourcing of integration user stories to external organization
Team of experts prioritizes the development of the interfaces, APIs and changes to the databases and related changes which are required as part of integration. Integrating and testing is done by this independent team and also by the affected sprints as each affected sprint will have one user story to integrate with appropriate acceptance criteria coupled with test scenarios specific to sprint.
- To create a more careful integration user stories and related personas
- Flexibility in sharing of expertise or resources
- Integrations can be made available to the regular scrum team before they start working on the user stories. Integration defects will go back to the integration backlog
Weekly EPIC Level regression testing
This is done in addition to the regular testings in the sprints. This is executed by the centralized test experts who report to the Product Owners. Scenarios developed for each of the user stories are grouped by the EPIC and the customized regression pack is developed for each testing. This helps in ensuring not just the user stories but also purpose of the EPICs are fulfilled
Check-in by Defect
Code related to one defect is checked into the system by all programmers before the build is triggered. Multiple programmers prioritized and fixed on same day, logically even if it is across the sprints (impacted user stories).
Note this is only for defect fix backlog.
Virtualization Services for Testing
In addition of test automation certain business services were virtualized to give the production like environment during regression testing. These are containerized using the dockers which further used by multiple scrum teams for different user stories. This reduced the amount of time taken to test the release.
Reuse of containers is a strategy, to simulate the production like environments for configurations which are difficult to provide either in development or testing
Daily Dependency Call
Daily 5 minutes is dedicated in scrum of scrums to highlight the issues and risks if any originating from the user stories consumed by others scrum teams during integration. This helped in escalating the issues and risks to the Product Managers and making corrections for the release as required.