 |
|
|
|
| David Christiansen | |
|
|
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Agile iterations are nearly always defined around a set of features that are going to be built in a short period of time. Those features are described in various ways -- my favorite is user stories -- but they almost always end up being some simple description of what the application can do. This focus on the "what" of software development is born out of the agile principle of continuously delivering working software, and it results in rapidly emerging software solutions that actually work and make customers happy. This is perhaps the most visible benefit of agile software development: Customers get to see and re-direct the work product much sooner and more frequently than is typical of other software development approaches, particularly those that are heavily front-loaded with analysis and design.
Some agile practitioners -- and sadly, some agile coaches as well -- make the mistake of focusing too exclusively on that one particular agile principle. They neglect other very important aspects of agile software development, specifically:
- Sustainable development
- Attention to technical excellence and good design
- Regular self-reflection as a team
Ignoring these agile principles has a powerful negative effect on a project that builds with each iteration. If not addressed, this effect will grow until it becomes a significant obstacle to continued development using short iterations.
There are two symptoms of "iteration myopia", which are out-of-control technical debt misuse of subject matter experts. Let's look at these problems and steps you can take to overcome them.
Technical debt is getting out of control
The most common symptom of this problem is a growing sense of "technical debt" on the project team. Technical debt usually starts out as an ominous feeling that there is a lot of "stuff" that needs to be "cleaned up". A retrospective is a good touch point for discovering technical debt because developers, testers, and project managers will often say something like "I'm glad we shipped feature X, but I wish we'd had more time to do it this way."
Another indication of growing technical debt is a high or blown estimate on a story that requires significant re-factoring of existing code. When it's really hard to force the existing code in a new direction, possibly because of shortcuts taken earlier or because you're afraid you will break it, then you've found technical debt.
What should you do about technical debt? The same thing you should do about credit card debt: stay out of it. If you get into it, pay it off.
Here's how to stay out of technical debt:
- Code is NEVER finished until all the appropriate automated tests are in place.
- Run all of your tests at least once a day, preferably every time a change to the code is committed.
- Never leave a build broken for more than a few minutes. When the build fails -- i.e. one or more of your automated tests fail after a code commit -- fix it right away.
Getting out of debt requires understanding how you got into debt. Was it the result of developer laziness, schedule pressure, or ignorance? Whatever the cause, the fix is going to require you to set aside time for paying off technical debt. Put it on the calendar and do it - use the time to write the tests you need, clean up old code, or otherwise remove the problems that keep you up at night.
Subject matter experts aren't testers
You just released your awesome new product to real users at the end of a release and right away a user finds a critical flaw in the software. As you review the bug report, you feel your neck and ears turning red, because it's an embarrassingly obvious bug that is going to mean a 10-minute fix and a late night emergency deployment. Why didn't it get found by the subject matter experts who tested and subsequently accepted the story this bug applies to?
Subject matter experts (SMEs) are wonderful assets to an agile team. They write stories, prioritize them, test them, and accept or reject them. The feedback they give an agile team during an iteration goes a long way toward making your software work, but they are not a complete strategy for application quality. If you rely entirely on them to find all your bugs, you will have post-production quality issues. You can avoid those problems if you accepted a simple truth: Subject matter experts are not testers, and they will not find all of your bugs.
You can fix this problem easily enough: get a tester and make their testing a formal step in a story's implementation. The best tester for an agile team is one who is skilled in exploratory testing, also called session-based test management. The worst tester for an agile team is one who requires written scripts.
A good tester can keep up with about four-to-five developers on a typical software project. It's important that you have a good system for keeping track of which stories have been tested and which have not. (See my article on free tools for agile testers for a product that's great for this). After a developer delivers a story, the tester should be expected to test and either accept or reject it, just like the SMEs do, but a step ahead of them. If you are having quality issues on your agile project, including a highly skilled tester in your iterative development process will help dramatically.
David Christiansen is a senior developer at Collaborative Software Initiative and the founder and managing editor of TechDarkSide.com
This was first published in November 2009