The essence of Agile lies in being able to define the requirements in such a manner that the product/ solution gets created with features that are implemented incrementally. Unlike waterfall models, we do not need to wait till the business users are able to visualize and define the entire requirements fully before starting off with the designing and other phases of the product/solution. The Agile philosophy is for the entire team, a set of experts in their own fields, to own up the solution and move fast towards achieving the milestones, with intellect and understanding amongst themselves. Agile is adopted by businesses with the objective to be able to market/implement the product/solution early, in order to start reaping the benefits as quickly as possible. The objectives could differ depending on the business model. Few objectives for adopting agile could be as follows:
Catch users’ attention and get them interested in the new product by launching it early, highlighting some of the major features that convey the vision of creator/innovator. Newer features can be then incrementally introduced.
Reduce maintenance costs of corporates by introducing new systems and getting rid of the legacy systems.
Launch the solution (like online shopping site, job related web sites) with a few critical modules and start reaping the benefits quickly.
Many-a-times, the entire system’s requirements clarity is missing, even though the business may know what it wants on-the-whole. In such cases it is important to adopt Agile. It is important for business users to be able to visualize the product/ solution skeletally as a whole, and be able to pass on the vision to the business analysts. Then they should give guidance on aligning and planning the
dependent features together, and that would reduce the risk of huge changes & rework in the subsequent iterations. The business analysts’ responsibilities increase many folds of being able to visualize and translate what the business users want and define requirements incrementally. Requirement volatility actually defines success or failure of any Agile project. Also, the efficiency with which the requirements are broken into stories makes huge impact on the achievement of goals. If the business analysts are able to visualize the iteratively incrementing product and define the stories; keeping in mind the impact of each such story on the already defined/implemented product, the going is smooth.
It is important for business users to be able to visualize the product/solution skeletally as a whole, and be able to pass on the vision to the business analysts. At times just for the sake of adopting Agile model, which is in vogue, certain contracts are signed without even analyzing whether business teams would be able to visualize and define requirements incrementally or not. In such cases the sequencing of stories are completely unorganized and randomly picked, causing chaos and huge rework during each of the subsequent iterations. This results into additional effort and cost. To quote an example, one such project was picked recently where the stakeholders, from the client and the vendor realized quite too soon the mistake of defining Agile model for the project. The requirements included heavy UI components with multiple grids, almost like an excel sheet, and complex calculations, along with all possible complex algo-
Feedback: email@example.com, Prashant@pminorthindia.org
Synergy June 2014, Page
June 2014 (10th) Issue of PMI North India Chapter's Quarterly e-Magazine