×

Ten observations about Agile software development aimed at helping CIOs make the most of this iterative, fast-paced methodology.

Agile software development and its variants—Extreme Programming (XP), Hybridized Waterfall, collaborative development, and others—are hot topics in IT. There's a lot to like about Agile. What started in 2001 with the Agile Manifesto has flourished into a movement: Many software development teams now employ Agile as their default methodology on most major projects.

Yet, despite the rise of Agile, ambiguity and uncertainty still surround it, and many enterprises also struggle to define successful Agile processes or use the methodology to its best effect. The following observations may help guide CIOs as their teams increasingly integrate Agile techniques to benefit their businesses.

Agile is contentious and confusing. Agile has no shortage of fans and haters. Experienced IT professionals have seen these battles before—with databases, operating systems, and object-oriented design. Often, but not always, allegiances divide along generational lines; old guard developers eschew Agile while millennials readily embrace it. Meanwhile, the term itself is sometimes confused with “agile,” an adjective that more generally describes a nimble IT or business organization. Smart developers stay focused on the principles underpinning Agile, and steer clear of ideological debates. In truth, Agile software development comprises many techniques that also show up in other methodologies. Whether it’s called Agile, XP, or Hybridized Waterfall, the objective is the same: improve business outcomes. By selecting those elements of this “trendy” movement most likely to meet business needs, Agile teams can better position themselves to succeed in these efforts.

Iterative development produces better software. While iterative development may not serve every project well, easily 90 percent of the software projects I have encountered could have been better executed if approached more iteratively. As a rule, the longer it takes to complete a first release, the poorer the resulting software due, in part, to changes in business needs during the development period. Continual feedback from the earliest stages of a development project can dramatically improve the end product.

Comprehensive documentation doesn’t trump good design. During design, CIOs ought to allow teams to focus on developing good software even at the occasional expense of concurrently drafting the comprehensive documentation that will be needed later for support. Deliverables are important, but the processes of iteratively learning, adapting, and translating are more likely to improve the designs.

Narrative and visual storytelling help to communicate requirements. Business user stories are fundamental to Agile, and for good reason. Stories can reveal much about users’ biases, expectations, hot buttons, hopes, and fears—along with their actual requirements for the current project. Iterative developers can encourage users to spell out their acceptance criteria (the conditions the software must satisfy) to clarify when software is “good enough.” When possible, translating lengthy testimonials into pictorials can help developers trying to fully understand users’ requirements.

Midstream change is a necessary cost of quality. Traditional software development processes often explicitly limit mid-lifecycle changes in scope, which can quickly derail timelines and budgets. Yes, it makes sense to take all steps possible to get it right the first time. But Agile developers know that well-reasoned downstream changes aimed at improving business outcomes—whether they result from human error, a shift in direction, or another legitimate reason—should be accepted and perhaps even encouraged. Otherwise, resulting software may not meet business needs.

Automating testing and deployment early can yield fewer missteps. Agile often gets mischaracterized as “cowboy” development—write code, deploy, and tend to potential missteps later or never. In fact, Agile projects often rely on test-driven development, in which developers run very specific test cases to help them quickly improve the software prior to writing the actual code. Automated, end-to-end software testing and deployment should also occur during the development cycle, rather than in the week before go-live. Here’s a good litmus test for whether your team is embracing Agile: Ask for their test plan before they start writing code.

Daily collaboration between the business and IT is part of Agile’s secret sauce. The most effective Agile software development projects tend to center on day-to-day collaboration between IT and business teams. Colocation can help spur this teamwork; however, particularly in large companies, physically assembling far-flung developers and business functions on a daily basis is impractical or impossible. In these situations, organizations can turn to the many collaboration and communication tools at their disposal. Desktop VoIP is easy and cost-effective; adding video ups the ante on engagement—no more multitasking during meetings!

Technical details express business needs and can’t be ignored. The business expects software to meet its technical requirements in such areas as response time and uptime—no surprise there. But some Agile practitioners, caught up in the fervor of creating “cool” software quickly, may wait until implementation to worry about the details. Developers should consider these technical specifications to be part of the design process. Creating cool software without also supporting the business’ technical needs is not, nor has it ever been, the goal of Agile, and can even undermine developers’ hard-fought battles to gain acceptance for the methodology.

Simple tools and techniques can effectively model progress. As Albert Einstein said, “Everything should be made as simple as possible, but not simpler.” Because Agile development often follows unexpected dips, peaks, and curves, it can be difficult to convey to stakeholders where projects stand at any given time. But adopting complex modeling techniques, such as Unified Modeling Language, does not necessarily deliver high-quality results. Rather, Agile teams prefer to document user stories on index cards, hold daily stand-up meetings, employ burn down charts that graphically represent remaining work versus remaining time, use online collaborative documents, and employ other such tactics to track and share their progress.

Agile teams should be empowered to quickly make decisions. The goal of Agile is to quickly and iteratively develop quality software. Drawn-out, bureaucratized approval processes can stymie Agile teams’ efforts to expediently correct for mistakes or pursue new paths. Agile teams sometimes err in their initial software development efforts, locate the problem, and fix the issue quickly, and should have the freedom to do so. The more decisions that can be made by the Agile team (which ideally includes the business), the better. And speaking of an empowered team, many developers can and should work collaboratively on the same piece of code; the phrase “So-and-so is the only one who knows that program” is anathema to speed and agility.

*****

As Agile popularity grows, so do the number of opinions about its best (and worst) attributes. As their organizations explore or mature their Agile teams, CIOs should remember these techniques can be used in whole or a few at a time as needs arise, and will likely result in software that is better aligned with the business’ evolving requirements.

—by Ken Corless, principal, Deloitte Consulting LLP

Related Content

“Crowdtesting Expands Manager’s Toolkit”

“9 Myths About Agile”