Company O decided to build two new products which targets at two different industries: one is creative-related (Indus-C), while another education-related (Indus-E). We shall reference the products as ProductA (for Indus-C) and ProductK (for Indus-E).
Now for ProductA, since it is a new concept for Indus-C, it has with few rivals in the market. However it also means that requirements for ProductA cannot be easily gathered from any form of media. Hence it collaborated with another company, which specialized in the Indus-C. Company O decided to follow SCRUM for the product development. Reason being that since they do not have concrete requirements, SCRUM (agile development process) will accommodate frequent requirement changes.
ProductK for Indus-E is actually an existing-customer-solution-turn-product, hence there are a few concrete requirements. Company O decided to use the good old waterfall model for its development process, since there are no needs to cater for changing requirements.
ProductA did in-fact goes through several sprint cycle, along with several minor and major requirement changes. The development team rush through about 3 months of continuous sprints (each lasted about 2 weeks) to bring to beta customer. However, since it is a new concept, customer was also not too sure on certain features, which resulted in more requirement changes. Again, the development team rushed through about 3 months of continuous sprints (which sometimes involve schema and major code changes).
ProductK struggled throughout its development phase due to large number of requirements, small pool of developers and tight schedule. In the end, some of the requirements were postponed til next release, while more requirements arrived from customer’s feedback. So once again, developers struggle through the tight schedule to deliver more features.
The reasons for choosing to implement or not implement Agile development processes, are based on wrong assumption. To develop a product without requirements, is a futile exercise with or without Agile process. Waterfall model worked less favorably as customer can only review and feedback at the end of development. Hence any new requirements can potentially result in major changes: database schema and code changes.
Although Agile promotes and encourages acceptance of frequent requirement changes, it does not mean that all requests are welcome. Team Lead and Software Architect should exercise caution towards new requests, and let in those that are crucial (e.g. bug-fixes), critical (e.g. show-stopping functions) and least disruptive to development (e.g. less data schema or software design changes).
Recent Comments