Good and Bad Agile Project Management
3 min readJul 12, 2018
Just like any work management strategy or approach, Agile can be implemented either well or poorly. Here are the most common reasons for both.
The bad
- Doing Agile-like things just for the sake of doing them:
Arguably the most common bad Agile practice. An example of it would be keeping a daily stand-up meeting even when no new items need discussing and no issues have come up since the day before or holding a retrospective meeting without drawing any conclusions. - Padding daily communication with useless jargon:
Using simple language does not make one a simpler person, in fact in an increasingly jargon-filled environment, which most of today’s offices have become, you may find that speaking clearly accomplishes more than using a collage of management-style, Agile specific metaphors. - Failure to describe goals clearly:
Setting a goal such as Become a more Agile team has more to do with wishful thinking than with goal setting. Instead, use real-life, actionable wording, such as: Set a 2-days maximum response time for all inquiries, Sum up all user requests weekly.
It’s much better to set narrow goals, rather than wide-spread strategies, which are easily open to interpretation, misunderstanding and misuse. The more narrow and specific a goal, the more likely it is to get accomplished and verified. - Lack of interest in implementing continuous improvement:
If one and the same issue repeats on a regular basis and is being tackled as a single problem each time, you’re clearly missing out on a chance to improve the process in general. And, you’re wasting your team efforts and time while letting this happen. Creating repeating work instead of fixing the cause and improving the entire workflow at the same time. - Limiting your efforts to just an Agile tool adoption:
Though we, at Kanban Tool, would be the first to recommend use of a Kanban or Scrum board, just doing that is not going to make your team Agile. It will help, but it’s not enough. Agile working demands as much a cultural shift as it does an organizational one. It is an effort, in which each team member has to participate to a large extend.
The good
- Hiring people who really can keep a cross-functional role:
For instance — if you’re going to hire a project manager, it would make sense for this person to also have a second, more concrete role, as only very large teams really need a full-time project manager. Why not make one of the core team members a team leader instead? Or spread typical project management tasks among a number of people who already know and work on your project? - Taking lessons from the past:
No point in doing sprint reviews and retrospectives unless some value is derived from them. If you’re going to ask the team to spend their time looking back at their work and process, make sure that there are conclusions drawn and that they are turned into relevant workable items for the very next sprint or project. Otherwise the entire thing is a waste of everybody’s time. - Good Work In Progress limits setting:
First of all, do consider using WIP limits, they can make a very noticeable difference to a team’s efficiency.
A reasonable WIP limit should match the team’s minimal capacity, not opposite. This goes for both the speed of one part of the process and to the throughput of the whole system. Refraining from setting these at the highest possible level will keep the amount of issues and mistakes at minimum and provide a real chance of achieving high quality results.
Consider these before you decide that “All of Agile is just common sense” and also after you’ve decided that already! There is a reason for everything, and if a method deemed successful by tens of thousands of teams happen not to work for you, perhaps it’s just been done wrong?
Keep an open mind!
