A dissatisfied customer, an off-the-track development, a deadline delay caused by some communication error – who wouldn’t have nightmares about such things? One decade and a half ago the signatories of Agile Manifesto have laid the foundations of a new software development approach. The method works great, in our experiences too.
Let’s imagine a huge, complex project. The development team has been working for a year and a half, they have stuck to the contract word for word. The software has been delivered, the deadline was kept, and they are certain they have acted exactly in accordance with the customer’s requests.
Except the anticipated ovation is missing. The registration interface is unsuccessful as identification is QR code-based but the client didn’t specify this in the contract and wants a bar code instead. The signatories on the client’s behalf have never dreamt that any other solution could possibly exist. The project was completed by the target deadline, but both sides were disappointed. A lot of effort has been put into the project but the expected results have not been achieved.
Is this story familiar? Most of the experts working in the software development world have already had some sort of similar experience.
The recurring problem is the use of the Waterfall model.
Described in a paper by Winston W. Royce as a project that continues thought a linear series of events each completed in a strict order with precise deadlines and budget, requiring teams of permanent members and minimal interaction between the client and the IT team during development. Briefly and subtly, these are the characteristics of the Waterfall model.
And even though Royce saw clearly and pointed out the deficiencies of the method in the seventies, the software industry just ignored these warnings and limitations. Lengthy preparation and extensive documentation made us falsely feel that everything was well-prepared. We were well aware of everything, we could see exactly what tasks had to be performed. But the truth was, we were just admiring a mirage.
Of course, there are some industries where it is not possible to work with alternative ways of thinking or project management methods. Public companies, public procurement and the banking sector are typically like that. No excuses can be given, what and when the developers deliver must be precisely clarified not to mention the cost, too. Due to hierarchical organisation structures and the regulation of tenders all of those involved have their hands tied, and this is not only true nationally.
However, in business life, in product development and in more “horizontal” and decentralised organisations there are only a few types of projects that justify the use of the Waterfall model while another option might exist.
And indeed, it does exist.
In 1986, two Japanese organisational research specialists proposed a number of innovations to overcome the disadvantages of the model: they called for self-organising, flexible teams and stressed the importance of continuous learning within organisations.
Then, by the second half of the 90s, these proposals were already being successfully used in practice by several software development pioneers, such as by the creator of Extreme Programming, Kent Beck. It was then that Jeff Sutherland and Ken Schwaber began to systematise the already introduced practical elements – from which Scrum as we know it was born. They believed that you should respond flexibly to customer needs. They then later collaborated with 15 other software development gurus in 2001 to create the Agile Manifesto.
It is extremely rare that there are no historical-political reasons behind such an action, only professional and business motives.
Like an oasis in the desert, the Agile Manifesto is an exception to this rule.
Its most important that recommendations and concerns are acknowledged and close co-operation with the customer, effective communication and openness to change are encouraged. The agile methodology is based on handling software development issues, so its key element is flexibility. Development is divided into iterations built upon one another, and each iteration is preceded, accompanied and followed by reconciliation with the client. With this method a thorough discussion takes place during laying out the basics, but there are opportunities to change, modify and fine-tune the plan on the move during each 1-3-week phase. It is not uncommon that the client itself asks to change their original concept. Another important element is the retrospective of development iterations – an overview of the process which helps to realise what should be improved or done differently next time to make the process more effective or digestible for the parties involved.
There were several companies that soon recognised the power of agility, plenty of others have gradually shifted to the model in recent years. There are some, of course, to whom this approach still remains alien.
There are typically two reasons behind this aversion. Firstly, some find it difficult to handle the fact that you can not tie a strictly fixed deadline and resource requirement to a project. Secondly, it could be discouraging to realise that continuous consultations require resources from the customer too.
In other words, the client has to deal with the current IT project from time to time to approve it, or if necessary, change its course. This requires attention and energy. In addition, not only does the development have to be agile, but involves other organisations too, which means a flexible company, quick decision making and effective communication. Again, these are not attributes that everyone has.
By contrast, there is another factor to consider.
And it includes a precise result, an IT solution dreamt by the client. With minimum margin of error, the customer gets exactly what they expect. There is no waste of money. This is the case when the old saying “good work needs the time” is one hundred percent true.
Overall, I think about those organisations that have already been “burnt once”, their situation is ripe for change and there is a sense of urgency they would probably never want to return to the Waterfall era once experiencing the Agile Method. It is no coincidence that the agile methodology is far more common and widespread in the West than here nationally.
Although the transition is never painless, my experience shows that dedicated work always comes into fruition.
And some well-deserved ovation.