Scrum/Agile demands frequent delivery of software. Most of the companies develop software in a sprint of two weeks. (How to choose Sprint duration?) But many companies don’t release software that frequently. According to scrum principles software at the sprint end should be of shippable quality. But really is this the case? Many teams who diligently deliver the software periodically complain that because of frequent release they are not able to fix all the bugs. Because of the number of bugs they have an affinity for longer sprint cycles. But in reality there is no co-relation between the sprint duration or release duration and the quality of the software produced after each sprint.
Slow down to move fast
If you or your team is in a vicious cycle of releasing software with bugs release after release – then stop what you are doing, review the process you are following
- Review the definition of “done” – Schedule a meeting with all stakeholders, decide on a definition of done. Only thing you have to remember is that after the sprint cycle customer should be able to use the software
- Too much content – If you deliver about average of 5 user stories per sprint cycle reduce it to 4 or 3. Then apply the definition of done.
- Responsible for quality - Ultimately it is the PO who is responsible for the quality of the application but then that don’t mean that others can’t question the bad practices. There is no value in delivering a software with low quality, be if bug or performance issues. If you allow such practices to continue one day you will realize that you have more than 100 bugs to fix or application is performing so badly that customers have stopped using it altogether. Such drastic results or consequences don’t happen in one day they occur because of the continuous negligence of the good practices day after day, sprint after sprint.
- Existing technical debts – There will be many cases when you inherit an old legacy application with lot of bugs and performance issues. You may be asked to deliver new features in every sprint. This is a very tricky situation which needs some careful analysis and thoughts.
- Talk to the customers and stakeholders – identify the most important issues for them and create (& implement) a plan to solve them
- If a new feature is requested in the “problem” area inform the stakeholders about the dangers of making changes in those parts. Get a commitment from them to improve the areas. Try to convince them with figures. Few weeks back I produced an excel sheet with the hours spend in bug fixing one area of our application. The hours spend in bugs fixing was very high. It required only a fraction of that time to clean up the entire area.
Some Additional links worth reading.
- Scrum quality – Teams not delivering high quality stories; testing not complete during sprints
- Scrum Sprint duration – which is ideal; 4 weeks or 2 Weeks or 1 Week? Checklist -
- The Benefits of Regular Deployment - https://www.simple-talk.com/opinion/opinion-pieces/the-benefits-of-regular-deployment/