Published Summer, 2022

I’ve spent most of the last fours years working on teams that, more or less, employ the Agile Project Management methodology. And my experiences have generally been positive. I find that teams which follow the Agile rules, perform all of the ceremonies, and are studious about maintaining a backlog of groomed tickets, tend to be stable, resilient, and productive. Teams which only “go through the motions” or treat Agile like a “project management buffet” tend to suffer as a result. That said, I recently spoke with a colleague about his experiences with Agile. And he said he didn’t like it at all. And I think his reasons for disliking Agile are revealing. There is a potential dark side to Agile and I admit I have seen it happen before.

He said that he dislikes Agile because he is always under tremendous pressure to complete his currently assigned tickets before the end of each two-week sprint. And if he didn’t finish every ticket, he was scolded by management. And while we all strive to complete our tasks in a timely manner and would like to complete as many “story points” as possible during each sprint, his experience points to one of the major weaknesses of Agile.

Bob Martin likes to say that the purpose of Agile is to “destroy hope”. That’s a bit melodramatic. But it isn’t wrong. Agile provides management with some sweet metrics for gauging progress. And the purpose of those tools is help management identify problems and sticking points quickly. Used correctly, it should provide managers with the most accurate planning metrics possible by minimizing guesswork and “hope”. If your team completes fewer points this sprint than last sprint, then that presumably suggests there is something holding the team back. Or maybe something has gone awry with the estimation process. Unfortunately, there is, instead, a natural tendency to use those metrics to gauge employee performance. If the team or developer completes fewer points, then the developers are blamed. Indeed, the word “points” implies a score. And that’s not how it is supposed to work. In fact, I once worked on a team where the manager would praise the developers whenever they completed more points than last sprint and chide them when they completed fewer points. This is an understandable, if incorrect, use of the Agile pointing system. Ideally, each team should be completing approximately the same number of points every sprint – not more or less. And it is also tempting to compare point totals across different teams. But if done correctly, pointing estimates should reflect the difficulty of each task for that specific team. So comparing them across teams can create an artificial competition with a somewhat arbitrary scoring mechanism. If management puts an excessive focus on increasing the “point score”, then you will inevitably see the pointing system watered down to accommodate. Pointing estimates will go up and up and up in order to meet management expectations. This isn’t dishonest and it probably isn’t even consciously intentional. It is an understandable attempt to adjust estimates to match expectations.

In conclusion, Agile is a pretty good methodology for managing software development projects. Used correctly, it can make your team both productive and resilient. But be careful of the ways it can be misunderstood. The word “points”, in particular, can easily be misinterpreted and undermine the system’s stated goals.