What Agile Got Right (And Wrong)

Photo by Eden on Unsplash

As of this writing I’ve been in the industry for over decade and half, and I’ve worked and dealt with several Agile methodologies since my very first job out of college as a junior software developer. I’ve worked with Scrum, eXtreme Programming, “lazy” agile, certified Agile, BDUP Agile, and several different mix-and-match methodologies. While not an exhaustive list, I would say I’ve had thousands of hours of experience with each of the methodologies above. However, in spite of the positives, these practices and methods share, either by design or defect or misunderstanding thereof, the same underlying shortcomings — which I will explain below.

What Agile Got Right

Shorter, quicker feedback loop
Indisputably, in my opinion, the single most important aspect of Agile is how the process has pressed companies and teams into shorter iterations and feedback loops. Questions about requirements, design decisions, inaccurate estimates, all surface (and are often addressed) within the duration of a sprint. Shorter iterations do not necessarily mean (although often conflated with) faster ship times. But they do mean, at least in theory, that when the software is finally shipped most of the questions and issues around it have been resolved.

People Interactions
Another very positive aspect of Agile methodologies (except in what I call “certified Agile”) is the strong emphasis on people and their interactions. The exchange of information and ideas between stakeholders, implementors, management, subject matter experts, etc. is crucial to the success of any medium-to-large project. The more transparent and open communication amongst all parties, the more likely defects and imperfections in implementation, in understanding and desired outcome are caught earlier in the process. Agile has provided the key framework for such interactions so that they are purposeful and gainful while minimizing overhead.

Decomposing Large Tasks
Undoubtedly another benefit of Agile is how its framework forces large tasks to be decomposed into smaller, more manageable ones. Of course, anyone can and should decompose large tasks regardless which methodology they use. However, agile makes this aspect a de-facto requirement. Trying to reason about feedback and rapid…