Go to the profile of Peter Akins
Peter Akins

COMPARISON BETWEEN WATERFALL, AGILE, LEAN AND DEVOPS

INTRODUCTION

Technology has evolved over time, this has forced a need for the different software process methodologies that has been used to create these artefacts to evolve as well. These common software methodologies are agile, devOps, and lean. These software methodologies are intertwined and better than the 1970 software methodology waterfall. The extract below expands on the software development processes.

1. WATERFALL DEVELOPMENT METHODOLOGY

The waterfall development model was first discovered by Herbert D. Benington when he made a presentation at a symposium on an advanced programming methods for digital computers which was sponsored by the Navy Mathematical Computing Advisory Panel and the Office of Naval Research in June 1956 (BENINGTON, 1983).

Thereafter in 1970 was it formally introduced in software engineering as an idea through a paper published by Winston Royce. The model was believed to be a very structured approach as it was inherited from the hardware manufacture and software strategies (McCormick, 2012).

McCormick defined waterfall model as sequential process in the development of a system or software that flows in a downward progression. The sequential process often involves phases or activities which are totally dependent on each other, particularly the preceding phases. The number of phases in a waterfall model could vary depending on the software or system to be developed.

Andrzej Yatsko and Walery Susulow stated the processes involved in a waterfall software development model as follows:

  • Requirement Definition (Analysis and Specification)
  • Software Design
  • Implementation (Coding)
  • Testing
  • Deployment (Installation)
  • Maintenance
  • Retirement (Withdrawal)

The listed phases of the waterfall model will be briefly described as follows according to Andrzej Yatsko and Walery Susulow:

· Requirement Definition:

This phase as to do with the stakeholder management which requires having to interview them in order to know their expectations as regards the project. In this process, questions like; who will be the end user of the project, for what purpose will this project be built, what functions do you want inputted or outputted in the program, etc. are posed to the stakeholders. The answers to these questions are very much essential as it helps in the mapping out of project.

· Software Design:

The purpose of this phase is to simply provide a practical representation of the requirements stated above in order to create the relationships and interfaces that will help in the implementation of the requirements. This practical representation could be in the form of a flowchart or nowadays “wireframes” which, in turn, helps the developers have a clear view of the identified requirements.

· Implementation:

Having got the blueprint of the system or software, the developers may then proceed into the writing of the codes. Although the programmers are often in partnership with the designers in order to always be on track as the practical representation of the requirements, in the form of a flowchart, may sometimes be different from the documented requirement in the first phase.

· Testing:

This phase ensures that the requirements and needs of the software or system that is formulated by the stakeholder is, in fact, met accordingly having compiled the codes. Also, it is in this phase that the product is being tested for quality assurance.

· Deployment:

This simply have to do with the delivery of the project to the end-user. As simple as this may sound, it involves ensuring that the software is compatible with the user’s hardware or infrastructure. Also, it involves training the user on how to effectively make use of the deliverable.

· Maintenance:

Having delivered the software, the user begins to implement the installed software, in other words, putting the software into use, which could sometimes reveal bug and errors. As a result, the developer will be required to find possible solutions in order to fix such errors.

· Withdrawal:

As time goes by, there will be multiple error involved in the software which will allow to for the developers to create a number if patches in order to fix the error. This sometimes leads to the optimization of the software thereby yielding in a software upgrade. Owing to this, newer versions of the software is being deployed which sometimes instigates the need for withdrawal of the older version due to business reasons. Examples of this include the End of life or production of the software ending.

1.1 WATERFALL IN TERMS OF CULTURE, CONTINUOUS DELIVERY AND INTEGRATION

The culture of the waterfall model is such that testing only occurs at the end of the project which may be very expensive, provided that there is need for modification, this will cause the re-start of the entire process, from the requirements down to the very last phase in the lifecycle.

It is apparent that the waterfall does not, in any way, support the continuous delivery which entails the fast and automated feedbacks on the production of software which, in other words leads to the deployment of software at the end of each phase in the lifecycle. These processes are clearly not present in this model. The only time feedback and deployment is made is at the end of the waterfall model. This fact equally shows that it doesn’t incorporate continuous integration as this is what leads to continuous delivery.

Apparently, software development companies using the waterfall model approach spend so much time getting their product because, not until a particular phase of the model is completed will they proceed to another phase. Owing to this, Josef Langerman; a DevOps savvy, literally stated that the waterfall model is, in fact, a misnomer considering the free flow and downpour of water from a certain height but, unfortunately, the waterfall model’s principle of flow happens to be in a linear process which makes deployment and delivery generally slow (Langerman, 2016).

2. AGILE SOFTWARE METHODOLOGY

The advent of waterfall model caused a diffusion of innovation in the 1980s in that, the best way to develop software was through careful project planning, formalized quality assurance, the use of analysis and design methods, and a meticulous and controlled development process (Sommerville, 2012).

Ian Sommerville stated that, during this time, a community of software engineers were responsible for the development of large software systems e.g. the government systems, control systems for a modern aircraft etc., which takes a long period of time before execution considering the scope of the project. The control systems for the modern aircraft for instance, was envisaged to last for 10 years from the specification phase to the deployment phase.

Putting into consideration the heavyweight approach in planning, designing, documenting etc., these traditional processes in software development were all deemed to be an overhead that was quite large so much that it was dominating the entire software process with regards to how much of a time which was spent on how the system should be developed than on the implementation of the code and testing. As a result, there was dissatisfaction with the linear approach considering the fact that the system requirements often change, which may warrant the need for rework, especially in the specification and design phase.

Unfortunately, the linear approach being very inflexible doesn’t support a sudden change in development cycle. This led a set of software developers to break away from the traditional, structured, and bureaucratic approach to software development and ported to a flexible development style hence, the agile methods which was proposed in the 1990s. This in fact, made agile to focus more on the software than the design and documentation (Sommerville, 2012).

Kathy Schwalbe stated that, In February 2001, a group of people, 17, to be precise, which called themself the Agile Alliance created and agreed on the Manifesto for Agile Software Development which reflected the philosophy behind the agile methods. The Manifesto states thus:

We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:

· Individuals and interactions over processes and tools
· Working software over comprehensive documentation
· Customer collaboration over contract negotiation
· Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more (Schwalbe, 2014).

2.1 AGILE; CULTURE, CONTINUOUS DELIVERY AND INTEGRATION

With the Manifesto developed for agile software development, it is crystal clear that agile is not a process, unlike the waterfall model, but, it is, in itself, a culture. This is such that, the mere thoughts of the term agile, in itself, depicts the rapid delivery of something, which, in our case, is that of software (Sahota, 2011).

Having said that, an inkling ought to have been gotten regarding the fact that the culture of agile embraces the aspect of continuous delivery and integration. Continuous delivery simply shows the rapid process of the transfer of coding aspect into the building, testing and deployment phases through continuous integration, meaning that the binary which is deployed into the code had been committed into a source control which makes it easy to deploy the codes into building and, subsequently, testing, having detected errors and bugs early enough (Binstock, 2014).

3. LEAN SOFTWARE METHODOLOGY

The global competition that is present in the community of software development has resulted in an ultimate search for a way in which qualitative software can be developed in a rapid, repeated, and reliable fashion. Lean, which was actually originated from the manufacturing industry as far back as 1950, during the Toyota Production System (TPS), has got its initiatives in the manufacturing, services, and product development which have led to improvements in cost, quality and time of delivery of products (Poppendieck, 2006).

Tom and Mary Poppendieck stated that this concept has been transmitted into the aspect of software development and it actually focuses on satisfying customers by giving them what they want, when and where they want it, without any form of wasted time. This is simply the culture and thinking of lean.

Tom and Mary Poppendieck again stated that there is a difference between product development and operations, as techniques that are successful in operations are inappropriate for the process in development. The table below shows the similarities between Lean Manufacturing and effective product development:

Table 5.1; Similarities between Lean Manufacturing and Effective Product Development (Poppendieck, 2006)

Lean is a way of thinking in which organizations are allowed to specify their values, line up their value-creating actions in a proper sequence, conduct these activities when requested without any form of interruption, and then perform them in an effective way (Xiaofeng Wang, 2012).

3.1 PRINCIPLES OF LEAN

Some of the principles of lean that are relevant to software development includes the following:

1. Eliminate Waste,

2. Build Quality In,

3. Create Knowledge,

4. Defer Commitment,

5. Deliver Fast,

6. Respect People,

7. Optimize the Whole As a group, etc.

Tom and Mary Poppendieck stated that these principles provide guidance on how to deliver software faster, better, and for less cost in a parallel process.

Lean’s primary aim is basically the identification and elimination of waste, as well as every form of unevenness from the software development process in respect to the customer’s value. Waste and unevenness in Japanese is referred to as Muda and Mura respectively (Xiaofeng Wang, 2012).

Xiaofeng et al. stated that lean thinking classifies work into three categories namely;

· Value-adding activities

· Required non-value adding activities

· Non-value adding activities

Processes that do not add value to the development of the software can be easily identified and eliminated by mapping out the processes with the aid of a value stream map. The identification of waste is highly essential as they could be broad and context-dependent (Xiaofeng Wang, 2012). Waste can be classified as waiting, extra features, extra processes, partially done work etc.

3.2 LEAN PRACTICES

Xiaofeng et al. did confirm that development practices of lean already have been established in the agile methods which have equally been classified as the agile practices. In fact, the origin can be traced back to the days before the conception of agile i.e. the pre-agile days. Nevertheless, the empirical data in terms of lean approach was categorized in order to generate a list of lean specific practices as regards software development.

Some of the Lean software development practices according to Xiaofeng et al. (2012) are as follows:

· Address bottlenecks with the aid of a Cumulative Flow Diagram (CFD)

· Avoid too much optimization

· Hansei: Relentless self-reflection, to acknowledge one’s own mistakes and to commit to making improvements

· Hide individual performance

· Kaikaku: radical improvement within a limited time

· Kaizen: continuous improvement to establish a smoother flow

· Value stream mapping: analyse and design the workflow required to bring a software or service to a customer etc.

3.3 Lean; Culture, Continuous Delivery and Integration

It is crystal clear after having analyzed the principles and practices of lean that the culture doesn’t, in anyway, accommodate muda and any form of mura in the development process of a software. Also, any business practice that incorporates lean is solely dependent on continuous delivery (Johnson, 2013).

Scott Johnson stated that the lean startup model requires that cycles be released in a quick proportion as well all as constant testing against customers. There cannot be quick and frequent release cycles if the IT operations team are manually configured. The success of continuous delivery is dependent on automation throughout the process which entails that the IT team should have a thorough understanding of the software development process, and that the developers should equally have an understanding of the IT operations. These relationships between development and operation teams shows that lean startup builds on devops practices which helps in taking advantage of the quick delivery cycles (Johnson, 2013).

4. DEVOPS DEVELOPMENT METHODOLOGY

DevOps began in Belgium, in the year 2007, when Patrick Debois who happens to be a consultant took a project with the government ministry regarding a large data center migration. In this project, he happened to be in charge of the testing where he struggled in relating with the development and project team. This is platform on which the idea emanated thereby formulating DevOps as bridge between developers and testers (Edwards, 2016).

In comparison to Waterfall, Agile, and Lean, DevOps is the proverbial new kid on the block. It is not a methodology neither is it a framework. DevOps builds on the Lean and Agile methodologies (Langerman, 2016).

Damon Edwards defined DevOps as a response to the growing awareness that there is a disconnect between what is traditionally considered a development activity and what is traditionally considered an operations activity.

The diagrams simply show the differences as regards the area of interest in each department of development and operations. The development crew are employed to respond to change in an organization and as a result, it is their ultimate goal to ensure that there are continuous changes. On the other hand, the operational crew have a view of change as an enemy owing to the fact that the business depends on them to keep the lights on and maintain stability and reliability in the organization (Edwards, dev2ops, 2010).

Apparently, there are two areas of interest in a team which will, no doubt, create a wall of confusion between these two departments hence, the need for DevOps; to break this wall and rather create a bridge that will allow for flow and quick deployments of deliverables in each lifecycle.

4.1 FUNDAMENTALS OF DEVOPS

Wurster, et al. (2013) described the fundamentals of DevOps as the following:

· Cross-functional team and skills: DevOps aims to expand the boundaries by integrating the process of operational and functional roles while Agile focuses on reaping the benefits of integrating development and quality assurance roles.
· Continuous delivery: Ongoing updates, applications, and every important aspect of the development lifecycle are made more frequently in smaller sizes in order to avoid service disruption.
· Optimum utilization of toolsets: The cross-functional teams i.e. development and operations implements the same tools where necessary.
· Automated deployment pipeline: DevOps initiates the creation of automated deployment model pipeline in order to allow for a frictionless deployment in the development lifecycle.
· Continuous assessment: The DevOps environment recommends the continuous assessment of application development and release process.

As much as DevOps has proven to be a culture and not a methodology, the need for continuous integration is highly essential considering the fact that apps are often measured according to throughput and ops according to the stability. The differences will cause a delay as regards continuous delivery, which allows for small batch and iterative developments in the project lifecycle (Hammond, 2011).

In contrast to agile and lean whose primary aim is to rapidly adapt to the market and environmental changes in order to resolve the issue between business and developments, DevOps primary aim is to resolve the wall of confusion between the development team and the operation team.

5. CONCLUSION

In this research, the Waterfall model, Agile software development, Lean and DevOps have been explicitly described, thereby showing the differences between these models.

For instance, the waterfall model which embarks on a linear, plan-driven approach is most useful in the aspect of software engineering where the plan and specifications will have been well spelt before the commencement of the project. This kind of project requires less user involvements.

Agile and lean share the same principles as they both embrace rapid changes from end-users and delivers feedbacks of software at the end of each lifecycle through continuous integration and continuous delivery. Although agile methods are widely used as an approach to the effective management software development while lean principles were originally designed for improving the quality of production in a software development process.

DevOps aims at bringing the developers and operations together under the same environment after having resolved the disconnect between them as stated by Damon Edwards, and have created a bridge in place of the wall of confusion.

6. References

Andrzej Yatsko, W. S. (2015). Insight into Theoretical and Applied Informatics.

BENINGTON, H. D. (1983, May 5). Retrieved from http://sunset.usc.edu/TECHRPTS/1983/usccse83-501/usccse83-501.pdf

Binstock, A. (2014, May 5). Dr.Dobbs. Retrieved from http://www.drdobbs.com/architecture-and-design/continuous-delivery-the-agile-successor/240169037

Edwards, D. (2010, February 23). dev2ops. Retrieved from http://dev2ops.org/2010/02/what-is-devops/

Edwards, D. (2016). ITREVOLUTIONPRESS. Retrieved from http://itrevolution.com/the-history-of-devops/

Johnson, S. (2013, October 3). Puppet. Retrieved from http://puppet.com/blog/continuous-delivery-and-lean-startup-principles-can-they-work-for-you

Hammond, J. (2011, September 9). Forrester. Retrieved from http://blogs.forrester.com/jeffrey_hammond/11-09-09-the_relationship_between_dev_ops_and_continuous_delivery_a_conversation_with_jez_humble_of_thought

Langerman, J. (2016, May 5). Medium. Retrieved from Medium: https://medium.com/@josef_89142/big-it-rising-b98826b68364#.zgeknkvkc

McCormick, M. (2012, May 5). Retrieved from http://www.mccormickpcs.com/images/Waterfall_vs_Agile_Methodology.pdf

Poppendieck, T. P. (2006, November 3). InformIT. Retrieved from http://www.informit.com/articles/article.aspx?p=664147&seqNum=7

Sahota, M. (2011, May 6). Methods and Tools. Retrieved from http://www.methodsandtools.com/archive/agileculture.php

Schwalbe, K. (2014). Introduction to IT Project Management.

Sommerville, I. (2012). Software Engineering.

Xiaofeng Wang, K. C. (2012, February 15). Leagile Software development: An experience report analysis of the application of lean approaches in agile software development. pp. 1–13.