Mastering Agile Development Practices

Source: Dice.com

Tired of traditional software development methodologies, command-and-control management styles, and juggling multiple projects at once? Consider agile development, which delivers functionality in rapid iterations — measured in just weeks — and eschews heavily designed projects for frequent communication, development, testing, and delivery. Sound like chaos? Find out if “agile” is right for you.
- By Mathew Schwartz

Are your software development practices “agile”?

The agile software development discipline focuses on rapid development and frequent customer contact to create software of maximum relevance to customers or business users. In the agile world, working software doesn’t have to include every possible feature — just to meet a customer’s top needs. Updates will introduce further high-value functionality later.

By contrast, “traditional” software development frequently involves a so-called “waterfall” technique. Waterfall projects move through clearly defined stages, from capturing requirements, to analysis, design, coding, and then testing. Each step produces so-called artifacts — for example, design documents during the design process, and code reviews during testing.

How does agile differ? “Agile tries to shortcut the process, and really get to the essence faster,” says Ryan Martens, founder and chief technology officer of Rally Software Development Corp., which offers agile software development and requirements management products and training. “Because by the time you’re done with a nine-month project, the competitors and requirements have shifted, and you may need to go and build another completely new product. Because what you thought was strategic? That was six months ago.”

Accordingly, Agile’s core tenet is, “Do only what you have to do to be successful,” notes software requirements expert Dean Leffingwell. Thus the less methodology — and the smaller the plan — the better. “Every unnecessary process or artifact slows the team down, adds weight to the project, and diverts time and energy from essential coding and testing activities.”

All About Agile
What exactly is agile software development? The term loosely applies to a number of development methodologies that gained popularity in the late 1990’s, including Scrum, Crystal Clear, and Extreme Programming. While each methodology has its own nuances and approaches, all have in common using small (5-9 people) teams, which are co-located and cross-functional. Thus developers, QA testers, and technical writers often work on the same team. Agile teams also deliver project features in “timeboxes” — fixed iterations — occurring every two weeks (or perhaps four, for larger projects).

According to Martens, for a development team investigating agile development techniques, the best way to get started is to simply schedule a demo. “Set a demo date two or four weeks out with a customer or stakeholder, get feedback about what they want to see in a demo, then figure out how to get it done and tested, so at the end of the demo, if a customer likes it, you can put it into production.”

After each demo, the development team routinely meets to decide which aspects of the project are going well or need improvement. Perhaps not enough time is being spent on testing, so the team adjusts the upcoming schedule accordingly. The group then selects the next three top priorities, and begins delivering those. “So they get into a regular cycle of adapting their tools, processes, and roles,” says Martens.

Navigating Potential Agile Roadblocks
When testing the agile waters, start small. “Trying to take agile into a large, distributed team that’s run by command and control — that’s not the way to introduce agile. But you can get to those large, distributed teams pretty quickly, if you can get two smaller teams to run for a few iterations, and prove the concept,” notes Martens.

Starting small also helps circumvent any roadblocks, and to identify whether agile will even be a cultural fit. Potential roadblocks include managers with the aforementioned command-and-control style, since agile teams require cross-functional teams which self-organize; and managers who hoard resources, since team members must work full-time on the project and not get reassigned on the fly. Agile also requires team players, not “heroes” who ride in at the last minute and rescue code.

Finally, Agile demands a very present customer — or “customer voice” proxy with decision-making authority — who is, ideally, co-located with the team, to provide just-in-time guidance. For example, if an initial requirement is for a system able to handle electronic payments, and the development team discovers that because of code base vagaries, using PayPal will be much easier than trying to integrate with credit card processors, and the customer agrees PayPal is sufficient, then the development team can quickly implement the solution, without trading design documents and waiting weeks for customer guidance.

Agile in the Enterprise
While groups testing agile should start small, agile techniques can also work well in large organizations. For example, take BMC Software, which in 2004 decided to create a single, shared architecture for its two separate Patrol products (an enterprise-class infrastructure monitoring tool), to increase scalability and performance. With a one-year deadline, the company faced steep odds of success, including having to coordinate the efforts of 300 developers spread across six locations — from Texas, to India, to Israel.

To see if agile techniques might help meet its deadline, BMC began testing Scrum with two project teams, and after two months expanded it to five teams, eventually creating an agile evangelist; reorganizing teams to be co-located, cross-functional, small, and able to work “virtually” around the clock; pursuing continuous iterations; and creating a “requirements architect” role to help development teams identify detailed requirements. In the end, BMC not only met its deadline, but even won the 2006 Innovator Award from Application Development Trends magazine for its efforts.

For developers able to adopt this attitude, however, and work on fast-paced development teams; and for companies who want to quickly produce software designed for customers’ needs, consider going agile.