(Page 4 of 4)
BEST PRACTICE #4: EMBRACE SPEEDThe trend to agile is a great thing, said AccuRev’s Hart. “I haven’t seen anyone doing pure agile by the book, but there is one thing in common: quicker feedback,” he said. “If a bug is a story, it’s found right away, as opposed to finding it later during integration, like under waterfall. This greatly reduces the cost of bugs, and I’ve seen defects being treated more as first-class citizens.”
Hart noted that development’s all about going faster and producing more code, while the operations side is about managing risk. “So,” he said, “you want to be able to allow the ops team the ability to say, ‘You know what, we’re real close to pushing a new release to the site, but there’s a critical fix that I need, I want to be able to take just that fix, not last night’s build,’ because last night’s build might include 15 different things, and maybe three or four of those are kind of risky that they want to do some more verification on. If you’ve got everything properly set up and you’re working in a change-based model, and your systems support it, then the ops guy can say, ‘I just want to take that critical fix, just that fix, even though there are 10 other fixes in the queue,’ grab that change and push that into production, mitigating the risk. This will give you a lot more granularity as well as the traceability you’re looking for.
Working quickly and reducing the cost of bugs allows engineering teams to work on tasks that advance the software, according to Atlassian’s Nolen. “When I think about our engineering teams, I think about the ratio between work that pushes us forward and work that is about removing risk. It’s really easy to let that ratio get skewed to where you’re spending 80 or 90% of your time removing risk and only 10% of your time actually building something a customer cares about. So, the way I view it is, if you can find a way to reduce the cost of a bug, you can also reduce the amount of time you spend trying to avoid that bug, because you know that you can fix it very quickly.”
The shorter cycles called for by agile development “address the immediate need, instead of compiling a list of high- and low-priority bugs,” said TechExcel’s Perec. This, he said, frees organizations from the multiple calls of “When will it be fixed? When will it be fixed?”
Agile methods also get developers and QA working more closely, said Perec. “The development team is only focusing on one or two features. This takes pressure off QA, which only has to test the two new features and then run regression tests. Defects are discovered and fixed in the same cycle,” he said.
Axosoft’s Robinson cited another benefit of agile development on defect tracking: “When you’re doing a lot of agile, you’ll be able to solve things so quickly that when you look at the (defect) list, those bugs won’t even apply anymore. They’ll be fixed before they can even be taken off the list.”
Another critical element to reducing delivery time is feedback, according to Nolen. “You want the feedback from the customer to get back into your engineering team as quickly as possible,” he said. “And you don’t want completed code sitting on the shelf essentially wasting value or rotting while you try to organize a release. The faster you can get it out to the customer, the faster you can learn, the faster you can deal with problems or learn good things, like if you find a direction that has been profitable, continue to pursue that. That’s why we think that reducing the number of hours between somebody committing a change and a customer actually seeing it and the developer getting the feedback from that interaction is of primary importance in a healthy engineering team.”
Nolen went on to say that when you deploy faster, you reduce the cost of the bug that you shipped. “If you ship a bug and you know it will be out there in the field for a minimum of two years, then the cost in terms of customers hit—dollars affected—the pain cost is very high,” he pointed out. “If you ship that same bug, and you know that as soon as the first customer hits it you will notice it, fix it and that no one else will touch it, your cost is very low. Which is one of the reasons that Software-as-a-Service is such a great sort of paradigm shift for our industry because it means once you’ve seen the bug one time or two times or five times or however many times it takes to notice, you fix it and no one will ever see it again.”
BEST PRACTICE #5: COMMUNICATE“This might sound trite,” said Alexsys’ Bianchi, “but it comes down to communication. The dev team is not thinking about what marketing needs. It’s important to make everyone’s voices heard.”