Our old staples

Since the “Manifesto for Agile Software Development” (known more commonly as the Agile Manifesto) was brought to life, and while it was on its way to becoming ubiquitous, many were following models with fixed and rigid structures, such as the Waterfall or the Spiral model among others. The V Model was more popularly used in our teams in the 1990s and early 2000s.

Even in these times there were clear indications that these models were not able to keep up with customer needs. Today we know of Agile and that the customer can see the product and features, almost in real time, and start benefiting from the value it brings. It took multiple steps to get to the Agile model in this interim time. A perspective from a practitioner in this time would give an insight and help us understand the methodology and the reasons for the transition to Agile.

An impossible tale

‘Srini’, the Project Director, from a major SI in India wanted the project completion in one month, as that is what he had committed to his seniors. I had heard that this customer was challenging when I was asked to come in and manage. It was in the early 2000s and our organization was still following the waterfall model with Extreme programming being the new model we were being encouraged to try out. In the initial meeting with him and his team and my team from the Services team of the Multi National, he gave us a project plan for the implementation that he had come up with, and he kept bringing our discussion back to that schedule. The requirements and all other details were discussed, but the timeline was of prime importance.

In the traditional waterfall model, the project plan that we had come up with was extending to 9 months for the implementation of the enterprise knowledge management software for this customer, under a no-risk scenario with extra tight schedules and a no buffer situation. But that was too far out for Srini. He had committed and he would not budge from the date of end March, which was just 4 weeks away. Of course, what the circumstances of this timeline that he was to work on was not known to us.

During the meeting, hearing Srini focused on March end, I remember looking at the faces of our sales team and they – as only a Sales team would – had continued the discussion as if there would be no problem with the deliverables and the date promised.

Not wanting to walk away from a promising large customer deal, the fantastic timeline was not debated and my attempts to talk of a more realistic timeline seemed feeble and went nowhere. Any traditional implementation would not have worked at all as it might have cost us multiple high-level escalations and possibly the deal as well.

Adaptations

Our team jumped into the implementation, regardless of the unachievable deadlines even if pulling in all-nighters were considered. In every meeting thereafter it was the March-end deadline that was at the top of the agenda. There were daily quick updates on progress and plans that I was working on with the team.  To keep the customer happy and to show that we were as committed to the project implementation, we had regular interactions with Srini’s team. There were small deliveries made from time to time, meeting small feature requirements that helped show up as achievements.

Even with the regular review meetings, there were still times when I was at the receiving end of long, loud complaints from Srini over the phone on various aspects such as the schedule and some feature not having worked as per his expectation or him being unclear on the usage and that multi-level demos across his organization were to be made as a part of feature releases. I learnt to just focus on the essence of the call and the need of the hour.

What stood out was the emphasis on collaborating with the customer team and getting the delivery done in a way that would meet the goals of functionality and also, to some extent, the meeting of the tight deadlines.

It was clear that we had digressed from the waterfall model that we were meant to follow and were adapting to the client needs on the go. The development team was delivering on the requirements impressively and with agility.

While we were tweaking the implementation model, the common goal among the extended team was to have a lighter process, be more flexible and have a planning that was just enough and maybe also plan on the go. This was about not being tied down to the plan made at the start of the project and probably not even spend time on a heavy upfront plan.

Values and Principles

Though the implementation was not Agile as we may know of it today, these approaches are signs that we were adjusting to the need of the hour to focus on quicker deliveries for meeting the clients’ requirements.

Its positive impact on the development would confirm that the key values of the Agile manifesto were important to the world then as now. These values were being followed as was felt, without actually knowing them as –

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over negotiations
4. Swiftly responding to change over following a set plan

Three of these are directly obvious in the implementation example here.

The Agile manifesto also brought out 12 principles to back these values. Those principles included the ones relevant to the experience we had all those years ago without precisely following the manifesto:

• Satisfying customers through early and continuous delivery of software
• Delivering software frequently through shorter development timelines
• Using working software as the primary measure of progress

These values and principles guided our development and delivery of the project to a satisfied customer, as they continue to guide the development universe today as well.

So as March turned to May and June and July the long calls became infrequent and to a point that I missed them. Srini seemed to have been impressed enough with the deliveries and demos made and they also appeared to have satisfied his senior management sufficiently, so that the mention of the March end overall deadline was losing its significance and was not brought up after some time. The long complaints were brought down and withered away. It was a combination of quick deliveries, confidence building, and patient hearings that did the trick!

The implementation went smoother in later months.

Paradigm Shift

The change in the development model involved changing the overall thinking for the development community. It involved a paradigm shift, which was not always and not easily accepted by the management, as was also the case with me. The concerns included: Will the different parts would fit in together; Will the smaller parts would add up to the sum; etc. For the customers too, who might have been used to the models as adapted from other industries, the change caused anxious moments on whether all the features would come in and if the overall timelines for implementation would be met in their strategy.

The fallout from this experience for us, as must have been with the software development industry, were brought out in the following myriad ways.

In spite of apprehensions, seeing the benefits would have then hastened the adoption of newer and more nimble models. The shaking out of rigid mindsets and models was coming at us and carrying us with the wave. It was – adapt or get left behind.

The client could also see the impact on their implementation and their strategy. Later in the year when I was starting my vacation during the Dussehra break and was sitting at the airport waiting for my flight, a call from Srini sweetened my trip. This time it was not the difficult call that I had come to expect – It happened to be a short and sweet call letting me know that the implementation was complete and successful and that it went well. They must have met their strategic goals as well, for him to reach out and let me know.

A happy customer leads to a happy organization. The project happened to be a significant implementation of a major product for my company. It was a success on many fronts from sale to implementation to customer feedback. When the year-end awards rolled around, my team was awarded a Performance Award to celebrate the many successes as well. It was a recognition for the efforts and the impact on the organization that helped in making this shift.

Closing

Overall, this and other similar projects guided the Development community towards Agile. The realities of: Challenges in the need for upfront end-to-end design and planning; Moving to the next Project stage only on completion of the previous stage; and the Customer seeing the product only after all the steps in the process were accomplished; were drivers in the migration to Agile.

This evolution was gradual and even organic, moving away from the earlier rigid and longer models, with newer values and principles leading us to the Agile way.

As can be seen from this practitioners tale, the need for quicker turnarounds set the tone and was one of the steps to the changing processes from the old development models to the newer Agile model.