Are your current error management practices slowing your team down? If you are using agile methodologies in your organization, it’s likely that:
This works well for most processes in your software development team. However, when it comes to your error management process, history and technical debt can inevitably pile up. Error logs become full, and important issues impacting users get swept under the rug – or even worse – missed altogether.
There are plenty of resources on agile frameworks and which one is best for your team. However, one thing that agile frameworks don’t talk about is how to best deal with software bugs that affect end users, slow down your site and negatively impact revenue.
Today, I’d like to share a few common problems in agile practices teams encounter when it comes to error resolution, plus a how to make things a little smoother using your tool kit.
‘Being agile’ relies on the ability to make fast yet calculated changes and decisions. So our error management systems have to follow this philosophy. To make our bug finding process more efficient, we need more information on errors and where they are exactly. And we need it quickly.
So, how can we adapt our current agile practices to ensure bugs don’t fall through the cracks, and our errors are found and dealt with quickly?
I’d like to focus on four ways software teams can adapt current agile practices to make bug resolution easier and faster.
If a development team pushes code into production and relies on tests and a QA processes before deployment, it could be falling on your customers to find and report problems they encounter.
Unfortunately independent research found that only 1% of users actually report issues.
The best thing we can do to prevent revenue loss from errors is to have processes in place to both find and respond to errors before users even notice. How do most companies achieve this?
Rigorous testing before deployment is certainly one of the best ways to maintain a company culture of producing quality code at all times.
Buggy software means customers are having a poor experience – and as team leaders it’s our job to make sure that doesn’t happen.
We can make the process a little easier by using our agile processes together with a continuous deployment strategy. For example, our friends at Raygun, discovered that “when a team gets locked into a sprint it can become much harder to recognize and fix bugs”.
“Therefore, we actively avoid locking all but the lowest priority errors into sprints – rather we have time set aside inside our sprints to allow us to find errors and fix them on the spot. This way, it doesn’t affect our sprint work, and issues get addressed as soon as they come up, rather than waiting for an end user to find them.”
The most important takeaway is to always keep your code deployable. By always keeping your master branch matching your production code, you can fix a bug and deploy knowing that other ongoing fixes and features aren’t creeping into a bug fix deployment.
Errors do slip through the cracks. Understanding how best to manage these errors and the customers who become affected is an important part of the error handling process.
It’s not always easy for developers to replicate issues for customers so they can be fixed quickly. So sometimes errors do get lost in communication.
This is especially true for last minute fixes and changes. When we ‘tweak’ code, inadvertently introducing errors becomes much more likely. Especially when there are strict deadlines to be met.
Keeping your whole team looking at the bigger picture (from coding right through to how the user is experiencing the software) helps the dev team communicate with support so they can get information to customers quickly and effortlessly.
In agile methodology, traditionally bugs may appear on issue tracker backlogs or within your agile management tool as tickets/tasks.
When tickets get assigned, the error can remain unsolved until deeper diagnostics on the issue are discovered.
Getting full contextual information on an error is extremely difficult unless you have crash and error reporting software.
Hands down, this is the biggest time saver and the best way to resolve errors in your current agile methodology.
Most crash and error reporting software will pull extremely detailed information on location and damage caused by errors that slip through the testing process. Using a tool like Assembla to deliver that information to a team member cuts the time in the communication process.
If you have allocated time in your sprint to errors rather than locking in fixes, there’s still hard work to be done by your team. However, having the correct tools in your toolkit will greatly improve.
Because of the flexible nature of agile practices, lots of small, last minute changes can be introduced into a developer’s workflow.
This usually means two things:
Unfortunately, recurring bugs and ‘minor’ fixes are still affecting end users – someone is still getting a poor experience of your application.
Staying on top of the errors inside your agile workflow is critical – which comes back round to practicing test driven development.
Every bug is a chance to build a test. If you find a bug, write a test! This prevents recurring bugs and keeps the culture of producing quality code in your team strong.
Ridding your agile workflow of bugs doesn’t have to be hard – and it’s a critical factor in your success.
The agile methodologies that have made the development process faster and better have left many dev teams grappling for ways to handle their bugs within the agile framework.
However, it’s your agile toolkit that will provide the biggest leverage when it comes to staying bug free.
Managed properly, fixing bugs doesn’t have to be a massive task, taking valuable development time. The process can – and should – fit seamlessly into your current agile practices.
We’ve helped many companies in many different industries cut down their error processing time. There is never a one-size-fits all approach to becoming an agile bug-beating superhero. – but it can be done!
