Agile project management: 10 mistakes to avoid

Think agile is all hype, or that it isn’t right for you? One of these common roadblocks could be standing between your organization and the promised benefits of agile project management
545 readers like this.
remote security policy

Agile project management holds a lot of promise for leaders. Those who have successfully made the switch in their organizations sing agile’s praises, like the ability to rapidly course-correct, release software faster, and create happier teams and customers. But if you’ve been working at it for a while and you still aren’t seeing the promised benefits, you might start to think that agile is more hype than substance, or that it isn’t right for your organization.

Consider this: It may not be agile that’s to blame – it could be you.

[ Want a primer? Read Agile project management, explained. ]

Are teams still struggling to really collaborate in open ways?

“Organizations really see agile as a panacea,” Melissa Swift, Korn Ferry’s senior client partner for digital solutions, recently told us. “What we see happening when some organizations move to agile is that they’re asking people to operate in a completely new process, and some of the fundamental things haven’t changed yet.

”For example," she continues, "if leaders still operate in a top-down way, if teams still struggle to really collaborate in open ways, if you haven’t meaningfully rewritten people’s jobs, all of those things push against agile. And all of those things are critical to cultural change.”

What roadblocks are slowing down agile project management in your organization? We asked experts to share some of the common mistakes, such as lack of planning, lack of flexibility, and lack of executive support. It’s not only deficiencies: Over-testing, for example, can pose problems.

Read on for 10 agile project management mistakes to avoid.

1. Trying to boil the ocean

“It’s a mistake to try to turn everything into an agile sprint or micromanage every sprint. The idea of agile sprints is to empower small groups to ideate and develop while the PM checks in and ensures everyone is on task. Trust in them. Have PMs certified if you have the time. Don’t try to boil the ocean. Trust in your highly qualified and experienced people. Another roadblock might be trusting too much in the process and not having enough touchpoints or end product quality review in place.” - Shayne Sherman, CEO of TechLoris

2. Resistance to culture change

“The greatest challenge or roadblock for the data team is culture. For too long, the data teams have not had to consult with others. They viewed themselves and were treated by management as insular, not subject to the demands of the enterprise. This is no longer the case. Changing the culture around data service teams will be the biggest challenge. Feedback loops and blameless postmortems would benefit the data services teams, but they are very different from how they do their jobs today.

“One of the hallmarks of agile is focusing more on the process and less on the tools.”

“One of the hallmarks of agile is focusing more on the process and less on the tools. That’s a difficult idea for database professionals. Moreover, flexibility and nimbleness are not exactly words one would use to describe most database teams. But that needs to change now. When other parts of the organization adopt agile, it puts an immense amount of pressure on database teams. The data team needs to respond, or risks becoming irrelevant and slowing down the rest of the enterprise.” - Robert Reeves, CTO of Datical

3. Not enough team planning

“A roadblock to implementing agile at the team level is underestimating the level of effort and planning needed to get an agile project off the ground. Too many organizations plan their agile strategy but miss the nitty-gritty tactical planning.

The scrum master and product owner are critical roles and should be filled with experienced resources.

“First, it is important to field a cross-functional team with all of the skills needed to deliver something of value. Agile teams are expected to work independently, without the handoffs that cost time and quality on traditional projects.

“Second, the scrum master and product owner are critical roles and should be filled with experienced resources. A two-day class does not provide someone with the skills and experience to fill these roles. The scrum master needs the experience to help the team build and mature their practices. They also need the gravitas to influence leadership and resolved systemic blockers. The product owner should have the ability to build the vision, prioritize work to deliver on it, the political skills to defend it, along with a good working knowledge of the product.

“Finally, you must work through the logistics to help the team be successful from the beginning. Does the team have a good workspace? Does the infrastructure support the continuous delivery of value every two weeks? Without this essential planning, agile teams will fall short.” - Alan Zucker, founding principal of Project Management Essentials

[ What tools can help? Read also: Top 7 open source project management tools for agile teams. ]

4. Too little flexibility 

“Agile projects often fall down because of rigid procurement practices. A large organization will appoint a supplier to deliver an agile project, but with a contract that ties them to fixed deliverables. This is at odds with agile, which relies on the team being able to adapt and respond to change, whether in client requirements or in available technologies. More flexible contracts lead to better results, with a fixed outcome to provide a clear direction of travel but with a provision to review progress on an ad hoc basis.” - Jim Berrisford, chief operating officer for Step5

Carla Rudder is a community manager and program manager for The Enterprisers Project. She enjoys bringing new authors into the community and helping them craft articles that showcase their voice and deliver novel, actionable insights for readers.  



Don't fall for the hype. Agile has a valid application range, but it is far smaller than claimed (GUI development and little else) and is not a guarantee for success, no matter how religiously you adhere to it.