Strategy Canvas and Value Curves for Agile and Waterfall Development Methodologies
The following sections highlight how the Agile method has created a new blue ocean of software development opportunity that has lead to improved business, software quality and customer satisfaction as compared to the earlier scenario where organizations were busy competing with each other on the basis of the Waterfall method and still trying to increase their business, software quality and customer satisfaction by focusing on improving their effectiveness and efficiency (red ocean).
The variables remain the same – improved business, software quality and customer satisfaction. However, by employing a different strategy (the agile method as compared to the waterfall method), organizations have created a new blue ocean of opportunity for trying to achieve their goals in a more effective manner.
Application of the Strategy Canvas and the Value Curve tool to Agile Methods
Keeping Figure – 1 in the backdrop, a detailed explanation of the ten factors highlighted in the Strategy Canvas are given below (Agile method examples generally refer to Scrum/XP method, but other agile methods could also be used) –
1. Customer Involvement
Agile – The customer involvement is very high. Most agile methods (e.g. Scrum, XP, etc. make it mandatory for a customer to be available full time with the development team. In Scrum, the role is called as the Product Owner).
Waterfall – The basic premise in this case was that the customer will give the requirements to the development team and subsequently after the development work was assumed to be completed; the customer will inspect the final product. By this time, the equations would have changed and on account of the changes in the market conditions and other factors, the product/service provided would have been rendered below satisfactory levels.
2. Response to Change
Agile – The Agile Manifesto gives high importance to change and agile methods are known to harness change to deliver a superior product/service to the customer as per the schedule and of high quality.
Waterfall – In this scenario, change was considered to be unwelcome and there was an elaborate process of change requests that needed to be fulfilled before the change could be implemented. Most of the time, there was a committee called the Change Control Board which will oversee all the changes before any change could be carried out in the product/service.
3. Big Requirements Up-Front (BRUF)
Agile – There are no big requirements up-front. Change is constantly harnessed during the iterative and incremental cycle and the output is produced. In Scrum, the sprint backlog contains all the details that need to be developed during the sprint. In case of any change, the next sprint will take care of the changes. However, during the sprint no changes are allowed.
Waterfall – This method focused heavily on having BRUF and the work used to go forward only after a clear sign off was obtained. This lead to a lot of delays and the final project almost invariably got delayed.
4. Big Design Up-Front (BDUF)
Agile – Here again, there are no Big Designs up-front. In Scrum with XP, during the iterations, design modeling workshops ensure that the required design for the sprint/iteration is derived and there is no stress on complete and big up-front design in the initial stages of the project.
Waterfall – This method again focused on the BDUF. Only after the design sign-off was the work allowed to go forward to the next phase, namely implementation. This led to unnecessary delays and by the time the approvals were done, additional changes led to further problems during the