It's difficult to explain the concept of bugs in software without going through the development cycle first hand. One of the better ways to think about it is through the lens of testing. During the planning and design phase of a project there is an anticipated user flow. The software application is designed to lead users through that flow. As a result, that is the way it is tested. Unfortunately users don't always interact with an application the way we originally envisaged. For example they might return to the home screen when we expect them to submit a payment.
Because it's impossible to know every variation of how a user will interact with the application, there will always be bugs. Bugs also occur when third party frameworks (eg. Chrome, iOS, Android) are updated, so what used to work as expected, no longer does. Don't worry, there are measures that can be taken to reduce the number of bugs and raise the quality of the software. WorkingMouse does this through a process called trim the tail.
Trim the Tail
The trim the tail allowance is used to add a chunk of time into the project to account for any bugs or minor improvements which may pop up. Experience has shown us that every project requires periods of cleaning up time where the team needs time to pause on active development and instead focus on the work they have already done. The irresistible urge is to block out 6 weeks of development time and spend the entire time developing new features. So what happens next?
Case Study: What happens when there's no Trim the Tail?
Before the Way of Working was created, there were projects that did not allocate a period of time to quality improvements. One particular project had originally planned to spend the last few days of development on bug fixes and raising the quality. However due to delayed user acceptance testing, change requests were thrown into the trim the tail (Iteration N) period. Quality improvements were prioritised below new changes. This had repercussions when the application was released into a production environment. These weren't detrimental to the performance of the software but it did damage the user experience. Consequently it was the support mechanism of WorkingMouse - Rogue Two that had to 'save the day'.
Changes
Implemented within the Codebots Way of Working is a trim the tail factor. The trim the tail factor calculates a period of time which can be used throughout the project's timeline. This creates a bank of time which can be drawn from at any point in the project's timeline. When the team lead and the customer agree it is required, the standard development progress can be paused, and the team can enter into an Iteration N. The length of this iteration can vary depending upon the amount of work which is required. This period of time is then taken from the bank and the running tally is updated.
Through these learnings we defined a recommended factor that should be applied to every software project. Currently, the trim the tail factor is calculated as a 1.25* multiplier on the time estimate (including risk and allocation factor).
Case Study: Using Trim the Tail to your advantage
Tool Protect is an application designed to help tradies keep their tools safe. The App was turned around in under 5 weeks which doesn't leave much time for extensive testing. With the Trim the Tail factor applied at the end of the project, it was successfully completed and capable of accommodating a large influx of users (after receiving a feature story on Channel 7 News). Since then the application has also launched in New Zealand. It is currently managed and supported by Rogue Two.
As mentioned earlier, the factor calculates a period of time. This time can be taken at any stage during the development period. The reason it is called trim the tail is because we want to move away from one big allotment of time at the end of the project.
Case Study: Don't wait until the end
One of the most common mistakes is to wait until the very end of a project to conduct all quality improvements. For small projects/minimum viable products, this may be acceptable. However, the longer a project is anticipated to take, the more bugs/defects that might arise. A project that was completed before the Way of Working waited over 12 weeks before designating time to quality improvements. This left a large backlog of bug fixes that impacted on the teams productivity during feature development iterations. The learnings that came from the project suggested that iteration n (dedicated to quality improvements) need to be taken incrementally during a project.
To summarise, there is no silver bullet for bug-free software. But there are methods and tactics that can be used to raise the quality. Use the factor of 25% as a starting point. Every 4-5 weeks of feature development may require one week of iteration n. Trim the tail so the problems don't pile up at the end.
