We have one scrum team (distributed Agile) working on one code base. Due to parts of the team being in different time zones we wanted to divide the one team into two scrum teams. Our model with one scrum team was:
- Create a user story (feature) branch from the develop branch.
- After testing, merge back the user story branch to the develop
branch at the end of the sprint. - In the following sprint, perform the QA test with the integration build to verify there is no collateral damage with the new code.
- It depends on the product owner when to release to the field (we create a release branch when we are ready to release).
Now with the two teams, how can this be handled? Regarding point 3, when QA starts integration testing, how will we know which team's code has caused damage?
Best Answer
Generally, I think the development branch with feature branches tends to work well and scale decently, but I have some concerns that the process you describe is introducing some risk that can be avoided.
First, work should be merged more frequently than once at the end of the Sprint. Maybe for some extremely complex work that is difficult to decompose into smaller, deliverable entities, it can happen from time to time. It may also be more likely in shorter Sprints that the work is done later in the Sprint.
Second, all of the testing should be done within the context of a Sprint. In Scrum, a Sprint results in a potentially releasable product increment. However, in your current state, it takes you two Sprints to have a potentially releasable product increment. In a few environments, independent quality assurance is needed, but in that case, I would recommend rethinking your value stream and Definition of Done to align with how the work actually happens.
Overall, it seems like you don't have a lot of test automation. I would want to increase test automation to reduce the time it takes to get feedback. And this is at all levels, from unit tests on particular methods or classes to automated acceptance tests that simulate human interaction with your application. If you can run these on a regular basis, you can get feedback on if a change introduces a problem before you merge it into the development branch.
Finally, I don't think your ultimate question of determining which team's code "caused damage" is necessary to ask. This is a side effect of having long feedback loops, instead of short feedback loops. And even so, the team that introduced the problem doesn't matter - in a scaled instance, all teams are responsible for the quality of the product. If an issue is found, let the teams pull it into their work based on their understanding of the problem and confidence in fixing it.