Is Being Agile Really Something to Strive for?
Agile development is all the rage nowadays. Anyone who has worked in web development for any length of time has, undoubtedly, worked for a company that "does Agile". Now, agile is one thing if its kept within the development team, but when "business people", who don't know the first thing about developing software, start talking about "Agile", a development team can be in for a rough ride. What "being Agile" usually means to a business person is something along the lines of:
"We use an iterative, flexible process to position our development team to quickly respond to the needs of our client base in a fast-changing marketplace."
What they are really saying, through their actions, is:
"We don't have anyone in our business who remotely understands our product's business domain, nor do we have anyone who has the communication skills to talk with current and prospective clients to determine what their needs may be in advance. Rather, we are going to just sit around with our heads in the sand and tell you to start working on something and then change direction halfway through. Our customers are always right and, no matter how ridiculous or impractical their requests, we will always drop everything to accommodate them."
Now notice, I'm talking about when Business People say they want to use agile, not people whose primary duties are either working as a software engineer or in managing the engineering team directly. The problem here is that the business folks, good intentioned as they are, have hijacked a term that sounds appealing and re-purposed the phrase.
Agile is an engineering term, plain and simple. It can encourage good practice by keeping projects modularized and concise. It encourages breaking down large concepts and ideas into smaller chunks that can be iteratively fit into release cycles. Agile does not, however, mean that ideas like "market research" and "product vision" suddenly become passe. At its core, being Agile really just means that the engineering team will use sound development practices by making sure that the code is loosely coupled so that some things that may have been planned originally can be left out, if needed, and some small things, namely "usability bug" fixes, can be put in, without too much hassle.
What Agile should not mean is that every few days some "idea man" businessperson pops his head into the development meeting and proposes a "new direction" for the project that the team will start work on "as soon as we get started on the next iteration". If this happens, its likely because the "idea man" is actually prototyping a product, not overseeing something that is being engineered to go into production and start being used by real users.
The inability of some business people to understand the difference between prototyping and regular development is, what I believe, often leads to problems. Not surprisingly this tends to occur the most in small companies that have limited resources. There's always the non-technical startup founder who wants to be bringing in revenue today by finishing off the remaining bugs on the application that's "just about ready" to start a case study with customers, but also needs a little help in developing prototypes, since this "helps him think" and develop ideas for adding on to the product.
In reality, if an engineering team is doing major development that will go into production, it should, at minimum, probably have been thought out at least a few months in advance by the stakeholders and have went through a "vetting process" to really determine exactly what is needed. Then this would have been broken down into tasks to fit into the Agile model. This is, of course, oversimplifying the design and requirements phase, however suffice it to say that Agile doesn't mean you "don't do requirements up front". Agile does allow for more flexibility but it should never mean that there is not a clear road-map, prioritization of tasks and early recognition of dependencies between tasks.















