
Agile is sweeping the world. Well, it is if you’re involved in product development. It’s not new, Agile has been around for over 20 years, but it’s seems to have gained traction with each passing year and is trending, as they say in social media circles. But is Agile really the miracle cure for all project woes as it’s often prescribed?

Of course not, but it’s a fine way to manage product development, and Agile offers some unique advantages for the project leader and their team.
Agile is a software development approach that has gained momentum over the years, with good reason. It addresses uncertainty with
respect to product requirements and development as opposed to Waterfall, which looks to organize the project lifecycle phases in sequential order –
Initiation, Planning, Execution and Closure.
What Is Agile?
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
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.” But whatever you do, don’t confuse Agile with Project Management. Agile is about building a product and not about managing a project; there is more to Project Management than simply getting the product built.
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 product development methodology, like Lean or Kanban or Waterfall-style structured approach, 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.

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.
What Are the Right Conditions for Agile?
Agile is best used when product requirements are uncertain. Time is used more efficiently to engage the product owner and the Scrum team, starting with the use of user stories. User stories are a brief description of features and functionalities the product owner wants to have developed.
![]() |
The product owner and the Scrum team then takes these software features and creates a to-do list called a “product backlog.” Once the product backlog is established the Scrum team creates a “sprint backlog.” These features are then scheduled for release in “sprints.” Sprints are scheduled releases of features designed to develop and deploy small portions of the product at a time. The product owner and Scrum team will meet daily (daily Scrum) to review the development progress. This approach helps to address the issue of product or requirement uncertainty. Develop some, test, gather feedback and continue developing until the product owner is satisfied with the end results. When is Agile Not the Best Approach?Agile is not always best, such as when there is little uncertainty regarding requirements. Product development efforts where there is a solid history to use as a baseline for a new project may be better suited for a waterfall methodology. Managing the build of a data center is a good example. The planning effort depends on solid requirements and a specific sequence of activities to be completed in order. You cannot build a little and test a little with a data center. It’s impractical. So, When Is Agile the Way to Go?Now that we have a good idea what Agile is, what kind of environment it’s most suited for and those project that are better served with a more traditional methodology, it’s time to look at where Agile makes the most sense. There are many, and here are a few:
|
The embrace of Agile is exciting. It provides one more tool in the project leader’s toolbox with which to address the progress of a project. Like any tool, there are tasks that it’s better at and those which it is not as well designed for. But we’re all better project managers with more to choose from than less.
The Case for Managing Agile Projects
You want to create the most valuable software possible — as determined by your stakeholders — in the least amount of time and for the lowest cost. There are many different methodologies you can choose from to deliver your project, from Agile to Waterfall or a hybrid of the two.
So, what do you do?
The “Tension” on Agile ProjectsYou need a solid plan and a clear picture of what your project will deliver — and a way to control and monitor progress — while at the same time being able to release the most creative and productive energy of your project team. But is it possible to think everything through in advance, or is it better to think things through as you go, and still end up with the results your stakeholders want? There’s an inherent tension here, be it a push and shove or a top-down versus bottom-up. It’s like the yin and yang of project management. The answer, like Buddhism, is in taking the middle path or approaching things from somewhere in between. That doesn’t mean being a project manager on a large Agile project isn’t tense. You can feel that tension and you need to resolve it… How to Resolve the Tension on Agile ProjectsStart by answering one of the biggest questions on your project, “What is value?” Defining value will take a lot of collaborative effort among team members and stakeholders. Together you will determine what you actually want to see in the end, based upon value. Here are some guidelines for determining value:
Agile Case StudyLet’s say you are on a large and complex software development project. There are numerous Scrum teams, in multiple locations and under different organizations, but all on the same project. The tempo is fast, with new sprints every two weeks. There is a constant stream of meetings — sprint planning, design reviews, requirements meetings, integrated test planning, Scrum of Scrums and more! The wheels are turning, but where is it all going? How do you sort through all of the activity and ask the right questions? How do you determine what’s going right, what’s going wrong and what is needed? |
![]() |
Ask these three basic questions:
- What are we building? What is clear and what not? How will we know when we are done?
- By when? And how can we monitor our progress — toward getting done what we know and prioritize, and clarifying what we don’t yet know — and make course corrections along the way?
- How can we do it at the needed quality level, for the least cost, and with the most efficiency?
It seems, based on these questions, that it’s all about controlling what we can in the short to medium term and then figuring out the rest along the way. You want to empower people to contribute along the journey, assuring stakeholder concurrence and moving toward an increasingly clear picture of an end state of value.
This last point — moving toward a clear picture of the end state — is where a lot of Agile projects can come up short, simply because they are too short-term, incrementally focused and lack an eventual longer-term goal.
The Value of the Agile Approach
The reason for Agile in the first place is that in software development, because of changes in technology, technical complexity and rapidly changing needs, it is hard — often impossible — to know exactly what you will need at some point down the road. As a result, a healthy acceptance of the fact that you cannot know it all up front can help you to adopt to a more Agile mindset. A drive for clarity on the end state can help you to properly guide the Agile work to a yet unknown place where stakeholders will be satisfied.
Back to the case study on this complex and challenging agile project: How do you know when you are “getting there”? Can you just be satisfied to say that “we are making progress”?
My answer is a bit trite: You cannot be satisfied that you are making progress until you are satisfied.
Going a little deeper, you know that you, your team and your stakeholders are on a learning curve. At the same time you need to make progress. In large part, it’s all about tempo. It’s about setting up a system to ensure that all these things are happening.
Agile accommodates this challenge beautifully. It enables you to be managing a relatively short duration project — let’s say six weeks plus or minus — while at the same time chasing after that vision for the ultimate end state. Using a rolling wave, you are constantly managing this short term project that has 95% clarity, and closing out bits and pieces while you push on to the next set of bits and pieces that come into clear view.
Clarity on the final end state might be 50% at best. It’s initially a bit like hitting a golf ball toward the flag. At first, you know that you can hit in the general direction of the flag — although often you cannot even see the flag, but just know it’s out there.
So you start out with a strategy about how to get down the fairway — considering wind, slopes, hazards and your own knowledge and capabilities — and into a position where, as each shot is taken, you are closer to the green, where you can finally focus on getting the ball into the hole. It’s the ultimate balance of short-term and long-term.
Strike a Balance on Agile Projects
In the final analysis, managing an Agile project is a process. You need to come to grips with what you do and don’t know, and create a system for filling in the blanks as the project unfolds. You assemble the team, develop an ecosystem and manage in chunks of short duration while you figure out the rest.
In the process, you deliver early and often.
The one constant across all methodologies is the use of good tools designed to get the job you’re working on done right. There are many tools out there, including those from Castellan Systems. To see how it can help you plan, monitor and report in real time, check out the free 30-day trial.
These articles were originally published by ProjectManager.com
Copyright 2015 © ProjectManager.com
3420 Executive Center Drive, Austin, USA 78731