Any person who's worked in or around software for any length of time has likely heard of Agile. Since the release of the Agile Manifesto in 2001, Agile has quickly spread through the industry, and even companies who aren't fully Agile sometimes claim to be, if only to check the box. Still, despite this popularity, we regularly receive confessions from people who admit that they don't fully "get" what Agile is, often from teams outside of software developers who want to know if Agile can help them too.
The Elevator Pitch
"Getting" Agile is a multi-step process, but knowing the elevator pitch is a great place to start. Agile is an iterative approach to software development and project management, with iterative being the keyword. Its primary focus is on delivering value incrementally, with those increments being faster, more frequent, and with fewer strings attached than some traditional approaches. Agile also acknowledges, accepts, and even encourages that risk and change are likely to pop up and need mole-whacking along the way, allowing for real-time course-correcting as needed.
This short description can help people navigate through many of the superficial conversations around Agile. If you want to impress though, knowing the details is the next step.
The Details
To really understand what Agile is, it helps to first understand why Agile is. Agile's origin is in software development, and its inception was a direct response to the rigidity of existing development methods like Waterfall. Despite this, its existence is not at all meant to be a critique of Waterfall, which is a valid methodology that still has uses in several scenarios; rather it's an answer to the "But what if...?" questions that plague so many projects, such as:
- What if I discover more requirements after development has started?
- What if we don't catch a big problem because we waited too long to test?
- What if we need to ship to market faster or more frequently?
Answering these questions is difficult in a Waterfall environment, and failure to answer them can be costly. This can be especially true in software, where conditions and criteria frequently change, and rapidity and innovation are critical factors in winning over users. Enter Agile, whose principles allow teams the flexibility needed to answer these questions as they arise while still meeting product and stakeholder needs.
While some interpret this flexibility as Agile having no rules, this could not be further from the truth! The Agile Manifesto itself includes both key pillars and guiding principles, which every organization purporting to be Agile should follow. Amongst the guiding principles are those that are arguably more nebulous, like "Working software is the primary measure of progress." Still, many are undeniably rules and not suggestions, such as the principle requiring the increments mentioned above: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. "
Beyond that, there are also rules associated with each particular Agile framework to adhere to as well.
You see, while "Agile" is the overarching methodology (or philosophy, some argue, an ongoing debate), the actual "doing" is often guided by the numerous frameworks within Agile, with more popular frameworks like Scrum, Kanban, eXtreme Programming, and the Crystal Method leading the charge. Of course, that's not to say that one can't simply follow the principles of Agile without needing a specific framework -- you absolutely can! -- but development teams may find it easier to work within a framework. Aiding this ease is that each framework has taken the Agile principles and hammered them into specific actions, ceremonies, and practices for teams to follow, reducing the need for teams to develop their own.
Knowing the pitch and the details is essential to understanding Agile, but "getting" Agile requires that you take it one step further and apply it outside the business.
The Real World Example
As mentioned, Agile is an iterative process that seeks to frequently deliver value while still allowing for the winds of change. One of the reasons Agile can work so well is, if you think about it in the simplest of terms, because most people do Agile every day.
No, seriously!
I recently moved and learned again how ever-present Agile is. I prepared for the move with a soft plan and a general goal in mind: get everything packed and ready by X date. I even took an incremental approach to it, regularly moving smaller and more manageable items over to the new house in the weeks leading up to the move. As is frequently the case, though, life had different plans, and I found myself scrambling to finish hours before the movers' arrival (see: winds of change). I could have chosen to stubbornly stick to my original plan, risking either an incomplete project or a financial blow from having to delay, but I instead chose the Agile approach. I reprioritized and adjusted my goal, focusing on readying the most vital components and shifting lower priority items to my next increment.
And just like that, you're Agile!
