Let me start off by saying, Agile is not just for projects and not just for software development. Agile is also not a methodology or framework. (*This is why you may hear people say there is no such thing as an “Agile Project Manager.” It is not because project managers do not exist in Agile approaches; although some Agile frameworks do not define a project manager title, the duties still get performed. I will be releasing a post soon on DSDM which does define a project manager: “A Full Life-Cycle Agile Approach: Dynamic Systems Development Methodology (DSDM)“)
Now that I have that out of the way, let us proceed with a, hopefully, clearer definition of what Agile is.
I have found myself involved in a couple of debates on this issue and find I enjoy them. I even posted this “What Does Agile Mean?” as a question on projectmanagement.com to try and incite a little debate.
Let us start with a Google definition. According to the dictionary tool in Google, Agile is:
“1. able to move quickly and easily.”
“2. relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.”(Google Dictionary)
Our focus is the second definition (although the goal is the first), and the first problem I see with it is that it relates it to project management. I have to disagree. While Agile approaches are used for project management, it is not the only use of Agile methods or frameworks.
Agile may have a strong history with software development, but it is not isolated to software development. Even some commonly declared Agile software development frameworks, such as Scrum, can be used for non-software purposes. There are a few Agile methods and frameworks dedicated solely to software development, but it is not the majority of Agile methods and frameworks.
Agile: A Definition
Through my debating and experience with the issue, I have attempted to come up with a “good” definition of what Agile is. This may cause some disagreement.
Agile is a generic or “umbrella” term for an operational framework or methodology that strives to keep a focus on requirements by using adaptive approaches and continuous improvement practices.
Vague, but I think accurate. Being a little more of a fluid definition that allows for the ability of many Agile methods to expand beyond software projects. It also requires further explanation.
Some common traits of Agile Approaches:
- Adapt to changing requirements
- Continuously improve the work process and the product
- Release work incrementally
- Inspect with each incremental release
- Focus on the product or work output as the primary measure of success
- Gain frequent customer (primary user of the product or work output) input.
- Utilize servant-leadership philosophy
- Allow for self-organizing teams
You do not need to adopt all of those traits to be Agile. A way of implementing Agile outside of a predefined approach focuses on continuous improvement (Lean), servant-leadership, self-organizing teams, gaining frequent input, collaboration, and using the output as the core driver of success.
There exist several methods and frameworks that attempt to structure some/all of the above list in a way that they can help you focus on the needs and the work output. Some are more strict than others, Some are looser defined, some consist of much wider processes or a fuller life-cycle, and some are very focused. It wouldn’t be fair to declare Agile a failure if you only tried one. This is not a complete list.
- Dynamic Systems Development Methodology (DSDM)
- Test-Driven Development (TDD)
- Feature-Driven Development (FDD)
- Extreme Programming (XP)
- Scaled Agile (SAFe)
- Disciplined Agile Delivery (DAD)
- Scrum of Scrums
- Large Scale Scrum (LeSS)
- Rapid Application Development (RAD)
- Agile-Waterfall Hybrid (often just called Agile)
- Agile-Agile Hybrid (sometimes just called Agile, sometimes one of the other names in this list)
- Agnostic Agile
- Lean Software Development
- Unified Process (UP)
- Unified Software Development Process (USDP)
- Rational Unified Process (RUP)
- Optum Scaled Agile Methodology (OSAM)
- Spotify Squad
- Sustainable Cultural Agile Release in the Enterprise (SCARE)
- FAST Agile
- Adaptive Software Development (ASD)
Some Advantages of Agile Methods/Frameworks
If done properly, Agile methods can have many benefits. This may vary in your organization and by which method/framework you choose, but in general, there are 5 core advantages to the business.
- Flexible and adaptive to changing situations/market conditions
- Higher quality delivery
- Quicker value delivery
- Greater customer interaction and satisfaction
- Less focus on non-value added items
I have been on some poorly implemented Agile teams before. If it feels like you are spending all of your time in meetings talking about the work you have to do, but little time doing it – you are doing it wrong. If you end up in an endless iterative loop with constantly changing requirements to the same release or incapable of setting scope boundaries to a release – but no actual releases for weeks or months, you are doing it wrong (this is what timeboxing is for). If you like to operate that way, an Agile approach probably isn’t for you.
Adopting Agile requires a change, not a small change, but a complete change. This is why they say you have to be Agile you cannot just do Agile.
Some Disadvantages of Agile Methods/Frameworks
Number one on my list of disadvantages – convincing people to stay on task and within the set time for the increment. You will be okay if we release without just the right shade of blue. Try it, maybe you will like it. If not, you can change it later after you make up your mind. Nothing has to be set in stone right now.
- Greater risk of failure due to inability to make decisions on time, and insistence that nothing can proceed until minor decisions can be made
- Complete dedication from the team involved with little outside distractions
- An inability to decide on what “just enough” means, causing a lack of documentation or planning
- The final product may end up very different than was originally envisioned (this may not be all that negative)
Agile “Just seems natural”
Unfortunately not. A “just seems natural” approach too often looks like a Waterfall with no planning or Agile without any rules or structure. Situations like that tend to create a condition I have come to call the “Endless Iterative Loop.” If you want to have a two-month project last four months, then, by all means, take this “natural” path.
If Agile was natural we wouldn’t have to debate about what it means and convince people of its value. Agile is not natural, it requires a distinct change of thought on how to conduct business. It requires being very proactive and continuously correcting. This is why “Agile Coach” has become a job title, and why the Scum Master is tasked with advocating Agile practices.
Agile is anything but natural. Natural tends to develop first and tends to be more chaotic. Which is exactly what happens when organizations adopt the belief that Agile “Just seems natural.”
Agile Vs. Waterfall in Projects
In project management, there are two core ideas for approaching a project. Agile and Waterfall, or perhaps more appropriately, predictive and adaptive.
These are not competing ideas. You can have both, you can have one, you can reside somewhere on the spectrum. It is not a black and white decision, you can be somewhere in the middle.
Waterfall is also known as the traditional approach to projects. It is a predictive model. This means you try to plan things up front and set a timeline for the entire project. This works best with less complex projects that have a low likelihood of changing requirements. Your scope of work is almost set in stone, with little ability to change or adapt if requirements do change.
Agile approaches are intended to be adaptive. Frameworks and methods within Agile can be more or less adaptive depending on their specific practices. This adaptive approach works best with more complex projects that have less clear requirements. Your scope of work may not be fully defined in the beginning, you may just have a general idea of what you have to create within the project. This is why it is often used and associated with software development, software development being very complex and abstract.
You can define Agile in different ways, using different words – the thing to remember is that it is not a methodology. You cannot apply roles to it, or define it has having a structure – at the same time, you cannot really declare that there is no such thing as an “Agile Project Manager.” Reality steps in here a bit, companies have invented roles called “Agile Project Manager” just like “Agile Coach” was invented – (DSDM defines both a project manager and a DSDM Coach role).
Agile is generic, it is not specific. If someone says, “We practice Agile,” you should respond with, “Which approach do you use?” (*although you don’t have to practice any predefined approach, you can adopt a set of Agile core values) What is practiced in one version, may not be practiced in all versions; Coca-Cola is brown, but not all pop (or soda if you prefer) is brown.
It is also not just for software development projects. Kanban especially (my own opinion) has a lot of uses beyond software development, but any complex activity could benefit from an Agile approach.
There are lots of good resources out there to help you understand Agile; there are unfortunately lots of bad resources as well. It certainly is a much discussed and much debated about idea. The decision to adopt an Agile approach (or abandon it) shouldn’t be made without some intense investigation into the issue, and it should begin with understanding the core concepts.
Now we need to answer the question: What does it take to be Agile? Maybe in another post.
*Additional note here: Some people may describe Agile differently, from a slightly different perspective. They would look at Agile frameworks/methods as something you would put into your existing management and support structure. You would have a project structure in place, you would put an Agile framework or method inside that structure.
Kanban is a good example of this, you put Kanban into your already existing structure. This would also work well with Scrum. I don’t think it would work well with DSDM (In fact, the Agile Business Consortium, creators of DSDM, give advice on how to implement Scrum within DSDM).
I personally do not recommend looking at ALL of Agile from that perspective, but on a case by case basis for each method or framework under the Agile umbrella. To the best of my knowledge, this view would not work for all Agile frameworks or methods, nor is it needed for all approaches that have this flexibility, and it would not be something that defines Agile.
For More Information:
Agnostic Agile: 12 Principles of Agnostic Agile
Agile Manifesto (Software Development Focused): Manifesto for Agile Software Development
Agile Alliance: Agile 101
Agile Business Consortium: DSDM Agile Project Framework
Images from https://www.pexels.com
Google Dictionary: Agile Definition