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:
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
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
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.
Tuesday, 12 August 2014
Labels: product backlog, Product owner, scrum information, scrum software, what is Agile Scrum framework
The QuickScrum community offers a single, common platform for all Scrum people to meet, talk about, and understand Scrum. The community is more of a Scrum family and offers endless possibilities for Scrum professionals, coaches, and trainers to find fruitful business opportunities. Scrum professionals can participate in events, Scrum coaches can hold workshops and share their knowledge through articles and videos, companies can post their Scrum job requirements to find productive candidates, while Scrum beginners can learn the framework by accessing the vast knowledge base and find lucrative job opportunities. There's a lot more for everyone to do!