The two key initial phases of any development model before the actual development work begins, are: The Requirements gathering and Detailing. Before the Agile methodology was followed by Development teams for their projects, teams followed the older models of software development such as the Waterfall or the V model with its rigid structures, which had long and detailed requirements planning phases.

These phases were critical and yet tough to go through. The complexity was coming not just from the unclear nature of the requirements, with not clearly knowing what all is required and how it is required, but also from having to document them in a way that was clear and understood by all in the same way. These were complicated further with the changing nature of market dynamics due to the long implementation cycles, causing requirements to change further during the lifecycle.

These challenges came in many forms. Some of them are described here.

Requirements Detailing

Collaborating with the client on getting the requirements was somewhat a mind bending task. Aside from getting the high level requirements discussed, many times it was not possible for them to give specific details of what they were looking for in the product. A factor in this case was the non availability of any historical products as are available today for them to take cues from. It was difficult for them to imagine the exact way this product would function.

Putting down the requirements was a tedious process to me as a developer, as with a lot of young team members. Similarly, understanding those requirements was another challenge. It would inevitably come down to being told by the team leader on what exact feature was to be developed.

Hence, with the limited and sometimes vague requirements noted, the probability of getting a sign off on the requirements was a long process. Yet the project would be required to be completed in tight schedules, as was becoming the norm, As the sign off came in, the development team would start to work on it with the design work. The sign off did come, in most cases, in an indeterminate amount of time.

Change Requests

This confusion and non-clarity on the requirements along with the long time in this process brought with it a new set of problems, as was the case in a project that ended up having to deal with multiple high level escalations. ‘Mike’, the client was persistent in asking for a different feature, or not happy with the feature coming in because that was not exactly what he wanted. Over time, this had caused a fractious relationship with the client and an unhappy implementation team.

The hurry to get the product deployed by customers, probably, caused them to give a set of requirements that were high level and sparse, without wanting to spend too much time in analysing and detailing it. The requirements had been put together quickly to get to implementation quickly, also maybe because the requirements were probably not completely clear to the client at the start of the project.

The deliveries being made were at times not always up to Mike’s satisfaction. This inevitably led to multiple complaints causing the implementation team to having to rework leading to delays. This went on for a while and started causing escalations. These had become a regular pattern till they could bring in a dedicated manager, when I was hired.

The implementation team was frustrated, the customer’s team was annoyed and the senior management was spending more time than they would, in usual circumstances, in trying to resolve issues raised by this customer. Well, I had my task cut out here!

In my initial visits to the customer, which meant a travel to a different city, I would receive a frosty reception from them. On further study of the situation, I figured that I was confident about the team. It was also clear that there were some process changes that had to be brought in.

So, each time Mike would come back with an issue that a feature was not working as it should have been, we asked for time to analyse it. The analysis by the team was to help us understand if this was how the requirements were stated or they were different. And, if they were different, further analysis would be on the impact on time and cost to the customer for getting them implemented.

So, while still following the traditional models of software development, there were variations that had creeped in during the implementation and deliveries. Some parts of the lifecycle were still traditional, such as the requirements gathering phase, which happened upfront. So even though requirements were gathered at the beginning, due to apparent time pressures for the client, there was a need to jump into implementation. This was causing additional or modified requirements to be coming in during implementation.

This Change Request (CR) process was at first resisted by Mike. Many times these CRs would result in additional time needed and additional costs. He, of course, was not happy with the ask for more time and money for the changes to be implemented. He was insistent that these were not additional changed requirements. It meant a lot of phone calls and travel to discuss these changes and the process. There were discussions around whether these were actually originally signed off requirements and that they were not understood right by us. This would mean further discussions. There were also some times when the CR would show that the change is minimal and we had decided to let them pass as original requirements as well.

Responding to Needs

Trying to follow the old lifecycles while the need was for faster turnarounds caused the requirements gathering and detailing phases to be completed in a quick manner. This was probably done as the customer could surely not be aware of the consequences.

The CRs were frequent enough and needed frequent and good collaboration with Mike and his team. This way he started to see the value in the process and accepted them grudgingly. He even started to expect them eventually. What was coming through was that there was the responsiveness and support to the changes requested by the implementation team, and there was no insistence on sticking with the initial plans.

This changed scenario helped streamline the implementation team’s efforts and improved the overall morale of the team as well. With Mike getting onboard, the relationship seemed to take a more positive turn.

Though the implementation did not start adopting Agile methodology, the delivery was expected to be agile, that is, nimble and quick. The starting phases did not have the requisite details known upfront. This resulted in additional or modified requirements coming in during implementation and delivery phases.

The older models of implementation were not able to keep up with the changing needs of the times, due to which the Agile manifesto with these 4 values had been drafted, and were practiced during the implementation in this project case –

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Two of these Values were the clear drivers for the case here and were adapted for our applicable lifecycle to meet the customer needs. These were also being true to these Agile principles among the twelve–

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Conclusion

With the adjusted process and acceptance of changes in requirements by the implementation team, Mike was not just satisfied with the newer deliveries, but also with the changed relationship dynamics that it led to.

Our senior management had become completely hands off on the project and had even made the comment that all escalations were being held up and there was no escalations or even calls going further up the chain anymore. This was a testament to the success of the changed process, in becoming agile in handling the newer requirements coming in from the customer.

The customer requirements were all met with this new and changed methodology. There were logical reasons for the process and the analysis presented to Mike and his team could not be refuted. For this project, eventually Mike even gave us a very high positive Customer Satisfaction rating.

The use of the traditional development models were molding themselves to the Agile way to meet the needs. This mashup caused challenges initially on this project, which took significant additional efforts to fix and bring the project back on track.

Evolving Delivery processes to meet changed customer scenarios dynamically is the essence of Agile methodology, which was what our older development methodology adapted to, to meet the changing requirements.