A couple of years ago I presented Project management the agile way at Meet Magento Poland 2014, so when I read this Agile is dead article I felt compelled to write on this topic. You can also watch this video for more context.
For me, Agile was never really alive in some of the ways mentioned in the article, but along the years I met fans of Agile who were strong advocates of some of the bad practices mentioned there.
Some people understood Agile as a justification not to write requirements specifications, and they were quite insistent that doing specifications was so waterfall. That automatically evolved into no estimations, since how can you estimate something that you haven’t defined? That always sounded absurd to me, since I think everybody needs a budget and/or a timeline for a project of any size. So if Agile means no specs and no budget, then I never truly was Agile.
Another bad practice I noticed is on not planning more than a couple of sprints ahead; beside a global budget and timeline, clients also need a intermediary milestones and having no idea what will be delivered when will have a negative impact on client’s organisation.
Agile Scrum insisted on frozen sprints for example, and while this was a good thing to aim for, insisting on it was just not possible and sometimes sprints needed to be amended with high priority items.
A more trivial problem is that Agile insisted on all tasks to be User Stories, while some items were just not translatable to stories, although they were much needed. And for some reason, Agile projects seemed to do worse in the documentation area; probably because Agile is focused around developers and as developers we hate documentation.
I presented some of the bad, the rest can be read in the article I referenced in the opening, but Agile is not all bad and has very important benefits.
The biggest benefit of Agile (especially Scrum), in my opinion, is communication: having daily meetings in the team (whether they are standing or sitting) was a big win for us and saved a lot of wasted time resulted from misunderstandings and miscommunication. The client communication resulting from sprint demos was equally as important, since it made sure we were on the right track and also gave the client a constant update on the progress; the demo being done by the team was again a good thing, since it made everybody more involved and aware of the business needs.
The sprint in the Scrum was again a benefit, since it organised the team around certain deliverables they committed to, and not being able to deliver on time gave an early warning on falling behind on the project schedule.
The goal for less rigid specifications was another good thing I think, because some things do change during development and you don’t need to stay on the wrong track just because that’s what you planned a few months before. In the Agile spirit, client flexibility on changing specifications without formal change request documents, but rather with informal discussions also removed a barrier for improvement.
Finally, although not completely related to the Agile methodology, the kanban board is a great way to visualise what everybody is doing.
So Agile is not the magic solution to all problems as it was hailed to be, but it’s not all bad either. I think we need to apply it with common sense: requirements need to be defined, development needs to planned and effort needs to be estimated. This is the only way clients know what they will get, for how much and by what time, which is just business common sense.
About the author
Vlad Stănescu is founder and CEO of MindMagnet, a web development agency in Romania focused on Magneto and custom web development.