Strange how people want to blame agile processes for project failures, instead of the people who are implementing the processes. I’ve been involved in the agile world since 2005 and developing software since 1992. My understanding has always been to bring value to the customer with software that works the first time and meets the needs, wants, and desires of the customer. After all, isn’t that why all those experts got together in Snowbird, Utah in the first place? We, as a collective group of software developers, were developing crappy software that didn’t meet the needs of the client and 75+% of the software development projects failed. We can blame management, the clients, and anybody else, but in the end we have to point the finger at ourselves because it was our code that was failing.
Lean, Kanban, Scrum, XP, DSDM … these are all processes that help us do our jobs better. However, they are not the magic bullet to quality software or to bring value to the customer, they do not address every single problem one might experience on a project. That’s why we have brains, so that we can think, we are not stuck inside a box because some process doesn’t address a certain problem. We can break out of the process when we become the masters of the process and make a way to overcome the situation at hand. Remember the Sho Ha Ri concept that Lyssa Adkins talks about in her book “Coaching Agile Teams”.
And by the way, when was the last time you released code that had defects. I see it every day, people “say” they are doing agile but they are neglecting one of the basic premises that was even around before agile, don’t deliver code that’s broken, in any way; a sev 4 defect is still a defect, accept it, deal with it, and fix it before it gets delivered to the client. Do not allow a deadline, a Project Manager, or a client push you into releasing code that has defects.
Agile is all about creating and delivering defect free code that brings value to the customer, there is no argument about this.
One of the problems we have seen is that Corporations have been demanding prospective employees to have some type of agile certification, and that has trumped years of experience, thus all of the certification mills started popping up. Nowadays, it’s difficult to get a job without some type of certification from one group or another; then again, we had the same problem with software development. If you’ve been in software development for at least 15+ years you should remember all the hoopla about getting Sun Java Programmer certification back in the 1990’s, then Microsoft Developer certification, MVP certification, etc. I remember a company would not even interview me because I wasn’t a Sun Certified Java Programmer, even though I had 3 years full-time experience writing software for real, paying clients.
The point for me is if you are going to say you are using agile then learn everything you possibly can and then do it, don’t just use the terms and fancy catch phrases. If you fail, look inside yourself, what caused the failure, how could you have prevented the failure, and what can you do to keep from failing again. Sounds familiar … could that be called a Retrospective in Scrum, back in the 1990’s we called them Lessons Learned, but of course we never had time to do them … so we never learned from our mistakes until someone got fired or we lost a contract renewal .. then we learned.
Finally, remember that even when someone gives you directions on how to get to a location, you may experience unexpected detours and roadblocks along the way, this doesn’t mean the directions were bad or wrong, it just means that some things cannot be anticipated and you have to learn how to improvise, adapt, and overcome.
Don’t just do agile, be agile, then become better.