Process

QBurst uses agile development methodologies to improve quality while reducing cost and time-to-market.

Why Agile?

• Traditionally, software applications are developed using waterfall methodology. A large percentage of big corporations still continue to follow the waterfall model. As of 2008, surveys show that agile penetration in large enterprise is less than 25%, but growing fast as more and more enterprises understand its benefits. A majority of ISVs and startups already use agile methodologies.

Agile is gaining momentum because of several factors:

• Businesses operate in a fast changing environment, where they have to respond to market changes quickly by introducing new products or changing existing ones. Typical projects are now 3 months or less and not years as it used to be.
• New technologies are coming to market every other day, so if a product takes years to build, it sure will get outdated before it launches.
• The web-based model allows companies to launch a bare bones version of the product first, get feedback from end-users and then incrementally add new features based on that feed back.

What is Agile Development?

In the waterfall method, a software development project goes through multiple sequential phases starting with requirements analysis, high-level and low-level design, coding, system and acceptance testing and finally deployment. Requirements are typically frozen after requirements analysis. Any change in requirements after the freeze will typically add to the cost of the project. The cost of making a change progressively increases as the development moves further downstream. In order to avoid this, end-users are asked to state all the features they need upfront resulting in bloated requirements. It does not matter even if those features are rarely, if not ever used.

Agile methodologies take an iterative approach and does not require a requirements freeze upfront. Work is carried out in iterations, which typically last one to six weeks. All of the features required for the project are put in a wish-list. Then depending on business priority, these features are assigned to releases which are tied to iterations.

The Scrum Process

Scrum is the default process we use. A custom-made process for a client is usually a variant of Scrum.

Scrum, though often written using upper case letters, is not an acronym. It derives its meaning from a play in Rugby in which the two sets of forwards mass together around the ball and, with their heads down, struggle to gain possession of the ball. Scrum could be used in any project, but is mostly applied in software product development.

The requirements for the product are collected into what is called the product backlog, which is a prioritized wishlist of features. Features may be described using user stories. The Product Owner maintains the product backlog. The Product Owner is a Scrum role that represents the interests of the customer. It could be the customer or a business analyst representing the customer. The product backlog is never frozen, users can suggest new requirements and the Product Owner can add them to the backlog and prioritize it.

The product is developed iteratively in multiple sprints. A sprint is a time-boxed iteration, which usually lasts 30 days. The duration of a sprint can be fixed based on the nature of the project. Typically a release follows a sprint, though a release can be made after multiple sprints. Each sprint will implement a set of features. A sprint backlog is created prior to the beginning of a sprint during the sprint planning meeting. The sprint backlog contains all the tasks that need to be done to imple- ment the features included in that sprint. Once a sprint starts, the scope of the sprint cannot be changed by adding new features. This allows the developers to complete a sprint without external interference. The Scrum Master is responsible for making sure that the process is followed. Typically, this is the Project Manager.

Remote Development and Agile

Most agile methodologies, especially XP, stress the importance of face-to-face meetings between users and developers and also co-locating developers. Having everyone in the same room is always good and paves the way for highly efficient development. But the reality is that development almost always happens in a distributed fashion. All the skills required for executing a project are often not available in the same geographical location.

The current reality is that development happens in multiple locations located in different timezones and with team members from different cultural backgrounds. Is it possible to go agile with such teams? The proof that distributed teams can create great products is discernible from the success of open source projects. Most open source products are created by community developers who work from home and barely see each other.

Modern web-based project management and collaboration tools allow developers and users to work from different locations. Most of these tools are free. Instant messaging, Skype video calls, desktop sharing tools, task tracking appplications like Trac, wiki, version control systems like Subversion and GIT and web-based build and deployment tools like CruiseControl allow seamless communication and collaboration. In recent years, these tools have helped drastically improve the efficiency of remote development. Having overlap time for teams working in different timezones is important too.