How Can Agile Scrum Reduce Regression During Software Development?

For IT development companies, and organisations developing computer and digital-devices  (smartphones, tablets, digital diaries, etc.) software projects, one of the  most important, and also the most troublesome issue is encountering “bugs” or defects in  the code functionality when a particular application, or a system, is deployed and used in  a live environment. Software bugs can be very common. Ever since computers were  designed in the yearly years, bugs have inadvertently, or otherwise, kept on troubling  coders and project managers, and have tested their ingenuity to resolve them to the  fullest extent possible. Ask any seasoned programmer - He or she will tend to initially  confer, and eventually say that the word “Bug” is aptly named – It tends to “bug” you! Etymology of the word “Bug” It is interesting to know how the terminology “bug” was first coined, and used to  describe a state of functioning in which an error, or a flaw in coding can lead to  flawed results, or “outputs” in IT jargon. There are several stories as to how the  terminology came into existence. A theory most subscribed to involves the pioneer  programmer, Grace Hopper, who was a young Naval Reserve officer working on a  Mark II computer at Harvard University. In 1944, she related an incident in which  the computer had malfunctioned – an actual moth had, in fact, “managed” somehow  to get itself embedded between two electrical relays, causing the computer to halt  in its functioning. She explained that the cause of malfunction was a “bug,” which  was later removed by a technician. The famous bug was exhibited by the Navy for  many years, and is now owned by the Smithsonian Institute.  Bugs and software regression In a broad sense, a software bug can be understood as an error, failure, flaw, or  even a fault in the code designed to develop an application or a computer based  system. Bugs typically create unexpected and incorrect results or outputs, which  cause the functionality of the particular application to stop, or function in a manner  other than so desired. Bugs generally arise owing to reasons such as: Mistakes carried out while encoding a program Designing improper code structure or logic Utilising the functionality of the code in a manner other than that recommended Technical errors in the code compilers and/or interpreting resources and agents Of course, the above are not the only causes which give rise to bugs, however, they  constitute the major reasons why bugs tend to occur in majority of the cases. When  the numbers of bugs increase significantly, the overall functionality of the application  may be compromised upon to a considerable level, rendering it useless and  non-productive. This can cause severe financial loses, and even force businesses  to face litigation from troubled end-users and consumers. Broadly, the word “regression” means to return to a former, or a lesser developed  state. So, how can regression be understood in terms of “software regression”  pertaining to software development? In practice, developers write down,  or generate code, to develop a particular functionality as requested by the  end-user or the client. During the coding stage, the developer not only develops  the code, but also checks it and ensures that it is working properly. This is a  standard practice followed by most experienced programmers and developers.  However, at times, the testing process may not be carried out properly, or the  code functionality might work properly in most cases, but fail to work under  certain circumstances and situations. A second scenario is the code may be  developed and properly tested at the time of creation, and the application  deployed in a successful manner. However, a newer version of the deployed  functionality may be subsequently re-developed to include even more features  and functionality, to replace the prior one. The reason could be a need  experienced by end-users to use the functionality for a more specific purpose.  The newer version may cause some of the older functionality to stop working.  This, in a rough sense, can be understood as software regression. For example, you could encode a program to display “Hello World” on the monitor.  It might work perfectly, and display the message each and every time it is executed.  Later on, the same code may be re-developed to accept the user’s name, and display  it in lieu of “World.” The objective of thenew code might be to display  “Hello John” rather than “Hello World.” However, once the newer code is developed  and deployed, it actually ends up displaying the user’s name only - “John” - instead  of the actual greeting “Hello John.” In this case, some of the older functionality associated  with displaying “Hello” in the greeting is curtailed due to some coding reason and  “missed out” by  the newer code. This is software regression.  Knowing a “bit” about what is Agile Scrum framework Agile is a framework. It offers guidelines as to how software based projects can be  effectively developed  through consistent and sustained delivery of software functionality through short bursts  of development activities known as “sprints.” Agile is based upon certain principles which  suggest how the framework ought to be ideally understood and interpreted by people,  and how the framework should function in an ideal working environment. One of the  Agile principles state “Our highest priority is to satisfy the customer through early  and continuous delivery of valuable software.” To support this principle, Agile  framework supports an iterative (repetitive) product incremental cycle  (a process through which smaller components or parts of the actual product are individually  developed,and later integrated to form the complete product). At the end of one product  increment cycle (sprint),Agile events known as the “Sprint Review” and “Sprint Retrospective”  are held to ascertain the reliability of the code functionality developed during the sprint,  and whether it satisfies the acceptance criteria so it can be considered as “bug free”  and fully functional. Agile promotes “shippable” product increments i.e. small pieces of  code offering a certain functionality that is complete, perfectly functional, and free  of any “manufacturing” defects.It is worth knowing about the actual Agile process, events,  roles, and artefacts which can help to eliminate bugs, and control the factors causing  regression in software code. People new to Agile concepts and principles may find the  framework difficult to understand. This article does not aim to educate the reader in  Agile or Scrum framework. Rather, it aims to explain some of the important Agile  characteristics which make the framework a very good choice for developing software  projects. The objective is to describe how Agile can help to reduce regression levels during  the development process. To understand how Agile can do this, it is important to know a  “bit” about Agile first. The product owner “PO” (Role) He or she is the person who “owns” the project on behalf of the stakeholders or project  owners.  The person represents the interests of the stakeholders in the Agile project, and ensures  that the project delivers a certain business value (importance in terms of market value  and financial implications) at all times while the product is being developed. The individual  is primarily responsible for the success or failure of the project. The product backlog (Artefact) It is a master list mentioning all features and functionalists to be developed in the  software project,and to manufacture the software product in totality. Read more at http://goo.gl/Gy8PXu