How Quality Feeds Agile Flow
Everyone wants to be Agile. It’s the key to success! A lot of organizations claim to be Agile, but are they? If your team went to Agile training and came back to work with new ways to define their work, you probably aren’t Agile. You’ve just learned new terminology to wrap around your current behaviors.
Agile is about making work flow, and the only way to be fluid is to build quality into your software from the ground up. There are three quality behaviors present in every successful Agile shop.
Test New Functionality Immediately Upon Completion
When testing occurs right away – either manual or automated – defects are easier to fix. The developer was just working in that code so nuances of how the code works are fresh. Another simplifier is that additional code has not been built on the code under review, reducing the risk for potential collateral damage to almost zero.
The final value in immediate testing is that the whole team benefits from working on a stable code base. New defects are easier to trace to the root cause because there are not a myriad of old defects creating misdirection.
Write Automated Tests – Unit and System – For All New Functionality
This is arguably the most important skill to have on your team. It is not enough to kick off a bunch of scripts and call it automation. Robust automated test suites are carefully designed and limited to one feature. There are no dependencies on anything outside of the feature under test.
It is realistic to expect that writing good automated tests will take as long as it takes to create the code. There will also be maintenance required, but the time spent on maintenance can be minimized by a skilled automation expert.
Don’t get hung up on the up-front and maintenance costs. Those tests will run over and over again, creating value each and every time they run. This up-front investment pays off every time a developer makes a change and wants the assurance that nothing was broken. Effective automation is critical to Agile fluidity.
Avoid the Defect Backlog Trap
The first behavior mentioned addresses the importance of finding and fixing defects early. The problem is that teams tend to come up with all kinds of reasons for postponing a defect fix – and the reasoning can seem sound at the time. But if you want to be fluidly Agile, don’t fall into the trap of deferring defects.
Three common reasons teams have for deferring defects are these:
It will take too long to fix it now.It is not critical or high in severity so it can wait until later.This is a corner case. Most customers will not experience it.
In a perfect world, we would fix every defect found – but we don’t live in a perfect world. We live in a fast-paced, competitive world. Time is money. Resolving defects does not mean fixing defects. It means deciding what to do about each defect as it is found.
If a defect is important enough to fix – either now or later – fix it now. The cost of fixing it will never be cheaper. It might take some time, but that cost will pay for itself over and over by reducing the churn inherent in having a defect backlog.
If a defect is one you will fix if there is time later, have the courage to close it now and be done with it. If you don’t have time to fix it now, you won’t have time to fix it later. Document the reasons why the team has chosen to close the bug to allow for a teachable moment if the defect returns in a different context that is more serious later. When you understand why it was closed out incorrectly, the team can learn from the experience and not make that mistake again.
Defect backlogs steal your time because unfixed defects contribute to a code base that does not work correctly, making the working environment less stable. You also lose time every time you look through the backlog. The waste of having a defect backlog is captured in the phrase, “death by a thousand papercuts.” You pay the cost multiple times a day with no recognition of the overall negative impact to the team.
Let the Work Flow!
Make your software development environment fluid by testing new/revised functionality as soon as it is ready, automating your tests, and resolving defects soon after they are filed. When quality is not an inhibitor, creativity and value can flow. That’s what Agile is all about. Without technical debt, developers can create code on top of a stable code base with confidence, knowing that any cool trick they try will be quickly tested and validated. Don’t try to take a short cut to Agile outcomes with less than Agile behaviors.
How healthy is your agile team?