Agile Development

It has been a while since I wrote my last article. I am going to a transition period and trying to identify which will be the new area I will tackle.

Since I’ve always had my weakness on studying development processes I’ve decided to pause the technical articles and talk a little bit about Agile development.

On this particular article I will talk about why more and more companies are adopting some form of agile process.

Causes of Software failures

In most of unsuccessful projects the following factors are identified as causes:

Frequently and Rapidly Changing Customer Requirements

The problem with conventional software development such as waterfall is the assumption that customer requirements are static and can be defined by a predetermined system. It is interest that although throughout the years we slipped the schedule or had to make inhuman efforts to deliver the software on time we never stopped and realized that something was wrong with the process. That requirements were changing and we put out foot down and said you can’t change this because it is not in the functional specification.

Requirements change, and change frequently throughout the life of most systems, they cannot be adequately fulfilled by a rigid design. "Do It Right" has also been misinterpreted as "don't allow changes”. If the changes are not allowed customers are not satisfied. If the changes are allowed the company will have problems in delivering the software in compliance with the project base line.

Supreme control on one hands

At large the software development companies still follow the central control model where decisions “need” to come top down. This method actually increases the lead-time and makes the whole process rigid and slow.

Agile process favors a more democratic decision chain where the “soldiers/team” in the field are the ones responsible and accountable for the decision.

Rigid Project Scope Management

Holding the project scope to exactly what was envisioned at the beginning of a project offers little value to the user whose world is changing. In fact, it imparts anxiety and paralyzes decision-making, ensuring only that the final system will be partially outdated by the time it's delivered.

The way to build software today should be prepared for changes and allow the user to do so at any time. Of course changes in the requirement may incur changes in schedule or delivery order but nonetheless the goal is to deliver a final product molded accordingly to customer asks.

Traditional methods favors linear development

Most of the quality issues in the software components are also because of the linearity in the development process that does not allow the iterations and quality checks to occur before the components move to the next stage in the development cycle. So the development progresses even there are some quality issues ' Bugs'.

Conclusion

This article presented the common problems found in the most traditional development processes. Traditional development has always been rigid, not promoting requirements changes, democratic decision making and not engaging QA sooner in the process.

Next articles I will engage on talking about some of agile development that I was exposed: scrum, lean, eXtreme Programming. The goal is to present personal experiences in such methods exposing the good and the ugly hopefully open up the article for discussions.