Agile development is now well entrenched, and most think they understand what agile means. As with just about everything, the definition varies depending upon whom you ask.

Most developers who are doing agile are using Scrum methodologies, but that is not the only path available. Today, agile development in the Microsoft world involves both processes and, despite its being de-emphasized in the Agile Manifesto, tooling. Microsoft offers a broad set of project-management and developer tools in its Team Foundation Service, and other software providers extend that platform with plug-ins that help organizations become agile in a more efficient, effective way. This report looks at both sides of the equation.

What agile means
Back in 2001, a group of very experienced software developers put forth the Agile Manifesto, which states a series of priorities and objectives that are meant to guide developers and development teams through the shark-infested waters of professional software development. The development world is filled with horror stories of projects gone wrong and fortunes lost on dead-end systems that never make it into production. I even testified as an expert witness a few years ago in a dispute arising from one of these less-than-successful endeavors.

The root causes are often a lack of transparency, failure to communicate (or outright miscommunications), and—perhaps the deadliest of sins in this space—wishful thinking. These were the factors that affected the aforementioned doomed application as well.

The Agile Manifesto espouses a philosophy rather than providing a detailed instruction guide. At its core are four statements about important things, such as “Individuals and interactions over processes and tools” and “Working software over comprehensive documentation,” along with “Customer collaboration over contract negotiation” and finally “Responding to change over following a plan.”

Notice that methodologies are not included in any of this, even though the founding fathers of Scrum are among the signees of the Manifesto. At its heart, agile just is a developer-style rehash of the age old Army motto of “Lead, follow or get out of the way!” The goal is to achieve something, to get to producing value and moving away from assigning blame or making excuses. All great rules to live by, but mere mortals are left to ask how, and that is where the methodologies and the tools become critically important.

Where agile fits
Agile development has many fans—for good reason—but the first thing to understand is that it is not necessarily for everyone and is not a fit for every project under the sun. There are many ways to characterize a project, but the primary differentiator for any development project is always whether the details of the final result are known in advance or not.

When a project is started with an exact blueprint already defined, then a competent consultancy could quote a fixed bid proposal. But if there are any unanswered questions, it is not ready for a waterfall development process. This is the kind of development project that is planned from the start, and also the kind that runs according to a project manager’s Gantt chart rather than according to a Scrum Master’s cadence of sprints. These kinds of projects are still out there, but they are fewer and farther between since entrepreneurs, website owners and even department heads are increasingly compelled to get coding before the idea or requirements are fully fleshed out.