The scope of
development in the software/IT field
People and individuals associated with software development and the
IT field like to use the term “software development” to describe their
particular field of work and professional involvement. The term “development”
is very widely used to describe a host of activities catering to the IT field.
It can range from developing code for applications and systems, to developing
mobile applications for mobile operating systems such as Android, iOS, Symbian,
Windows OS, etc. (visit http://en.wikipedia.org/wiki/Mobile_operating_system), “manufacturing”
gaming software using scripting languages like Ruby, AGSScript, Lua, Marathon
markup language, Ada, C++, C#, D, Lisp, Mercury, Pascal, Perl, Python, Scheme,
JavaScript, Java, VBscript, EDL, etc., (visit http://en.wikipedia.org/wiki/List_of_programming_languages) carrying out web
development using HTML, CSS, PHP, Joomla, DotNetNuke, Java, etc., and even
developing entire operating systems for tablets and PCs (visit http://en.wikipedia.org/wiki/List_of_operating_systems, to know more about
operating systems). The fact is as on today, the terminology “software
development” is extensively used to mention almost any type or activity
associated with the programming and development of “computerizable” code of any
type, in any way, or manner. When a particular methodology or framework is used
to develop computerizable code and create software projects, it is important to
ascertain whether the scope of development includes the specific activity you’re
currently involved or associated with. Software development and projectmanagement frameworks such as Agile have the potential to develop successful IT
related projects involving the vast majority of development platforms and
operating systems.
While explaining Agile in a simple and straightforward manner, it
can be best understood as a collection of project development methodologies and
frameworks, of which any framework or methodology can be used in a successful
manner to dynamically develop projects of almost any type and nature, including
software development projects. The framework is based upon iterative and
incremental development, in which self-organised and self-managing development
teams understand, plan, and develop projects under the supervision of a project
leader, and offer productivity in the form of short bursts of development
cycles (iterative development) known as sprints. A unique feature of all Agile
frameworks is that the development carried out by the team is “shippable” in
nature i.e. the code developed during the product development cycle is
independent, testable, verifiable,
documentable, and ready for deployment after it is stringently checked
for any “manufacturing” defects.
A second, highly important feature of Agile development is that
individuals “owning” the project are closely linked with the approval of
development carried out by the team. A particular “code” or “piece” of functionality
is checked for regression after it is developed, and subsequently presented to
the stakeholders and project owners. They ascertain the development carried
out, and clear it as “OK” for future integration into the actual product. This
leads to a successful development of software projects, since the management is
always aware about what functionality is currently being developed by the team,
and up to what extent it satisfies the project objectives. If the project
owners feel the productivity offered by the team is not up-to-the-mark, or
fails to satisfies them in terms of business value (how much important the code
or functionality is from the market point of view, and how much it is worth
from the financial point of view) offered by the functionality, they can reject
the entire functionality and instruct the project manager to redevelop the
particular script or code, based upon a new set of inputs and requirements recommended
by them. This ensures that the software project always “maintains” its business
value at all times, even while the product is being currently developed.
A third important feature of Agile framework is that all activities
in the project are “time boxed”, and therefore, have to be completed within a
predetermined time period. In an Agile project, each activity is time bound.
All development related activities are “configured” to suit the unique project
needs, and a duration “affixed” to them so they can be completed within a
stipulated time. This ensures that the project does not “drag-on” and extend
indefinitely. The development costs incurred while the project is being
developed can be properly and “profitably” controlled, so that the project does
not become “too” expensive and difficult to afford financially.
Agile framework differs drastically when compared to traditional
linear or Waterfall methodology. In Agile, project development is carried out
in short bursts of activities rather than in stages that have to be “completed”
one after the other.
The main Agile features include:
· Cross-functional
development teams consisting of developers, programmers, testers, QA personnel,
technical writers, system analysts, etc. all work together as a single
composite team through collaborative efforts, offer and share ideas, and help
each other during the development process.
· Working in short,
fast-paced development cycles, with focused objectives – Iterative development.
· Shippable productivity
at the end of iterative development cycles – Incremental development. The
functionality keeps on “growing” through development cycles until the entire
application, system, or product is developed.
· Human communications
and involvement takes precedence over management authority and delegation of
work.
· Total transparency and
visibility of the team progress to project owners, stakeholders, and end users.
· Feedback and
suggestions help to self-correct and offer new ways and means to carry out
quicker, more efficient, and reliable development.
An important feature of
all Agile frameworks is that the frameworks are independent of the nature of
project to be developed i.e. the framework is not dependent upon the platform
or environment used to develop the particular software project. The architecture
or design can vary, and could be anything. The important aspect is that an Agile
framework has to be implemented in the project first, and its benefits availed
subsequently. Please visit http://en.wikipedia.org/wiki/Agile_software_development.
Scrum, briefly, is a
“light weight” Agile framework, used extensively for developing and delivering
“workable” software products, very often, and on a consistent basis. The
software products can range from the development of new web processes and
systems, gaming solutions, plugins, mobile apps, ecommerce websites, corporate
portals, development of WordPress themes, RAD (Rapid Application Development)
projects, OOPs (Object Oriented Programming) projects, CAD/CAM drafting
solutions, port programming and configuration utilities, web development and
platform interfacing solutions, etc. Scrum adheres to all Agile principles and
features discussed above since the framework is “inherited” from Agile itself.
Scrum offers a new,
and a better way of managing software projects. There are many technical
reasons why Scrum is popular and why many Fortune 500 companies prefer to use
the framework for their project development purposes. While being introduced to
Agile Scrum, a question that inadvertently comes to one’s mind is why is Scrum
so popular? Why is there so much “hype” about Scrum? Does Scrum offer a magic formula,
which can work wonders for your project and software development? Why should an
organisation that has been following a particular development methodology, and
feels comfortable doing so, should change over to Scrum? There is a separate
article which deals entirely with why you should opt for Scrum. The point is,
this article focus upon explaining Scrum to individuals who are new to the
topic, and have absolutely no idea what the framework is all about, and what it
can “do” for you. Efforts have been made to explain that Agile Scrum is
applicable to almost any kind of software development, and possesses certain features
which make the framework very popular as well as “powerful”.
The actual Scrum
process can prove to be difficult to understand, at first, for Scrum beginners.
Even though Scrum implementation is not difficult, people need to understand
and familiarize themselves about what is product increment, and how it actually
occurs during the Scrum process. The second aspect is getting to know about
Scrum events. The special meetings, known as “events” are important for
monitoring the development activity, and analysing the reliability and
effectiveness of the functionality developed by the team. They also help to
solicit feedback from the team members as well as the project owners so that
the business value of the project is not affected, and maintained at all times
– even while the product is being developed. It is worthwhile to get an
“overview” of the process first.
 |
1.
Project conception - An idea!
All
projects, whether involving software development, or otherwise, start with an
“idea”. Projects are developed out of needs. A project is planned to fulfil a
particular requirement or achieve a certain objective. Moreover, each project
results into “something” within a specific time frame – a project cannot extend
indefinitely. It is important here to differentiate between a “project” and a
“program”. Programs are generally long termed, and can even last for years,
unlike projects which have a relatively short life span and last for a brief
period, ranging from a couple of months to even a year.
Typically,
a person, or a group of individuals realise it is worthwhile to put in efforts
and resources, and develop “something” so that “another thing” can be easily
fulfilled or availed. The “something” is the product, and the “another thing”
is the solution that the project is supposed to provide. This stage of project
development involves a lot of discussion and brain storming sessions, where the
product is envisioned and “though over”.
Scrum
does not figure during this stage. However, the vision seen by the project
owners, can, or may, affect the manner in which Scrum is implemented in theproject, in the future. This is because the nature of product to be developed
may require Scrum to be configured in a certain manner to obtain positive
results from the project.
2.
Project release – Getting started with the software
project
Once the
project is “thought about” the next logical step is to work out the
nitty-gritty concerning the project dynamics – the objective of the project,
the product definition, how the project should ideally deliver the product, in
what manner, what should be the “strength” of the team, how many team members,
etc.
Scrum development
process does not come into the picture even during this stage. The
documentation pertaining to the project is created and “everything” concerning
the product to be developed is finalised – in black and white. Scrum does not
advocate extensive documentation. You do not have to prepare detailed system
flow diagrams and extensive design structures to get started with Scrum
development. A basic idea will suffice, and you should only spend that much
time and efforts which can get you “started” with the actual development
activity. Just enough information and specifications to develop some of the
most important product features.
The
project release is attended by the “Product Owner” – the person who functions
as a project manager in the Scrum project, the Scrum Master who overseas that
Scrum is properly implemented and followed by the team while the project is
being developed, and the stakeholders or project owners who actually sponsor
the project.
3.
Creating the product backlog (Product Features List) –
Defining the product features and functionality
The Scrum development process starts with the creation of a master list containing all
features and functionality required to create the product in totality. In
simple terms, the entire product, currently existing on paper as “imagined” by
the stakeholders and project owners, is “broken down” into its constituent
parts, consisting of individual features and functionality. The product is
thoughtfully, and systematically, broken down such that each individual
component can be individually developed, tested, and eventually integrated with
other software components or functionality developed by the team over the days.
Individually developed features and functionality can eventually “give birth”
to a working product when integrated or assembled later on.
Each
individual feature or list item is known as a “Product Backlog Item” or a “user
story” in simple language. Therefore, the product backlog or the master list is
fundamentally composed of product backlog items or user stories. The user story
represents a product feature, and is individually developed by the team members
during the development process – the daily sprints. Each story can be minutely
defined. The description, acceptance criteria (Points which need to be
“fulfilled” or satisfied before which the story can be considered as
successfully developed), its importance in the project, and the manner in which
it is supposed to be integrated into the final product, etc. are mentioned for
each user story.
Once the
feature list is created, it is arranged depending upon the importance of each
user story in the product backlog. Important user stories are arranged in the
“top” portion of the list, lesser important stories in the middle, and the
least important features and functionality in the bottom portion.
4.
Sprint planning meeting – Planning how to develop the
product features
The
product backlog functions as the main “backbone” of all development related activities
in Scrum. Once it is “developed” by the product owner and the stakeholders, the
actual development activity can start. A special meeting known as a “Sprint
Planning” meeting is held to initiate the development activity. The meeting is
attended by the entire development team, in addition to the product owner “PO”
and the scrum master “SM”.
The
meeting is held in two parts. In the first part, the product owner selects some
of the most important user stories or product features from the top of the
product backlog, and transfers them to a temporary list known as a “Sprint
Backlog” for development purpose. During the meeting, the product owner takes
the opportunity to explain each user story in details to the team members – how
user stories should be ideally developed, and what activities the team should
carry out so that each story can be marked as successfully completed.
During
the second half of the meeting, the development team analyses the sprint
backlog and distributes each story to individual team members. In practise, the
team members unanimously decide as to who should take up which story depending
upon their development skills and experience levels. Simple and easily
developable items are given to less experienced or “fresher” while difficult,
or more complex stories are taken up for development by more experienced and
senior programmers or developers.
This is
the main area of activity in Scrum. The entire product is developed in “bits”
and “pieces” through the daily sprint cycles. A sprint cycle is nothing but a
collection of working or “development” days during which the team members
actually sit in front of a PC and develop the functionality or product features.
The sprint cycle is time boxed and should not extend its deadline.
Each item
included in the sprint backlog during the sprint planning meeting should be
developed while the sprint is currently underway. A brief meeting known as a
“Daily Scrum Meeting” is held for a maximum of 15 minutes each day before the
team members start with their work. The purpose of the meeting is to get an
idea regarding how much work has been completed by each member the day before,
and what each member proposes to do “today”. If a team member is facing any
issues or problems, it can be mentioned during the meeting, and the scrum
master will ensure that the issue is quickly resolved.
In Scrum,
the daily sprints can typically last from 2 weeks up to a maximum of one month.
The duration of the sprint is decided during the second stage - the project
release - and it should not be extended under any circumstances - even if any
of the user stories in the sprint backlog have not been developed, or whose
development is incomplete.
6.
Sprint review – Checking and verifying productivity
(Is the development OK?)
Scrum
emphasises upon the development of “shippable” functionality at the end of
daily sprint cycle. Each user story developed during the daily sprint is
checked by the product owner and verified for its reliability, acceptance
levels, and whether it is “bug free”. In Scrum, it is very important to deliver
error free features – each user story should be properly tested for any
regression, and whether it satisfies the acceptance criteria linked with its
development.
Just
after the daily sprint cycle ends, a meeting is immediately held to review the
development carried out by the team. It is important to differentiate between
the daily sprints and the sprint cycle. The daily sprint is the development
activity carried out by the entire team on one particular working day. Many
such “daily sprints” combine to form the “Daily Sprint Cycle”, also known as
the “product incremental cycle” in Agile. The meeting is held at the end of the
product incremental cycle – the daily sprint cycle. It is primarily attended by
the product owner, the scrum master, and the team members. It is not mandatory
for the stakeholders to attend this meeting. They can chose to attend it if
they so desire.
The main
objective of this event, or rather the meeting, is to check whether the
features have been developed by the team as per the production plan, and if the
functionality has any “manufacturing” defects. Each feature should be fully
tested for any flaws by the team before presenting it in this meeting. The product
owner verifies if the feature is error free and checks if it satisfies the
acceptance criteria linked with it. It is a kind of “final” check carried out
before presenting the development to the stakeholders and the project owners in
the subsequent sprint retrospective meeting. During the meeting, the product owner
instructs the team how it can improve its working and offer even better
productivity by employing more efficient programming practices and standards.
7.
Sprint retrospective – Finalising product
functionality and contemplating about further improvement
Agile Scrum advocates client participation. The client
is a very important entity in Scrum, and has the final say as far as the
development of product features is concerned. The Agile manifesto primarily
stresses upon client participation and delivery of time bound product
increments because these two aspects are very important for developing
successful projects. A “satisfied” client often “comes back” to develop more
projects since successful projects help the client to earn higher profit
margins.
The retrospective provides an opportunity for the
entire team to demonstrate its productivity in front of the stakeholders and
clients. In addition to the product owner, scrum master, the development team,
the meeting may also be attended by end users, technical staff personnel,
vendors, distributors, and even other employees since the main purpose of the
meeting is to avail feedback from individuals and entities closely linked with
the market, and who have sound knowledge regarding what product features are
likely to “score” in the market once the product is launched, and what can aid
the product in “selling”.
The retrospective also offers a chance for the entire
team as well as the client to reflect upon the development process, and discover
what more could be done to make the product better. Discussions are carried out
to ascertain the rate at which user stories are currently being developed by
the team, and what new processes or methods need to be introduced to quicken
the process.
