You probably have read some articles or books about agile process. John Hsieh doesn't intend to be an expert, but rather he's focused on sharing with you when and how to take advantage of what agile has to offer, and how to complement agile with other methodologies so your project has a better chance to be successful. John's discussion is a practical one: Your success is measured by delivering your software applications on time, within budget, and quality.
My first 15+ years of software development experience has all followed some process-driven methodology. Many projects I'd involved have several hundred members (system engineers, developers, testers, deployment personnel). While my first experience in Agile process was about 10 years ago, when one of my teams (~15 developers) was working on a brand new software project. At the time we didn't know the term Agile; we just called it rapid development methodology (it sounds great, right?). It was a mix of success, we did deliver something quicker, but we also have had our own fair share of problems. Now, with 20+ years of experience and a few more "Agile" ones, I will share my own humble view of whether to adopt Agile, CMM, other methodologies, or a mix of them for your project.
You probably have read some articles or books about Agile process. As such, I don't intend to be an expert to repeat all the benefits and how to go about Agile, rather I will more focus on sharing with you when and how to take advantage of what Agile has to offer, and how to complement Agile with other methodologies so your project has a better chance to be successful. My discussion won't be an academic one rather a practical one, because after all your success is measured by whether you deliver your software applications on time, within budget and with quality.
I don't think Agile is the panacea of every software development project. I would like to start with the myth of Agile as highlighted in the table below:
|Deliver a system in many incremental||A quick and loose process|
|Customer realized partial benefits sooner.
Better return on investment (may be)*
|Requires no requirement process (documentation, review, approval, etc.)|
|Opportunities to identify and correct problems earlier in the process||Requires no design process (documentation, review, approval, etc.)|
|Best for small projects (single team delivery a project in a few iterations) and internal projects||Requires less unit test or no QA process|
|Best for projects with team members are co-located.||Requires no change management, source code and version control for development artifacts|
|Requires no trace-ability & audit-ability|
Potential traps and things to consider:
- Depending on the complexity of an application, the deployment of each incremental release may require conversion tools to be developed and tested, or manual conversion may be required. Regardless whichever, this takes extra effort and may cause unexpected system down time. An obvious example is that the database schema of the new and old releases is incompatible.
- Additional time has to be allocated for "putting out fire" while developers are working on the next release, and in the same time, the current one is cut to service. This is more the case if the team were under extreme pressure to deliver the current production release. Haste-makes-waste rule do apply.
- It's human nature that under the Agile process (shorter time intervals), people have tendency to take shortcuts such as not documenting and keeping records. Even the project is successful, it may be difficult if not impossible to maintain. It is even more detrimental if some developers (living documents) leave the project while development is still under way.
- Because of too much emphasis on “speed,” often documents are out of date, or, worse, non-existing, and source codes are uncommented. What if people leave the team or quit the job? This is even more critical if you have offshore teams or outsourced development.
- Human factors are as important. People will be burned out or less effective if a project has too many iterations.