Delivering a Software development on time has always been a challenge for IT companies. Today’s dynamic market has added further to the complexity. Whether it is the nature of client needs, the time available to develop and test software or the needs and convenience of the developer team, Agile methodology seems to be coming to the rescue of many IT companies.
There are die hard fans of Agile now, who talk about Agile as being a one stop solution for everything – from delays in project to people issues. I am reminded of the “fevi-quick” advertisement that shows it can fix any broken item -right from ceramic to plastic to glass etc.
In my experience of working in companies strongly influenced by Agile philosophies, this obsessive approach actually becomes a bit frustrating.
This article is therefore, an attempt to introduce and explain the Agile philosophy.
The method so far – the waterfall methodology
If we rewind a bit, the old way of software development was what is called the “waterfall methodology”. In this methodology, there are different stages of development; and each stage was to be signed off with the customer.
Typically, the stages in the waterfall methodology are –
- Requirements collection phase
- Analysis phase, design phase
- Development phase
- Integration phase
- Testing phase
The project duration is agreed upon and contracted with the customer in the beginning. Each phase is signed off with the customer, with a set of documents sharing the status of the phase.
A customer gets to see and use the software only at the end of the whole process. There is, therefore, always a high possibility for mismatch with the original requirements and the customer would know of it only on final delivery. This was one of the biggest challenges of the waterfall methodology.
The market is dynamic and the need to adapt to this environment is high. In the waterfall methodology, customers and companies end up in tight negotiation of the contracts, in terms of timelines, money and quality aspects. IT companies have challenges to manage the development within the contracted budget; and handling expectations of demanding customers gets difficult.
Introducing Agile Methodology
In 2001, a set of 17 independent thinkers of software development got together to brain storm on the current state of software development (you can read more about this at http://agilemanifesto.org/history.html.
They formulated a set of 4 values and 12 principles for software development and called it the “Agile manifesto”. Their objective was to develop software through collaboration between development teams and customers. This was a radical approach to software development for companies. Their motive was to reduce turn-around time, adapt to the dynamic market and provide a way to get frequent feedback from the customer to reduce mismatch at the end.
The Agile manifesto values
- Individuals and interactions – over – processes and tools
- Working software – over – comprehensive documentation
- Customer collaboration – over – contract negotiation
- Responding to change – over – following a plan
While the terms on the right – Process and tools, Comprehensive documentation, Contract negotiation and Following a plan are all important, the values written in bold are more important for the agile methodology.
Agile methodology – Cyclical, stage wise instead of linear
This brought a shift in the thought process of the software development where, instead of linear development, it became cyclic in nature. This meant that software would be developed in stages and every stage had an output that the customer could use and provide feedback to the company.
It’s hard to visualize this, isn’t it? Let me walk you through an example.
Let’s say you were a customer who wanted an application to manage your books of accounts. What is the most important feature that would be valuable for you? May be the entry of the incomes and expenses?
In Agile, this is what you will ask the IT company to develop first. The company will develop that and demonstrate you just this feature. You will experience using and playing with this feature of adding income and expense into the software and you share your feedback of using it to the company. The developer company then implements this feedback and shares it with you.
Now you have the opportunity to ask for the next important feature; may be just the report of income and expense. This then follows the same cycle as the first stage.This way of cyclic development gives you, as a customer, an opportunity to change the requirements and provide feedback to fine tune the requirements.
The cycle can be represented below:
Agile methodology is more of living the values of the manifesto rather than following some processes. This means, that Agile is not a magical solution for all the problems; instead it is an invitation to re-align the value system of the IT business.
Agile Methodology – A value system to be lived by
Companies do not realize that the changeover TO agile must happen at a value system level; they continue to believe it’s just about the implementation of a process. This is counter-productive for both companies and customers. That’s where it gets frustrating!
It is not an easy task for any organization to change at a deeper level. Agile values are like our other values, such as, honesty, for example. I cannot “do” honesty, isn’t it? I can only “be” honest!
You cannot be “Doing” Agile; you have to “Be” Agile.
I invite you to reflect on the agile manifesto (http://agilemanifesto.org) and the 12 principles (http://agilemanifesto.org/principles.html). I make an attempt to live by agile values in all the work I do, even as I work as an Agile coach and help companies in adopting the methodology.
If you have questions to ask on the Agile Methodology, I will be happy to answer.
Please do leave your comments at the bottom and do share with others if you like this article.
Nice DD. Agree wholeheartedly as I see some ham handed approach trying to derail what I have painstakingly created call it theoretical!