Software "Agile" Process vs "Agile Process"

Software "Agile" Process vs "Agile Process"

With all the hype with agile processes, there are many pseudo-confusion in some parts of the IT world. I say pseudo-confusion because some companies think they have an agile process but really just has an "agile" process. By process, I mean software development. By "agile" process, I mean minimum to no documentation, cutting corners, and highly-adjustable schedules.

"Agile process" is a discipline. There is a process, just like a disciplined process, but with a different structure to accommodate a much high frequency of releases. There are steps that are to be followed, see agile software development methods like Scrum, Extreme Programming, and Crystal Clear. Each stressing more importance on an evolutionary development approach.

But as I experience in my work place and speaking with other professionals, a common trend is that development managers are hiding the lack of processes and documentation by explaining that their processes are now more agile. Executives hearing the buzz-word will interpret this as a good thing and now follow through.

Whether this is intentional or not, this puts a lot of weight on keeping key players because processes are no longer transparent thus not easily transferable. This "agile" process is very developer-friendly in that documentation is often bypassed, processes are not always followed, and very difficult for others to make development teams accountable for poor quality products. Similar to how software was originally developed many years ago. Without documentation or audit trails, there is no method to track accountability to issues that arise in the future.

The projects manage to keep afloat but seem to lag farther and farther behind competitors that use a formal process.  But with the growing software industry, scalability and growth is now more important than ever. Lagging due to inefficient processes will be costlier down the road if not making the project completely obsolete.

This confusion will primarily hurt the business stakeholders. Developers now have experience in the industry and thus can transfer to competitors. Development managers can claim agile methodology experience because they used the term agile. For the few that were powerless to the process, they have real experience on what worked and what failed in the "agile" methodology.