With the economy tanking, many companies are finding themselves trying to identify ways to maximize resources and operate as leanly as possible. One solution that organizations, particularly those in the software development industry, are exploring is agile project management. Agile has earned a reputation for yielding highly performing teams who can create a product that customers truly want. Over time, that combination of great teams and targeted deliverables does translate to reduced costs and cycle time, but organizations should understand that agile methods are not implemented quickly and easily. Yes, transitioning to agile is a great long-term investment toward becoming sustainably resourceful, but it’s definitely not the answer for companies looking for a quick, painless fix.
Perhaps the biggest reason agile—and Scrum, in particular—can achieve its results is through ongoing communication. Agile’s employment of iterative, incremental work cycles ensures that the customer is continually brought into the development process. Factor in that agile asks developers to produce a potentially shippable increment of work (a functional version of the product, however skimpy its feature set may be) each Sprint and the team is prepared to demonstrate its work for the customer as often as every iteration. Such a short feedback loop prevents the team from blindly pursuing an approach that conflicts with the customer’s vision and, to be somewhat redundant, leads them toward the customer’s particular requirements faster. I understand that those last two points are, in essence, two ways of saying the same thing. But it’s important to understand how agile enables efficiency; it does so by empowering its team—through directed feedback—to do its job effectively.
Sounds great, right? It is, but here’s the rub. In order for teams to begin operating in this way, it’ll likely take time for them to acclimate to these new principles and processes. For example, because agile demands that the team produce a potentially shippable product every Sprint, the team will need to address defects that would prevent the product from being demonstrable for the client. That is, the team would need to fix the products’ bugs in the same Sprint that they’re discovered. That affects how much work a team can accomplish in a Sprint, since now it must perform the additional work of fixing bugs as they pop up. Considering that the number of bugs tends to increase with the size of the codebase, this mandate will force teams to decrease the amount of work they can handle in a Sprint. However, consider the upside. Rather than sequestering bug fixes to the end of the development cycle, the team maintains clean code and always knows where it stands in terms of progress. Rather than a chaotic conclusion to the development cycle, in which the team attempts to patch up all defects in one fell swoop, this approach forces developers to deal with critical bugs before adding more functionality. That will definitely result in more work in the short-term, but, over time, that combination of customer input, frequent communication, and vigilant code maintenance will result in doing more with less.