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.
Agile in a project management context
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.