I’m not certain when agile was first used to describe software development, but over the last few years, it’s become the term of choice for so many in describing their environment and approach (though not always the actual methodology being utilized).
So what does Agile methodology really mean? Let’s start with a couple of very basic descriptions:
- Waterfall is rooted in having all requirements in advance, then going off and building to these very exact specs. There’s not a lot of opportunity for change, and when alterations to specs are needed, they can be costly both in terms of time and money. Never mind the fact that they don’t tend to allow for evolving or changing needs from the perspective of the user (who by the way typically has little or no voice once the build begins).
- Agile is about getting things started and teams producing quickly. It seeks to provide a more fluid or dynamic approach, allowing for the user to be highly involved in the software development process, and thus brings a highly adaptive development environment. Change is expected, and adaptation is not overly expensive because it’s inherently accounted for. The user is always highly involved throughout the development process – because the process never ends.
There are lots of good styles of Agile out there, including my personal favorite known as Kanban (internally we used to call it hyper agile), but they all generally adhere to the basic tenets of agile development. They value changes and adjustments, feedback, and discussion – especially with users. They make room for gut checks all along the way, making sure that the product is continuing to bring value for the user. Course corrections during development are part of the plan and necessary. Extending from the first set of delivered product functionality, the agile methodology is about bit by bit refinement and improvement through constant communication with the user.
There’s also an agile style that just pretends; it’s really waterfall in disguise.
In Agile, user stories are created to replace all of the upfront requirements of Waterfall. But, when user stories come with too many detailed criteria, are too far time-removed from creation and selection, or require too many internal and management or other approvals, and [important] don’t involve the user in the overall process, aren’t we really just describing Waterfall with some window dressing? In this style, teams tend to spend much of their time on predicting project durations and feature sets and writing specifications and technical documents instead of interacting with users. Despite the application of select agile features such time-boxed development iterations, or Scrum style management, this isn’t a particularly agile approach. It tends to run counter to true agile philosophy.
From the Agile Manifesto, we should value:
- Individuals and interactions over processes and tools;
- Working software over comprehensive documentation;
- Customer collaboration over contract negotiation;
- Responding to change over following a plan;
That is, while there is value in the items on the right, we value the [bold] items on the left more.
The impact to teams following this pseudo-Agile style can be significant because people are often out of sync, the voice of the customer is often not heard (or worse, heard and not acted upon). Think about a situation where a user story is created based on initial customer discussion, then implemented weeks or months later, only to find after release that the requirements were not well understood at the outset. User interaction throughout the process is critical and can help eliminate or minimize these types of scenarios.
So what style is your shop? If it’s an Agile impostor, then you might want to re-evaluate to make sure you’re really getting the benefits Agile has to offer, making sure that your teams (and your organization) are completely on board; being somewhat Agile isn’t really Agile at all.