There's no question that "agile" is the buzzword of the times for software developers, ISVs, consultants, and businesses, in general. As with most buzzwords, the term is often over-used and mis-used, especially by those trying to portray their products or services in a new light. In the world of software development, the term "agile" is applied to a wide variety of processes, techniques, tools, projects, and phases of the development life cycle. It's important, therefore, to set out some basic definitions and context for the use of the term "agile," especially as it will be used in articles throughout this journal.

The Merriam-Webster online dictionary (http://www.m-w.com/) defines "agile" as an adjective meaning:

1 : marked by ready ability to move with quick easy grace
2 : having a quick resourceful and adaptable character agile mind>

I've worked with hundreds of IT organizations, software vendors, and consulting firms trying to improve the way that they build high-quality software and systems. Each {sidebar id=1} uses the term agile in a different way. I'll start by saying that I think that all of their goals are admirable - who wouldn't want to be agile? But through working with some of the smartest minds in the software development industry, I've learned that it's important to differentiate between the Merriam-Webster definition above and a specific set of "Agile" processes that have evolved in the software industry. [1]

In the context of software and systems development, the term "agile" (with a small "a") means that development teams are nimble, flexible, responsive to business needs, and able to adopt new technologies and techniques that can improve software delivery. I've seen development organizations trying to become more agile for a number of reasons including:

• Competition: "If we can't deliver new features or products quickly, we'll lose business to our competitors."
• Credibility: "Our customers and business users hate us; they have no confidence that we will deliver what they want or need - at least in this lifetime."
• Fear: "If we don't improve our quality and speed up our project delivery, the company will outsource development to someone else."

There are many ways that a development organization can become more agile. Delivering software in smaller, more frequent releases; instituting frequent feedback cycles from customers; and using component- and service-based architectures are just a few examples. All of these can improve a team's ability to meet users' needs and deliver value to the business. And, developers can adopt these techniques incrementally, without having to disrupt or overhaul their current development environments. The widely-used Rational Unified Process (RUP) is agile. RAD approaches are agile. Even running repeated series of short waterfall projects, rather than delivering one large release, can make you a bit more agile.

The term "Agile" (with a capital "A") software development refers to a very specific set of processes that have evolved over the past fifteen years including eXtreme Programming (XP), Scrum, Feature-driven Development (FDD), Crystal, DSDM, and Lean Software Development. The Agile Alliance (http://www.agilealliance.com/), a non-profit organization created by the thought leaders behind most of the Agile processes, promotes a core set of values that all Agile processes must follow:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Every Agile process supports these values, albeit in different ways. Some, like Scrum, address team management. Others, including XP or DSDM, address core development activities or other activities of the development life cycle. Note that users of Agile processes do not have to follow all of a process' Agile practices, nor does use of one process preclude the use of another. Many, such as Scrum and XP, are quite complementary.

At a minimum, every Agile process delivers working functionality in short, time-boxed iterations; implements early and frequent testing; involves the customer on a frequent if not full-time basis; and assumes that requirements cannot be fully defined at the start of a project, and that requirements will continually change. Using these practices, development teams will be able to respond quickly to changing customer priorities and feedback, and deliver value to the business - what I refer to as improved "time to benefits."

Why is this distinction important? I have two main reasons for stressing the difference between "Agile" and "agile" processes:

1. Companies adopting Agile processes must be prepared to really change the way they build software and this change is hard. But companies that do achieve this change, will realize some significant benefits in the productivity, quality and value of the software that you deliver.
2. Companies that are not ready or are unable to undertake this level of change can still become more responsive and flexible in the ways that they build software. Then they'll become more agile and will begin to reap the benefits that Agile practices can deliver. This incremental approach can ultimately lead to a truly Agile shop, but at some point the organization will have to step back and acknowledge that it's not a direct path.

In each issue of this Journal, you'll find articles discussing both "agile" and "Agile" practices and related technologies - and how your organization can take advantage of them to improve your software delivery capabilities. Over time, I expect to see more of the Agile approaches become mainstream, and certainly be supported by the major software vendors and consultancies. Until then, a blend of agile and Agile techniques will get you going!

[1] To me, "Agile" is an adjective that can describe any number of behaviors, activities or projects. Some, however, use agile as a noun, as in "Agile provides..." or "Agile lends itself to..." I find this to be quite misleading, as it's really rare to find anyone using agile everything on a project or in an organization. So I'm going to be a stickler - at least for the articles that I write - and be sure to clarify what type of agile "thing" I'm talking about. I encourage our readers and contributors to do the same!

About the Author

Liz Barnett is the Editor in Chief of the Agile Journal and Principal Analyst at EZ Insight Inc. Previously Liz spent 10 years as a Vice President and Research Analyst at Forrester Research, joining Forrester as a result of its acquisition of Giga Information Group. Liz held management positions at Accenture, PepsiCo, and Atelier Research. She also was the Research Director for the advanced software development and advanced network computing research services at New Science Associates, prior to its acquisition by Gartner Group. Liz holds a patent for developing a distributed application development/CASE tool. Liz earned her B.S. in operations research and industrial engineering at Cornell University.

{mos_sb_discuss:8}

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview