In a prior post, I wrote about the relentless pace at which our Agile development moves, especially as it is teamed with delivery of software as a service (SaaS).  One of the consequences of this speed of constant delivery is that there’s never time to go back and “clean up†any of those important but not urgent tasks that you just didn’t get to in the sprint. You know the ones I mean – that last unit test you really should write, fixing a low priority bug, UI tweaks, or automating all of the QA tests.
We’ve found that at the core of this challenge is that the team may not all be engaged simultaneously on the same project. As I work with other Engineering executives, many face the inherent conflict of QA sprints that lag behind development sprints. On the surface, this seems natural. After all, there’s nothing to test until it is written?
We know from test driven development practices this doesn’t have to be the case. Even if not following strict test driven development practices, with careful development story planning, the UI aspects or API stubs can be built first in the sprint, so by the time the QA team has spent a day or two planning test scenarios or preparing test data, they can begin automated test development.
We also find that we need for new code development to stop at some point in the sprint. From that point to the end, developers are only fixing bugs found by the QA team in the sprint, completing those final few unit test cases, taking on usability feedback, and otherwise driving to complete.
By taking this approach, the developers and QA engineers stay together, focused on one goal as a team. That goal is sprint complete of a high quality and finished deliverable. The result is far fewer lose ends, a higher quality product with less rework, and just as important a team that works together.