Background
Blue Ocean Strategy is a business strategy that was initially published in a book – “Blue Ocean Strategy” in 2005 and the founders of the strategy were W. Chan Kim and Renée Mauborgne of The Blue Ocean Strategy Institute at INSEAD, one of the top European business schools. The focus is on the creation of high growth and profits an organization can generate by creating new demand in an uncontested market space, or a "Blue Ocean", than by competing head-to-head with other suppliers for known customers in an existing industry (“Red Ocean”). Based on 15 years of research, the authors used 150 successful strategic moves spanning 120 years of business history and across 30 industries to bring the Blue Ocean Strategy theory to life.

Agile Software Development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software and a business approach that aligns development with customer needs and company goals. The earliest agile beginnings were initiated in the 1960’s and over a period of about 40 years, it has evolved considerably and it is now beginning to develop as the mainstream software development methodology across the IT industry.

There are many specific agile development methods. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. Some of the popular agile methods are Scrum, XP, DSDM, Adaptive Software Development, Feature Driven Development (FDD) and other methods.

The earlier method used was termed the Waterfall approach to software development where the software product/service evolved based on a series of steps starting from requirements, analysis and design, code, test and deploy in a sequential manner as part of the software development lifecycle. The Waterfall method is still being used for software development and it is effective when there are no changes proposed in the software being developed. However, in the real life scenario, this does not work well for commercial and application software development where there are constant changes in the software being developed due to customer requested changes or on account of other factors like technological changes, changes in the industrial and business scenario and other factors.

Introduction
The Blue Ocean Strategy gives important insights regarding how to create new market space in uncontested markets thereby making the competition irrelevant. There is no reason why this strategy cannot be adopted for explaining the significance of the usage of agile methodologies as compared to the Waterfall method of software development in commercial software development where the request for changes from the customer is very high.

The interesting aspect of viewing the agile software development methodology under the Blue Ocean Strategy framework highlights some very interesting points that are at the same time quite intuitive and also rational.

One of the important analytical tools and frameworks provided by the Blue Ocean Strategy is the Strategy Canvas and the Value Curve. These tools help to define the characteristics of the organization with respect to important factors affecting the organization and help the organizations regarding how to create new markets.

By applying a similar technique to the agile method of software development, we can derive the Strategy Canvas and Value Curves for the Agile and Waterfall method of software development based on ten important parameters that factor in all the important requirements regarding the usage of the two methods (Figure – 1).

Figure 1 – 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 development life cycle.

5. Process Documentation
Agile – Agile also derives its philosophy from other knowledge domains, most notably - Lean. Hence, the focus on process documentation is limited to the extent that useful and meaningful value added information required for the specific task is maintained and is available to the user. The mode of storage of information is also very flexible and the information could be stored in the form of audio, video, text or any other type of storage.

Waterfall – The method focused heavily on having documents for all the steps followed during the development life cycle. This led to extra effort spent for documentation and which did not add value as many times, the documentation developed was so extensive that there was no sufficient time to go through the documentation created. This led to wastage and it also compromised on the principles of Lean Thinking.

6. Risk
Agile – Focus on iterative, incremental, risk based and client driven software development ensured that the highest items of risk were addressed in the initial stages of the project. In Scrum/XP, the initial sprints/iterations ensured that the highest risk items were addressed initially based on the prioritization carried out by the customer in association with the project team.

Waterfall – As the method and the life cycle steps followed were sequential, the risk items were not addressed appropriately and there were generally greater issues pertaining to risk that were still not addressed during the later stages of the project.

7. Business Value
Agile – No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by the stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals. Hence, the focus on business value is paramount.

Waterfall – As the customer observes the product/service only after all the steps have been completed, the lag time ensured that no adequate business value could be addressed in a short period of time. This led to significant problems during the later stages of the project.

8. Individuals and Interactions
Agile – Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.

Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. Most agile teams work in a single open office (called a bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.

Larger development efforts may be delivered by multiple teams working toward a common goal. This may also require a coordination of priorities across the teams.

Generally, in Daily Scrum, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems from being hidden.

Waterfall – The emphasis on individuals and interactions was limited and more focus was given to ensuring that the sequential steps followed were adhered strictly and sign-offs were obtained from one phase to the other. This again led to issues during the later stages of the project.

9. Planning
Agile – Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("time boxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to the stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly.

Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features.

Waterfall – Planning was considered a key factor in waterfall method. A significant percentage of the time was spent on planning how the project will be executed up-front. However, as the business scenario changed frequently, the plans needed to be updated frequently and the plans began to lag and this led to issues as the initial plans could not be adhered.

10. Working Software
Agile – Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.

Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality of the working software and enhance project agility.

Waterfall – The focus being on the delivery of the product/service based on the sequential steps followed in the method ensured that the lead time from the requirements elicited from the customer to the final delivery was huge and this lead to a lot of differences from what the customer had said and what had been delivered.

Summary
The above sections do not necessarily critique the waterfall method against the agile method. They only indicate how issues arise in business and how agile takes a different perspective of the same issue and by using alternative techniques, the issues are mitigated. Agile methods are not a silver bullet that can solve all the business issues. However, what they can do is that they alleviate the known issues to a great extent by focusing on a different approach to software development.

Waterfall methods are still used in legacy systems and other areas and they are generally found to be useful in those scenarios where the requirements are clear up-front and there are no changes needed by the customer. However, this is an increasingly rare scenario, especially in commercial software product development and this has catapulted agile methods into the mainstream IT industry.

By adopting the Blue Ocean Strategy, we can observe how the agile methods have opened up new business opportunities by focusing on alternative techniques to resolve the perennial business problems and how this leads to value innovation (low cost and value differentiation). The above example was one aspect of using one type of tool presented in the Blue Ocean Strategy. Additional tools and techniques presented in the Blue Ocean Strategy may also be used to further highlight the approach of agile methods in creating a blue ocean of business opportunity/relationship vis-à-vis waterfall method. Additionally, what is a blue ocean today may become a red ocean subsequently and this is a process of continual improvement.

With more complexity in IT projects and a need to respond faster to changing markets, teams have had to adapt the way they work. The solutions they are using are just not meeting these new requirements. The need for organizations to do more with less means that the need to optimize resources and enhance productivity assumes paramount significance and in this aspect, agile methods promise and deliver good quality, optimal cost software to the customer within the committed timelines thereby leading to greater customer satisfaction and further business opportunities in the future.

Conclusion
The key point to be noted here is the parallel between new customers being created in the Blue Ocean as explained in the Blue Ocean Strategy and the new relationships being generated and renewed when implementing agile methods as part of your software development life cycle as the customer may still be the same but the subsequent relationship with the customer which is created will be different.

Thus, the application of the Blue Ocean Strategy as relevant to agile methods vis-à-vis waterfall method presents a useful and different perspective on how agile methods have helped the IT industry to develop new business relationships and opportunities and also strengthen existing business relationships by looking at the same business problems through a different lens.

References

1. Blue Ocean Strategy – W Chan Kim and Renee Mauborgne, Harvard Business Press, 2005
2. Wikipedia - http://en.wikipedia.org/wiki/Blue_Ocean_Strategy
   
3. Agile Manifesto - http://agilemanifesto.org/
   

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview