Agile Programming

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.

Posted: December 19th, 2008 under Agile Programming.
Comments: none

As I read Ty Kiisel’s recent post on Projects@Work, (http://www.projectsatwork.com/article.cfm?ID=246384) I couldn’t help but notice that the strategies he endorsed to help companies do more with less are many of the same strategies that agile uses to help teams become more efficient. Kiisel writes, “Continuous improvement in any market is the life-blood of a successful organization—improving processes and increasing efficiencies are even more important if the economy heads south.” Of course, he’s right. But reading that, I immediately thought of how agile methods, such as Scrum, literally build innovation into their processes. Because agile methods approach work incrementally (in chunks) and iteratively (in regular cycles, known as sprints), teams have the opportunity to build products that their customers want while improving processes. Let me explain. After each sprint has concluded (sprints are typically between two- and four-weeks in length, but always the same length), the team gets together for the Retrospective Meeting, where everyone assesses their performance in the previous sprint. What went well? What went poorly? What improvements could be made for next time? This meeting provides the team with the chance to focus on how they’re working together, not the final product. Dedicating time for this ongoing process of self-evaluation means that the team is always striving for improvement, refining how it works to become more and more efficient. And while this process is typically relegated to the team level, there’s no reason management couldn’t implement the Retrospective Meeting on an organizational level: to make sure that the company is doing what it can to maximize its resources and reduce waste. That’s the sort of measure that leads to success, whether it’s business as usual or the economy is tanking.

Posted: December 19th, 2008 under Agile Programming.
Comments: none