Agile was developed by software teams who worked in a flexible environment where change was the norm. They usually work in small teams and over short “sprints” to adapt to those changes more effectively.
More and more teams are going Agile these days. Everyone working in software dev is either using Agile or they are learning how to use Agile. And now Agile has spread to be adapted by other kinds of teams, too, like marketing and sales.
But what is Agile? Is it a methodology, as some insist, or is it not, as other protest? Well, it does seem to follow certain principles, and however loose and collaborative it may be, remains fixed to those principles.
Agile is best known for its manifesto (primarily for software development) where solutions evolve through an iterative, collaborative process. Generally speaking, it is founded on the principles of adaptive planning, evolutionary development and early (and often) delivery with the end user in mind.
But Agile isn’t a magic bullet that can pierce any project to reap the same positive results. Agile offers a kind of structured methodology, or approach, or whatever definition you prefer. Agile has an almost cult-like following, and many advocates don’t believe it’s a methodology at all.
Some say that Agile is a “philosophy of software development, and Scrum is a framework to apply this philosophy. Good software development practices are the practical methodologies that make it all work. Agile is a set of values and principles.”
That may be true, but it’s also a system of methods used in a particular area of study or activity, which is the textbook definition of Agile. Controversy aside, Agile is well suited to those continual deployment-type projects where the target is moving, an environment where priorities are constantly changing and you have high-functioning collaborative teams.
However, if your project has hard deadlines and pre-determined product spec, one that is immovable for whatever reason, then Agile may not the way to go. You might need a different methodology, like Lean or KanBan or Waterfall-style structured projects, or you might benefit with a hybrid approach. Even this, though, is debatable, as the proponents of Agile note it can used for fixed project work, as well.
Agile is well suited to those continual deployment-type projects where the target is moving, an environment where priorities are constantly changing and you have high-functioning collaborative teams
Despite the lack of agreement on what Agile is and what it’s good for, and even the possible divisiveness of such an argument, Agile remains popular and deserves serious consideration for anyone leading a project. So, at the start of any project, you should figure out if Agile is the best, or only, approach, for you. To determine the proper course of action, ask yourself these three questions.
1. Is my project completely structured?
There are projects where the deliverables are set in stone and a project leader can work back from that to develop a linear path to reach that goal. This is not an ideal Agile environment, even if there are those who would disagree. Think of the classic Waterfall projects such as infrastructure improvements or construction projects or building the Hoover Dam.
In these types of projects, there are defined plans and sequential timelines requiring a fixed structure, and while Agile advocates say Agile can apply, it may not be ideal. For example, first environmental studies need to be conducted, and approved, and then architectural renderings that define engineering specs all need to be finalized before pouring the concrete. All those deliverables are set in stone, so to speak.
2. Does my project require some structure?
There are projects that neither fall under the highly structured or clearly Agile category. They may require a hybrid approach. Portions of the project could benefit from Agile, such as dev required for a new website build related to a new retail store launch. Whereas other parts of the project, might be more structured and be more suited to a traditional planning methodology, such as the construction of the new store interior and the manufacturing of the clothing line.
It’s possible to use both on a single, larger project, but likely each would be considered sub-projects, and managed distinctly.
3. How hands-on are my stakeholders?
There are times when stakeholders are going to want change and want to see that change implemented quickly. They will give their teams marching orders, but are content to step back and allow the team to arrive at solutions in their own fashion. These stakeholders are perfect for Agile projects.
Then there are stakeholders who demand a greater control over the course of a project’s overall progress. They may be delivering the fixed product requirements and prioritized backlog to the team to implement in a more top-down fashion. This could be either due to leadership style, or that the product or project requires more defined deliverables at the outset. In short, when the roadmap that is immutable and timelines for deliverables are fixed at the start of a project, then Agile may not be the best choice.
There’s differing opinions on that, too, however, and some believe Agile can be applied to projects with immutable and fixed timelines. It’s one of the things that’s so great and frustrating about Agile: it’s a flexible approach with sometimes passionate believers that see its benefits in every potential project application. That can be helpful in that it keeps one open to the many possible applications of Agile, but it’s important that your stakeholders are well informed about the Agile process, so they can understand its benefits, too.
Agile is a great tool for projects, especial if you’re working incrementally, seeking user feedback and charting bugs, so you can adjust the product while in production, Agile can be your guiding principle.
But despite of the seemingly fluid definition of Agile, like any tool you have to use the right one for the right job. You want to make sure the research is done to know your stakeholders and know all aspects of the project (or sub-projects) to determine what will be best for you going forward. If it’s Agile, then by all means get on board, but being flexible to support to other approaches and hybrid approaches, will better ensure the success of your project.
Whether you run Agile or Waterfall projects or both, ProjectManager.com can work for you. It offers teams the collaboration platform they need, with task scheduling flexibility too, with the ability to track issues and monitor your project in real time. See for yourself with this free 30-day trial.