Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Every few weeks, I run into someone who vehemently claims that agile development doesn't work. This individual always has a story about an "agile project team" in his organization that failed miserably; therefore, agility is just a bunch of hooey and everyone should return to the heavy process we've all known and loved for years. After a few minutes' discussion, I invariably discover that the team in question really wasn't doing Extreme Programming (XP), Scrum or whatever process they claimed to be following—instead, they were embroiled in some form of code-and-fix hacking. Because the individual didn't know the difference, he honestly thought that the team was agile.

The challenge is that agility is situational—we clearly need reasonable criteria to quantify it. For example, a large team spread out among several locations can still be agile, but it must do more up-front modeling and documentation than a smaller, colocated team. Team size, location and documentation practices are not definite determinants of agility. But what is?

Evaluating Agility
When I'm asked to evaluate a team's agility, I look for several things. I first meet their stakeholders and watch their regression test suite run. If the team can't easily support these requests, there's a very good chance that they're not taking an agile approach. Next, I ask to see their working software, look at their source code, which should be of high quality and kept under configuration management (CM) control and discover how they manage changing requirements. At this point, if I hear the right answers, it's almost certain that the team's taking an agile approach. My final test is the frosting on the cake: The team should take responsibility for their work and strive to automate as much as possible.

Stakeholder Who?
It's 12:00. Do you know where your stakeholders are? Seriously, agile developers work closely with their project stakeholders. In fact, they're important and visible members of agile software development teams. XP, for example, includes the On-Site Customer practice, which requires one or more stakeholders to provide the team with requirements-related information and to make decisions in a timely manner. Agile Modeling (AM) extends On-Site Customer to insist that stakeholders also actively participate in your requirements modeling efforts—they're the business experts, so they're the ones best suited to model their business. Finally, in Scrum, the Product Manager is responsible for defining and then prioritizing requirements. This person frequently performs traditional business analyst tasks, albeit in an agile manner, because he often needs to drive agreement among a range of stakeholders. Remember, despite claims of agility, the absence of continuous stakeholder participation is a solid sign that a team isn't as agile as it may claim.

Testing Is Your Friend
Testing is a mission-critical activity. Although this can also be said of some traditional teams, at least at certain points in the project lifecycle, truly agile teams focus on testing to a much greater extent—and do so throughout the project. Although it sounds like rhetoric, agile teams have rethought the role of testing and QA, and have built new toolsets to support their activities. The majority of agile programmers take a test-driven approach to development: They write a small test, generally using the XUnit framework, and then write just enough production code to fulfill it. They proceed iteratively until the new requirement that they're working on is implemented. As they do so, they refactor their code to keep their design of the highest quality possible.

This approach offers two important side effects. First, by running a regression test, agile programmers can show that their software actually fulfills the requirements they've implemented to date. Second, the unit tests form detailed design documentation that's up-to-date, accurate and useful.

Most agile teams develop a full regression test suite for their acceptance tests, often using the FitNesse framework. This enables them to capture acceptance tests in a form of structured English from which running code is generated (FitNesse currently works for Java and C#). The acceptance tests are treated as first-class requirements documentation because they define criteria your system must fulfill. Having acceptance tests and unit tests do double duty as both test and modeling artifacts reflects the practice of single sourcing information: Store information only once in the most appropriate place possible, thereby reducing your development and maintenance workloads. Despite claims of agility, the absence of significant testing efforts is clearly a sign that the team isn't as agile as it may claim. It really works!

Agile teams produce working software on a regular basis, as it's the only valid measure of progress for a software development team. Even in the first week of a project, it's reasonable to see some working software. Throughout the project, any programmer on the team should be able to build and then run the entire system from his development sandbox. With each iteration (typically a week or two in length), the team adds an appropriate amount of working functionality to its overall system, showing regular and measurable progress. This is often very different than the "earned value" approach taken by teams claiming that delivery of requirements specifications or architecture documents is an accurate measure of progress. How many teams have you seen deliver such artifacts, only to fail to produce a working system at the project's end? Traditional "earned value" sounds more like "justified bureaucracy" to me.

Hello, Version Control
Agile developers take configuration management control very seriously. If something is important enough to create, it's important enough to put under version control. Tools such as CruiseControl monitor your version control tool, automatically copy any updated artifacts to your development environment, and rebuild the system on your machine if the source code has changed. This keeps all developers on an agile team up-to-date, reducing the potential for collisions. Open source CM tools, such as CVS and Subversion are also commonly used by agile developers.

Change Is Good
Agile teams welcome changing requirements. They realize that their job isn't simply to build software according to specification, but instead to build software that meets their stakeholders' highest-priority needs. They also understand that even if stakeholders were good at up-front visioning, they'd probably change their minds over time anyway. By treating requirements as a prioritized stack, agile teams make it easy for stakeholders to do this. At the beginning of each iteration, they pull a single iteration's worth of work off the top of the stack, and the rest of the requirements are allowed to vary as the stakeholders see fit (sometimes, even the current requirements are allowed to change). In effect, agile teams always try to implement the highest-priority requirements as defined by their stakeholders, providing the greatest value for their investment.

So, even when teams work closely with their stakeholders and are test and quality infected, they must still produce working software, keep their project artifacts under CM control, and embrace changing requirements. While these practices let teams make concrete progress throughout the life of a software development project, two more criteria make a team truly agile.

Automation, Meet Responsibility
Although drudgery isn't a showstopper, I expect agile teams to strive to automate the tedium of software development as much as possible. Good tooling is important—and, as I've indicated throughout this column, agile programmers have built a range of open source tools to help improve productivity.

Finally, agile teams should take responsibility for their actions. Even with an agile approach, project teams can fail, but you shouldn't hear "but my part worked" from anyone. The team succeeds or the team fails—together.

How agile are you? Forget the grandiose claims on both sides—it isn't the talk, it's the walk. Given your specific situation, if you're as agile as possible and strive to enhance agility when you can, you're agile enough.

Scott W. Ambler is a Canada-based software process improvement (SPI) consultant, mentor and trainer with Ambysoft Inc. He has written several books and is a regular speaker at software conferences worldwide.

RELATED ARTICLES OutSystems Updates Agile Platform Danube Releases ScrumWorks Pro 4.1 Agile Self-Evaluation Tool Released Why We Need a Theory for Software Engineering Nokia Takes Task Management For A Spin		TOP 5 ARTICLES No Top Articles.