Blog Objective

This is a blog that attempts to make life easier by noting down the author's accrued knowledge and experiences.
The author has dealt with several IT projects (in Java EE and .NET) and is a specialist in system development.

04 September 2010

Deciding when to use an Agile or Waterfall methodology

Comparison table:

Skill level of developers:

Possible hybrid approach for Brownfield projects
  1. Site survey
  2. Engineering
    • Discovery
    • Re-engineer
    • Generate
    • Test
  3. Acceptance
  4. Deployment

What went wrong with a particular government project?
  1. Requirement solicitation happened prior to any development (as part of the tender exercise)
  2. Vendor organisation (especially management) isn’t agile enough but customer insisted on unprecedented RAD approach
  3. Supposed prototyping team is
    • Overworked – had to develop the prototype during office hours and prepare for presentation after that
    • Not agile enough
    • Not trained to be agile

What went wrong with a particular private out-sourced project?
  1. Requirement solicitation happened prior to any development (as part of the requirements specification
  2. Requirements specification was contractual
  3. Customer isn’t agile enough and was not well-prepared for SCRUM (lack of training, knowledge and acceptance)
  4. Project started with Waterfall approach but changed to SCRUM mid-way
  5. Sprint demonstration failed as
    1. system tended to be buggy or less than ready for demonstration (confidence inevitably affected)
    2. customer expected the realization of requirements to be completely thought through and analyzed prior to sprints
    3. customer expected the solution to be as per previously agreed (prior to changing to SCRUM approach)
  6. Customer had difficulty appreciating & comprehending users’ stories compared to the original users’ requirements
  7. SCRUM approach ended abruptly for product line and project team took over development
  8. On-site customer for sprints was glaringly missing. Customer proxy, BA employed by the vendor, was not representative of the customer
  9. Customer was not involved in sprints except for the sprint demonstrations

What were common between the projects that led to failures?
  1. At least one of the parties (customer, development team or the management of both sides) was not prepared for Agile methods
  2. The onsite Customer was absent
  3. Projects were contractual in nature
  4. Requirements were solicited and agreed upon. Further, some aspects of the solution may have been agreed upon
  5. Customer knows (or at least, believes he/ she knows) what he/ she wants

No comments: