We use cookies to enhance your browsing experience and analyze our traffic. By using our site, you consent to cookies. Privacy policy

View the latest results of the Employee Retention Index


Agile Project Management: 6 strategies for success

How to make Agile real for your projects 

Organizations need Agile Project Management. They want to be agile. And Agile principles have existed for more than two decades. So why do so many project managers have trouble adopting these principles? Why do so many organizations continue to plan and manage projects using a traditional Waterfall approach?

Maybe it’s the comfort that comes from Waterfall Project Management’s black-and-white nature. A team puts up guardrails from the start, and theoretically, that keeps a project headed towards the defined goals at each stage. It has a history of working well for some projects and holding team members accountable. 

Traditional Waterfall Project Management methods may work well for truly straightforward, well-understood undertakings, but when it comes to managing unpredictability, it’s Agile Project Management that shines.

The problem with Waterfall is its assumption that projects always go according to plan—which they generally do not. Funding gets cut, key stakeholders enter or leave a project, global pandemics strike. A thousand circumstances can arise that slam a project into your carefully constructed guardrails and bring progress to a painful stop.

icon of clipboard with checklist

 Agile in a project management context

Agile development came about as a direct reaction to the traditional Waterfall IT approach to project management. Waterfall approaches are defined by strict and rigid long-term plans and schedules (with lots of paperwork). This results in products being delivered at the end of a long development period, during which the needs of the project often shift. But by that time, it is too late or too expensive to make changes.

Agile on the other hand, develops products through small and rapid iterations or “sprints,” bringing in continual feedback. This allows for product development to adapt on the fly to market conditions, requirement changes, and internal lessons learned. Although developed for IT, Agile Project Management excels as a tool for non-IT projects as well, especially those with a high degree of uncertainty. 

That’s where Agile Project Management comes in. Projects operating in uncertain environments, with known unknowns, should be serious contenders. So too are projects where the need for speed exceeds the need for extensive documentation of the process. Your job as a leader is to help your teams apply Agile principles and approaches in a way that works best for your organization.

However, calling something “agile” does not make it so. It’s fashionable, and many program teams adopt the language without understanding the principles behind it. If you’re not sure how to introduce Agile Project Management, here are six pieces of advice:


Let go of your ideas of a rigid schedule

Ingrained Waterfall Project Management habits can be hard to shake, but the point of Agile Project Management is accounting for a future that’s impossible to predict—or fully plan. You still need to understand the end goal and how you will get there (your series of sprints), but you will no longer operate to a grand plan. Instead, each sprint will have its own plan and operate in a short timeframe—generally, around 2–4 weeks long.


Get ready to shift other people’s mindsets

Some people just don’t feel comfortable without the big plan, milestones, and deadlines of Waterfall Project Management. The key to bringing people along is communicating Agile’s benefits. Early learning, early value, and preventing worker burnout are key benefits that resonate well with stakeholders. 


Set up a governance structure

For Agile Project Management to work, it is important to decide early on who makes decisions about priorities, what tasks go into each sprint, and what defines acceptable quality. For Agile IT projects, this is typically the product owner. In non-IT projects, this could be an executive sponsor or a small governance committee, who provide overall guidance to sprint teams. Within the sprint teams, it is also important to determine how decisions will be made – either by sprint leads or the team.


Establish your working norms

Sprint team members interact daily and need to maintain open channels of communication with each other. To prevent conflicts, identify team members’ preferred working and communication styles. Some members might need to work very specific hours, others may have very specific communication preferences. Assess these needs and develop norms to address them upfront to support team collaboration, communication, and morale from the start. 


Work in pieces

Agile Project Management is designed specifically to avoid the burnout of a Waterfall approach. So, plan work in small chunks and adjust as you go. Only bite off as much as you can chew in a defined period of time, also called “time boxing.” At every sprint planning session, ask what you can realistically accomplish and what resources you need to get the sprint done. You may occasionally hit a crunch period, but you should not repeatedly find yourselves frantic. Instead, when you reach the end of a sprint, be comfortable putting your leftovers into a box and reevaluating them at the next iteration.


Look back, learn, and refine from past experiences

The Agile term for the post-sprint process is called the retrospective. During the retrospective, the team discusses what worked, what didn’t, and what changes should come into play for the next iteration. This critical retrospective process informs future sprints, addressing issues before they grow out of control. Maybe roles need reshuffling or resources added. Whatever the specifics for you, Agile means staying flexible through your journey. If you find yourselves encountering the same problems every iteration, that’s a clear sign you haven’t been learning your lessons.