Time to Revisit the History and the Absolute Basics of Agile and Scrum – Brief History of the Software Development Process – Description of the Waterfall …<\/b>
\nJoin the DZone community and get the full member experience. I have about ~16y 04m of Software Development Experience (2021) and have been working on Agile Projects since about 2006. My First Formal Introduction to Agile was through a Training by Thoughtworkers (Thoughtworks is a Leading Agile Company). This was while I was a Senior Software Engineer at Huawei, Bangalore, India. I have worked on Agile\/TDD\/Pair Programming (Various Variants) in multiple companies including Huawei, Symantec, Yahoo, Finastra*, Oracle*, OpenText*. Recently and Once Again, I attended a Formal Classroom Training (Company Internal) on Agile. I jotted down the most important points and now am presenting them in this Blog. I hope it helps and becomes a Ready Reckoner for Understanding\/Learning the Agile Basics (Needs, Motivations, Practice, and Story of Evolution).* [Original Product Firms were Acquired by these Current Companies] Formal Software Development, specifically for those who started in the field in the 1990s or even the 1980s was essentially a very Heavy Plan Driven Approach. The name given to it was Waterfall Software Development Process (As a Result of Being a Set of Successive Steps akin to a Waterfall). Even Academia captures it in textbooks with the name as the Waterfall Process. The proponent of this approach was an American Computer Scientist by the name of Winston Royce. In his 1970s paper, he first formally defined the Stage Wise Waterfall Process (Though he is not the one who named it ‚Waterfall‘). The sequence wise phrases that were identified by him are as follows: [CREDITS BEGIN: WIKIPEDIA\/OTHERS] Royce called them „Implementation Steps to Develop a Large Computer Program for Delivery to a Customer.“ Royce actually foresaw a major shortcoming in this methodology, which he described as: The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input\/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. [CREDITS END: WIKIPEDIA\/OTHERS] Sometime Later and Ignoring the Shortcoming stated by Royce, the American Department of Defense accepted this „Waterfall Model“ as the Standard for Defense System Software Development. It promoted the One-Pass Document-Driven Waterfall process. It contained sentences like \u201cThe Contractor shall establish the Top-Level Design of each CSCI by Allocating Requirements from the SRS and, if applicable, IRS to the TLCSCs of each CSCI.\u201d This was the beginning of the real widespread usage, application, and practice of the „Waterfall Model“. This model was drafted under the document DoD STD 2167. The Principal Author of this document later regretted promoting such a rigid process. He also agreed that he was not familiar with the Iterative, Evolutionary Requirements Based or Incremental Development Process. Even though, In 1987 DoD started warning against the „Waterfall Model“ – It was in such widespread usage that Organizations all over the World refused to update their Process in their Software Development Documents and\/or in Real Practice. The above events related to the Waterfall Process or the Original\/First Formal Software Development Process are often termed as The Waterfall Accident. As Everywhere Else, I am representing the Real-World Situation in Usual Software Project Development (Aggravated by The Waterfall Model). There is this one more diagram, that also emphasizes the reason as to why the above situation is created. It is primarily due to the rigidity in the process and also the barriers to moving back and forth between various phases. The diagram is good in proving that without iterative back and forth movements between the core phases, neither changing requirements can be incorporated reliably nor can any newly identified constraints. In 2001, a group of 17 Software Thinkers and Practitioners met in Utah to arrive at a set of four common values that led to the creation of the Agile Manifesto (http:\/\/agilemanifesto.org\/). I am quoting from this site directly, We are uncovering better ways of developingsoftware by doing it and helping others do it. Through this work we have come to value: Individuals and Interactions over Processes and ToolsWorking Software over Comprehensive DocumentationCustomer Collaboration over Contract NegotiationResponding to Change over Following a Plan That is, while there is value in the items onthe right, we value the items on the left more. This was the beginning of the Agile Movement\/Revolution, which now is the Software Development Process of choice across the world. The above-mentioned group of 17 people had also chalked out the Twelve Driving Principles for Teams that Adopt Agile. You may find the actual 12 principles at the following link: http:\/\/agilemanifesto.org\/principles.html Since we were discussing Waterfall, you should first understand how the Agile Process can\/should be Visualized. This will allow you to understand the Flexibility, Adaptive, Iterative, and Incremental Nature of Agile Methodology. I am also mentioning the names of these original 17 Software Developers who were the original signatories of the Agile Manifesto. They should continue to find special mention in years to come, as they were the ones instrumental in the Formalization of such a game-changing Software Development Process. Together, they published the Agile Manifesto for Software Development. Since Agile only provides Values and Principles to guide Development Teams, there are many Methods or Methodologies through which Agile is Implemented. Each of them may require an article of their own. Also, I am familiar with only about 5-6 of these Methodologies to really be able to write about them comprehensively. I am enlisting first the Software Development Frameworks through which Agile can be Implemented. I am providing only the Topmost Implementation Methods, as per my selection. There may be many more ways to Implement Agile, with some of the other Innovative Value Add being done to the Agile Process every now and then. I have also provided the Wikipedia Links so that you may directly read about them. Apart from the above-mentioned Agile Development Methods, there are multiple keywords and practices that are associated with Agile Development. I am only mentioning the ones that I am most familiar with, along with their direct Wikipedia Links. Published at DZone with permission of Sumith Puri, DZone MVB. See the original article here. Opinions expressed by DZone contributors are their own.<\/p>\n