Member-only story
What Agile Got Right (And Wrong)
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.
