There's been plenty of sentiment about Agile (capital A as my buddy Ed pointed out to me) being dead or that it's a failure or that it's in some state of decay. In a sense, I completely understand why people would think that. It may also be some of what is holding back the free thinking in the process of software development. There are few big, new ideas (outside of lean but then that's not new) that are really providing direction for the software development process.
From my point of view, this wound is self inflicted. Agile has become the hammer to nail all process problems. It was championed and supported by some really smart guys in the software dev space. Popularity grew, Agile become all the rage and, as all fads in the space, it became a personal point of pride to declare that you or your company "went Agile". There were books written about it that contained all the activities and routines you must partake in in order to be considered Agile. Training classes and certifications inevitably popped up that claimed that with 3 days of training you too could be a scrum master and Agile wizard. Before anyone knew it, Agile was a defined creature with a strict set of rules (standup meetings in the AM, planning poker, TDD, pair programming, retrospectives, etc.). It was no longer the organic process that it was supposed to be.
I certainly wasn't there in the early days of Agile but my company did "go Agile" almost 3 years ago. With it, I've found some fantastic practices that are now part of my software development six-demon bag and I've chronicled many of them on this blog. It's truly been a great addition to my craft and I would certainly advocate others to try it as well. GO AGILE! You may thank me later.
So what's the problem here? I just said Agile prevents free thinking but then I advocate that you try it. The problem isn't the Agile movement, it's how it is adopted. People want to add it to their process without appreciating where it came from and why your company should care to use it. It's the same behavior I allude to in my "The Goal" entry. Blind adoption of the Agile process isn't going to be to your benefit.
When I talk to people about a good software development practice, I no longer think in terms of the canonical Agile. Every company, every product, every team have their own unique environment and set of problems. It would be a mistake to not take those things into account before you start throwing the Agile bible at everyone. My goal is to streamline the process and use the best tools I can to reach the coveted hyper productivity. Agile is comprised of many different practices and procedures. Take what you need from it and recognize what works best for you.
Remember, Agile wasn't created from thin air. It was coined by a bunch of guys that saw waste, friction and deficiencies in the process. This is not uncommon to any of us. These are things we all see in our days, isn't it? "Wow, that meeting was useless." "The number of regressions grows on each release!" "We build what they ask for but then they never like it!" "These manual deployments take hours and they're error prone!"
LISTEN to those thoughts and react to them. As a developer I know how easy it is to identify what is going wrong and grouse about it. It feels great to vent. If I asked you what pissed you off, you'd ramble about it for hours, eventually repeating yourself but then you'd dive back into it anyways because you're that passionate about it. Take that energy and think of how you would fix things. If that meeting was useless, how would you make it better? Should you even have been there? Were there too many people talking at once? Was there one loudmouth that dominated the whole discussion?
Don't accept this reality. Change it. Make it better. Be organic in your process. Evolve. Mature. You don't need a certification to understand where things are going wrong for you. Fix it. You have manual builds today. Automate them tomorrow. You have 6 month projects with unhappy customers. Decompose them into 1 month deliverables to get quicker feedback. You have too many bugs. Increase test coverage and improve your QA. You have a schizophrenic product organization that pulls you in 8 directions? Stop the assembly line and demand consensus and priority.
That's all Agile ever was.
...but before you go, buy a book, ask questions on forums and learn about all the wonderful practices that fall under the Agile umbrella because we've learned a lot in the last decade about good processes.
