Development gap

The problem of business users continually changing specifications during a software development project can be overcome by adopting an Agile development methodology.

  • E-Mail
By  Roman Konovalov Published  April 20, 2006

|~|roman_pix200.gif|~|Roman Konovalov, managing director of Aroma Software. |~|Business users and software developer teams - whether they are internal or third party companies - often end up at loggerheads at the end of a development project. On the one side, business and IT managers are not always satisfied with the software they end up with and complain that the developer does not understand the business need.

On the other, software providers argue the customer does not know what he wants and all the changes that have to be accommodated during the development phase are the reason for any failure.

But the customer - and this applies to the internal customer as well - is always right. So, software developers need to work on ways of bridging this gap between expectations and delivery, by working on the premise that customer requirements will change - and often - during a project.

There are two different methodologies software developers can use in their projects: the traditional ‘waterfall’ method and Agile development.

Traditional approach
The traditional ‘waterfall’ method of software development comprises three steps:

Step 1: Software company works closely with the cust omer to understand the company's needs and the problems the proposed IT solution is to address. Usually, the output of this work is a document that contains all the requirements for the system.

Step 2: The development phase: the system is implemented, tested and documented.

Step 3: The system is delivered to the customer, and staff trained. Customer starts using the system.

The development phase, might take months or sometimes years, depending on system scope and complexity. The classic problem that arises is that business will inevitably change during that development period. This is normal. Competition these days dictates companies react quickly to new market conditions and business opportunities, forcing them to adjust their business processes and rules.

Another problem is that a solution initially designed to deliver benefits applicable to the business environment say 12 to 18 months ago, often does not have any chance of doing so at the time of project completion utilising the traditional approach. Such an approach might have worked 20 years ago when most business models remained fairly static, but not in today's dynamic world.

The fact is, business people often have difficulty defining exactly what they need before they see a working system. They might think that they need one set of features, but later, after the development is completed, discover other features are more appropriate, by which time, it is too late.

On the other hand, having end users calling up a developer a couple times a week to ask for changes or additions, also does not work. As someone who has been working in the software industry for about 10 years, I can say that the last thing software developers like is a change in system requirements before the system is completed.

The latest project with which I was involved entailed working on with over 1,500 people from around the world. The major problem faced was the constant change of requirements. New features suddenly popped up in the requirement list, resulting in a lot of changes during the development process. With this permanent state of change, the development team became very unhappy and frustrated. Instead of focusing on the task in hand, they had to accommodate all the changes. These often entailed re-working previously completed work and the end-point was pushed out further and further.

Introduction to Agile with Scrum
As an alternative to the traditional ‘waterfall’ development life cycle, there are other approaches and methodologies to help software companies address the requirements change issues. A methodology getting more and more popular is called "Agile Software Development with Scrum". The idea behind it is very simple - every 30 days the development team make a new version of the system and demonstrates it to the customer.

The Agile development cycle steps comprise:

Step 1: As in the traditional approach, the developer sits down with the customer to work out the list of requirements for the entire system. The development starts with the customer's vision on how the system should look.

Step 2: The 30-day iteration begins. On the first day the developer has a meeting with the customer and the development team members to decide what requirements from the list of features will be implemented during the next 30 days.

Later, at the last day of the iteration, you invite your customer for the demonstration of the system you've worked on during the past 30 days.

Step 3: The customer makes a decision as to whether they want the system delivered, wait until the next version, or add or change anything in the current list of requirements.

The main point here is that every 30 days the developer is able to demonstrate to the customer the system that contains fully implemented features that both parties agreed on 30 days ago. This means that these features need to be developed, tested, and documented properly. Basically, every 30 days the system must be ready to be deployed at the customer's site.

After the demonstration, there are several possible scenarios. Option one is that the user might want to redirect the project as their business changes - new requirements might be added or the existing ones might be changed or even cut. After seeing what has been done so far, the company might also get new ideas about what the IT solution needs to include to help the business. Alternatively, they might realise some features are useless and don't need to be implemented in future versions. The demonstration of working software is the great motivator of new ideas about required functionality.

In option two, the company might want to have earlier delivery of the system; it might want to start using the system as soon as possible. If the system can help them today, why not start getting benefits right from now? The earlier the system is used, the quicker the return on investment (ROI).

Option three could see the user terminate the project because the company has all it needs. This saves time and money as the business gets only the features from which it really derives value. In this scenario, the developer avoids additional work and maintenance, and is also in a position to use resources for other projects sooner.

And finally, option four might see the company make a decision to cancel the project because it is not feasible for some reasons - either the technology is wrong, the business situation has changed or something else did not work well.

Benefits
Agile with Scrum helps to deliver the system that implements only those features the customer needs. It helps developers manage all the changes to the requirements as well as react faster to any changes in its customer's business. Since developer and business work together closely, the developer is aware of all these changes - either on the demonstration session or on the first day of the next iteration, and will be able to adjust the requirements list for the next 30 days. It helps to keep customers satisfied as they control the project.

During the demonstration session the customer might come to other features that the system might have. Before, seeing how the real system works would be difficult because in many cases customers have only a rough understanding of how the system would look. The company has a right to change its mind during the system development. The customer is the one who invests into IT solutions and they need to get the benefits from it - the right system in the right time.

Since the customer is involved in the planning of the next version, they have a clear picture on what will be done within the next 30 days. Thus the risk of misunderstanding and possible dissatisfaction is much lower.

Working this way the developer gets a commitment from its team members that the work selected on the first day's meeting will be completed within the next 30 days. So, the work is equally distributed over 30-day periods rather than to be done right before an extended project.

The requirements for the next version are selected by having a dialogue between the user and the team. The project's success depends on the fact that the developer's team believes in the defined goals. Developers will be much less stressed as they are working to a defined stage end-point rather than racking their brains over how to implement the changes they just got from the customer over the phone.

The developer is also able to improve the quality of its product. Remember that every 30 days you need to demonstrate the next version of your system and it has to be ready for delivery to the end user site.

The version demonstrated has had to pass through all the development steps - testing is completed, help files ready, and documentation written. In the traditional software development approach, the testing and documentation are often left for the last phase of the development. As a result of time pressure and constant requirements change there is often no time left to test the software properly, which typically results in quality problems and bug fixing.

If the whole cycle is run within 30 days, the developer has a much better chance to deliver quality. As the requirements implemented within 30 days are just a small portion of entire system requirements, it is easier to plan development, testing and documentation than it would be for the whole project. As the result, development processes are better managed resulting in better quality and increased customer satisfaction. ||**|||~||~||~|The main point here is that every 30 days the developer is able to demonstrate to the customer the system that contains fully implemented features that both parties agreed on 30 days ago. This means that these features need to be developed, tested, and documented properly. Basically, every 30 days the system must be ready to be deployed at the customer's site.

After the demonstration, there are several possible scenarios. Option one is that the user might want to redirect the project as their business changes - new requirements might be added or the existing ones might be changed or even cut. After seeing what has been done so far, the company might also get new ideas about what the IT solution needs to include to help the business. Alternatively, they might realise some features are useless and don't need to be implemented in future versions. The demonstration of working software is the great motivator of new ideas about required functionality.

In option two, the company might want to have earlier delivery of the system; it might want to start using the system as soon as possible. If the system can help them today, why not start getting benefits right from now? The earlier the system is used, the quicker the return on investment (ROI).

Option three could see the user terminate the project because the company has all it needs. This saves time and money as the business gets only the features from which it really derives value. In this scenario, the developer avoids additional work and maintenance, and is also in a position to use resources for other projects sooner.

And finally, option four might see the company make a decision to cancel the project because it is not feasible for some reasons - either the technology is wrong, the business situation has changed or something else did not work well.

Benefits
Agile with Scrum helps to deliver the system that implements only those features the customer needs. It helps developers manage all the changes to the requirements as well as react faster to any changes in its customer's business. Since developer and business work together closely, the developer is aware of all these changes - either on the demonstration session or on the first day of the next iteration, and will be able to adjust the requirements list for the next 30 days. It helps to keep customers satisfied as they control the project.

During the demonstration session the customer might come to other features that the system might have. Before, seeing how the real system works would be difficult because in many cases customers have only a rough understanding of how the system would look. The company has a right to change its mind during the system development. The customer is the one who invests into IT solutions and they need to get the benefits from it - the right system in the right time.

Since the customer is involved in the planning of the next version, they have a clear picture on what will be done within the next 30 days. Thus the risk of misunderstanding and possible dissatisfaction is much lower.

Working this way the developer gets a commitment from its team members that the work selected on the first day's meeting will be completed within the next 30 days. So, the work is equally distributed over 30-day periods rather than to be done right before an extended project.

The requirements for the next version are selected by having a dialogue between the user and the team. The project's success depends on the fact that the developer's team believes in the defined goals. Developers will be much less stressed as they are working to a defined stage end-point rather than racking their brains over how to implement the changes they just got from the customer over the phone.

The developer is also able to improve the quality of its product. Remember that every 30 days you need to demonstrate the next version of your system and it has to be ready for delivery to the end user site.

The version demonstrated has had to pass through all the development steps - testing is completed, help files ready, and documentation written. In the traditional software development approach, the testing and documentation are often left for the last phase of the development. As a result of time pressure and constant requirements change there is often no time left to test the software properly, which typically results in quality problems and bug fixing.

If the whole cycle is run within 30 days, the developer has a much better chance to deliver quality. As the requirements implemented within 30 days are just a small portion of entire system requirements, it is easier to plan development, testing and documentation than it would be for the whole project. As the result, development processes are better managed resulting in better quality and increased customer satisfaction. ||**||

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code