Monday 20 October 2014

Why Agile Can Be A Popular Software Development Framework

Agile A Popular Software Development Framework

Software products penetrate almost every aspect of human existence today. They manifest themselves in a multitude of manner, and remain omnipresent in a host of devices ranging from washing machines and smartphones to automobiles and computers. Owing to a consistent usage of different types of digital devices by people across the world, software applications and utilities have to evolve as and when consumer requirements change and “strive” to fulfill the new set of requirements demanded by end users. It is, therefore, essential to develop newer versions of existing software products more frequently, in the shortest time possible, and in a manner such that end users do not face any problems while using the products in the upcoming months. Stiff market competitions and an ever-increasing consumer “appetite” for feature-rich products have created a special need to implement a reliable and sustainable product development methodology, or a framework, which can aid in developing sophisticated software products in a relatively short time. Moreover, the methodology should also help in reducing the developmental overheads so investment returns can be increased. As on today, a reliable project development methodology is very much required to fulfill the business goals on a consistent basis, and earn large profits from the products manufactured by IT companies.

Over the decades, IT stalwarts have introduced many software development frameworks and project management methodologies. While many of these methodologies have proved to be useless and non-productive, a large number of them have been, in fact, successful in delivering the desired results – with varying levels of acceptance. With the passage of time, two software development frameworks have managed to dominate the field of software development. The frameworks are:

1. Waterfall

It is a traditional software development framework typically featuring “staged” development processes which have to be “carried out” one after the other. A unique aspect about this framework is that product development starts from the “topmost” stage and “flows” towards the “bottommost” stage. Once started, the product development cycle cannot reverse itself – it is unidirectional in nature. The framework is widely used, and is very popular amongst software development companies, primarily because the framework has “been around” for a long time and used by a large number of software developers and IT firms. It is easy to understand and use. Therefore, it is also used for teaching the software development process to engineering students. Even though it is a much sought after development framework, a large number of individuals and companies traditionally using Waterfall methods for developing their software products are now finding it increasingly difficult to meet the changing global software trends, and developing state-of-the-art applications and utilities, which are so much in vogue today.

2. Agile

A comparatively new “entrant” Agile has managed to find a special niche for itself in the IT development field over the years. The Agile framework was originally envisioned, and developed, to overcome the defects of traditional software project management methodologies and frameworks, which had failed to evolve “in the desired direction”, could not adapt themselves to the changing market trends, and offer reduced turnaround times. There are many reasons why “lightweight” Agile frameworks have become popular development platforms:
  • They support product development through “short bursts” of programming/development activity, generally lasting from two weeks up to one month. It is much easier to develop, test, and document smaller “pieces” of code, features, and functionality rather than entire projects. Individually developed features are later integrated to form the “complete” product. The frameworks primarily focus upon rapid delivery of “shippable” products and business value.
  • The client is actively involved with the team and the development process. Each feature is checked and “cleared” by the stakeholders before it is accepted as “Done”. This leads to increased customer satisfaction and enhanced user experience.
  • Potential pitfalls are identified well in advance, at a micro level, so it is much easier to control regression and reduce technical debt. Agile software projects generally help to earn good profit margins.
  • Agile frameworks support error detection and error correction processes. Technical errors are discovered early during the product development process, and dealt with effectively.
  • The frameworks provides an opportunity to carry out “retrospective” thinking, reflect in terms of where the project is heading, and what “more” could be done to improve the product development process.

Agile and the scope of software development

Individuals associated with the software industry generally prefer using the term “software development” to describe their particular line of work. The words are indiscriminately used to describe a host of development related activities, including testing, documentation, debugging, deployment, and maintenance of software applications. It is normal to explain one’s profession as “software development” while the individual may be working as a VBScript or Java web developer, an application programmer, an iOS or Android mobile apps creator, or even developing specialized scripts for WordPress themes.

One of the commonest doubt prevailing amongst most individuals new to the Agile process is whether Agile is “applicable” to their particular field of work. And if so, how? In what manner? How can they possibly benefit through Agile? The questions are many. First of all, it is important to know where Agile is applicable, and whether it “covers” your particular field of work. Please read to know more about Agile “applicability”. The list provides a rough idea regarding the scope of Agile software development.

1. Clients and stakeholders engagement

Scrum
Agile emphasizes upon client engagement. The stakeholders “own” the project and sponsor it. Their objective is to develop successful software projects, and generate higher sources of revenue out of them. In practice, the client remains conversant with the current market trends, and possesses a fair idea as to “what” is likely to score in the market in terms of a feature rich application or utility that can satisfy the end user requirements. When the client is closely associated with the day-to-day development activity, he or she can decide whether the productivity offered by the development team can satisfy user related requirements, and how much of business value the product features possess. Client participation leads to meaningful and successful project development and completion.

Waterfall does not encourage or support client participation. The project is developed, and subsequently presented to the client after it is totally completed. Since the client does not participate in the development process, Waterfall projects may fail to offer the exact features so desired, and, in addition, do not “guarantee” any business value for the project. There is a certain risk involved regarding the product’s saleability. 

2. Transparency and collaboration

scrum tool
The Agile framework makes it possible to increase the transparency levels while working, and facilitates the actual product development process by increasing the collaboration amongst team members. Information pertaining to the entire project is shared equally with all team members, and each decision undertaken by the senior team members – the product owner and the scrum master – is freely discussed. The seniors “act” as mentors, and many a times employ a servant-leader role to increase team participation. The team members have the authority to accept or reject the tasks taken up for development. Moreover, the developers have the right to allocate or distribute development tasks amongst themselves. Seniors do not allocate work to the development team members. All these factors create a healthy working environment. A conductive Agile work-related atmosphere leads to meaningful development and timely completion of product features.

The Waterfall framework primarily concentrates upon delegation of authority and direct allocation of work. Unlike Agile, the development process is pre-decided, and in many cases, even decided as to which resource should be used for developing a particular product feature. Waterfall is rigid as far as sharing of information is concerned. The project related documentation is created at the project’s onset, and apart from technical information, nothing else is generally shared with the team. The seniors have the final “say” and junior team members cannot argue with any of the decisions undertaken by the seniors.

3. Quick and predictable delivery

free scrum tool
Apart from the actual development activity, Agile supports several events and activities which constitute the actual Agile process. Each activity is time-boxed and has to be completed within a stipulated time. It is one of the most important framework features. Quick and sustained delivery of shippable products through periodic product incremental cycles known as “sprints” comprise the main heart of all Agile frameworks. The deadlines are stringently adhered to and rarely compromised upon.

One of the biggest drawbacks of Waterfall is that projects, in many instances, extend well beyond their stipulated deadlines, and rarely get completed in time. It is an inherent drawback which actually inspired the “birth” of Agile and Lean frameworks. Traditional development methods are rigid, and it is very difficult to control the rate at which productivity is offered by the team. That is not the case with Agile. Each Agile sprint is dynamic, and “monitored” on a daily basis through the daily scrum meetings so it can be “made” effective. Agile concentrates upon quick and timely delivery of product features and functionality through daily development activity known as “daily sprints”.

4. Predictable costs and work schedule

online scrum tool
It becomes possible to predict the amount of work done, or productivity offered, by time boxing the daily sprint iterations. The development carried out can be frequently and easily monitored since each “daily sprint” has to result into something “significant” with regards the development of product features, and the same has to be exhibited to the product owner and the stakeholders in special Agile events known as the “sprint review” and “sprint retrospective” meetings. The “velocity”, or the rate at which actual development is carried out, is used for estimation purposes i.e. the total number of tasks developed by the team during a particular sprint provides an idea about how much work was carried within a specified time. The estimation makes it possible to predict how much time and financial resources will be required to complete the project. A reliable project release date can be subsequently stated.

It is very difficult to estimate how much time a Waterfall project will need to complete. Deadlines are generally “set up” based upon predictions and project related experience, rather than on actual project dynamics and production pattern. It is one of the primary reasons why Waterfall fails to deliver time bound projects.

5. Support for “change”

scrum planning tool
Agile is based upon “inspect” and “adapt” principles. The Agile framework dynamically supports changes, and is capable of adapting itself to changing market related conditions and client demands – even late during the development process. New features can be introduced to enhance the product’s business value, and redundant functionality can be safely “removed” from the production plan without affecting the productivity levels.

Waterfall does not support, nor advocate, any types of changes once the documentation process is carried out, and the project commences. The framework is rigid and there is no scope of changing the functionality stated in the documentation process – even if the client so demands.

6. Focusing upon the business value

project management tool
In Agile, development is carried out by splitting the actual product into smaller developable parts known as “user stories” or product items. Right from the project conception stage, each user story is segregated and arranged depending upon its importance and business value. User stories having a greater business value or importance in the project are developed first, followed by less important ones. Thus during the Agile process, only important product features are developed at all times, thereby increasing the business value linked with the project currently underway.

Waterfall does not have features that can account for or take into consideration the current business value linked with the project. The concept does not exist. Projects are developed in a traditional manner, and no efforts are made to determine what they are currently worth in the market.

Subscribe to the permanent free version of the Quickscrum project management scrum tool to get an idea about how the tool works and what it has to offer.

Sunday 12 October 2014

Main Differences Between Agile Scrum And XP Framework

Of all Agile frameworks, scrum is the most popular one. Scrum framework is highly recommended for developing IT projects and it is so widely recommended for it that it is often confused with Extreme Programming or “XP” Agile framework, which is synonymous with software development. Both the frameworks are much similar, and to a person not conversant with Agile, both might appear to be the same at a first glance. While most Agile processes and events remain the same, there are some subtle differences between the two frameworks.

Sprint durations

Typically, in scrum, the sprint iteration can last from two weeks up to one month. In XP, the duration is much shorter, and generally lasts from one to two weeks. The sprint duration does not exceed two weeks in XP.  

Committing the sprint backlog

One of the major differences, and an important one too, is how user stories are committed in the sprint backlog while implementing scrum and XP. In scrum, the sprint backlog is “owned” by the development team. Once the team accepts the sprint backlog, all the user stories in the backlog are “committed” for development purposes. The team is required to complete all the user stories stated in the backlog. Moreover, once committed, the sprint backlog cannot be “changed” while implementing scrum. If any new user story is required to be developed, it can only be included in the next sprint after a new sprint planning meeting is conducted. This is not the case with XP. The sprint backlog does not become “static” even after it is accepted by the team and the user stories are taken up for development. If required, based upon the feedback received from the stakeholders, a user story taken up for development can be replaced with another one having the same estimation in terms of story points. Therefore, the sprint backlog is not “committed” at any time in XP. New stories can be replaced in lieu of those currently existing in the sprint backlog – something that is impossible in scrum. However, it is important to know that such a “replacement” of user story is only possible in XP before the particular user story is taken up for execution in the daily sprint. Once the development of a user story starts in XP, it cannot be replaced.     

Determining the sequence while developing user stories

The role of the product owner remains common in both scrum and XP. The PO prioritizes the product backlog in accordance to the importance of user stories based upon the business values.  Feedback is availed from the stakeholders as to which of the user stories are more important and pertinent from the development point of view, and the PO categorizes the product backlog based upon the business values of the user stories. The similarity, however, ends there. In scrum once the user stories are prioritized and taken up for development during the daily sprints, the development team enjoys the autonomy of deciding how the user stories should be actually taken up for development during the daily sprints. The team can decide the order, or the sequence, in which it desires to develop the user stories. This does not occur in XP framework. The development team in XP has to strictly adhere to the priority of the user stories as decided by the PO and carry out the development in the same order of priority. In XP, the team cannot choose the order in which the user stories should be developed. It is decided beforehand by the PO or the client. The team is required to stringently follow the priority as stated in the sprint backlog.     

In scrum framework, it is highly common for the team to start with the second-most-important user stories rather than the most important ones during the daily sprints. Larger user stories or “epics” are generally developed subsequently since they consume more development time. This is generally done to maintain the velocity during the scrum process, which is depicted in the burn down charts. It is important for the team to remain close to the “ideal” line so that the velocity is maintained at all times. Taking up easier user stories generally helps the team to remain consistent with the projected velocity. This is not possible to do in XP.
 
Subscribe to the permanent free version of the Quickscrum project management scrum tool to get an idea about how the tool works and what it has to offer.