During the last 20 years GSoft has been delivering Broadcast Resource Planning software through our GMedia product suite. Being market leader in the countries where we are present, our competitive advantage lays in great part in the ability to work closely with our customers, ensuring their requirements are met in our products.

Despite the unquestionable value of deeply integrating customer requirements, such approach conditions the development and evolution of a software product, raising challenges in our development processes.

During the last year we started a structural change process in our company for enabling more efficient responses to change, which focus on 3 different levels:

1. Preparing our development process to become more agile and lightweighted;
2. Creating a core development platform for developing highly extensible applications;
3. Applying the previous processes and tools to GMedia product suite, delivering a new generation of products designed to accommodate change, technologically updated and following architectural and business trends.

In this post I will address the changes we have made in our development process and how we believe they will help us to deliver higher quality products, focused on customer needs and business processes.

Successful delivery is about solving real world problems and meeting customer expectations

Agile methodologies, such as XP, Scrum, Crystal, FDD and a few others, have been around for a while becoming more widely spread earlier on the decade with the forthcoming of Agile Manifesto.

These agile approaches for developing software acknowledge some degree of unpredictability inherent to software development processes which are less (or differently) valued in a more prescriptive or waterfall approaches.

One of the greater factors of unpredictability is change. Change happens while a system is being analyzed, designed and implemented, or while it is running on a live environment. It may happen because the business evolves and the customer awareness increases, or because know-how is introduced in a form of experience or consulting services.

Although arguments favoring a more intensive analysis stage will reduce change (which I personally agree), it also seems that change is inevitable and actually can produce value, by delivering more focused and optimized solutions. This value seems to be more significant in a context where business processes are also being optimized.

Such deeper integration of change in the processes is one of the major characteristics of the agile development approaches we value at GSoft. It makes course-correcting a plan cheaper when compared with waterfall approaches.

This characteristic takes a form of Iterative Development and Incremental Delivery on agile processes.

The principle supporting Iterative Development is quite simple: the cost and risk associated with a project are directly related with its dimension and complexity.

Breaking a project implementation into smaller parts, - iterations (or sprints, using a Scrum terminology), reduces the risk and improves predictability by introducing more inspection points for course-correcting and responding to changes.

Delivering such parts sooner and incrementally, represents value being delivered faster to our customers and shorter feedback loops, allowing us to adapt sooner and easier. Also, such feedback tends to be more realistic thus it descends from a live system being used by end-users.

Change doesn’t come for free.

Dealing with change introduces risks that may materialize into problems or costs. They may appear in a form of a change request, a bug, a design or architecture issue, or some other unforeseen issue.

The cost of problems in software development tends to increase over time. A design problem is cheaper when detected at design stage, than when caught on an implementation stage. A bug is cheaper if found a few hours after is being introduced, than a few days later, or worst: after a release is shipped.

Following this principle, that problems are usually cheaper if they are addressed sooner, is the motivation for agile software development approaches value continuously integrating every piece of functionality in an automated manner.

Continuous Integration, ensures integration problems are detected as soon as possible, by performing a set of automated tasks and verifications signaling problems and broken functionality. This process allows us to guarantee a stronger control and quality enforcing over our product code-base and consequently enables incremental delivery.

On GSoft, the adoption of Agile principles felt natural. Embracing change in the development process and responding to customer requirements with incremental delivery allow us to reduce maintenance costs, find problems faster and easily, and deliver more focused software.

Abel Pereira