I have written this article for the CIO Magazine Australia in 2014. The published CIO link can be found at http://www.cio.com.au/article/538077/guest_opinion_do_we_need_agile_development_/
As a keen observer of the IT industry, I come across numerous buzzwords and phrases to describe new and improved technology products, services, and implementation methods.
In the software development world, one of the most prominent buzzwords has been “Agile” or the Agile Software Development Methodology, which enables developers to constantly assess if a project is on track through the entire development cycle.
Words and phrases like interactive and incremental, accommodative, cost-effective, faster development lifecycle and reduced project failure rate – among others – are used to sell the Agile concept. It’s even been called the ‘smart’ methodology.
But quite frankly, Agile is just another methodology not a solution to all your software development challenges.
Let’s start with iterative and incremental development where a little more is added into design and development each time more requirements are understood.
If we look closely, this nature of the Agile model combines the phases of the Waterfall model, such as, analysis, design, development and testing within an ongoing loop. It does not offer or add any new phases or elements.
A good project team should always be aware that requirements will change as they design and develop. The team should be smart enough to accommodate the changes with minimum disruption within the existing software development phases irrespective of which methodology is followed.
Agile also allows users to respond to features and review the product for changes on an ongoing basis. This is certainly a good feature but development teams often struggle to think about the bigger picture while they are busy addressing these ongoing reviews. This is because they are focused on the current agile iteration goals to avoid frequent negative feedback from the development manager or users.
Also, over-involvement of users do not always bring simplicity – it can introduce complexity as users constantly change their minds. Thus, software development 101 teaches us that there has to be a cut off point for analysing requirements or adding new features.
Add a large scale development team to this scenario and the accommodative features of Agile diminishes as the complexity outweighs the benefit.
You may also need to buy extra stationery to create and manage an Agile story wall, as well as software to manage the Agile process. Don’t forget, you also need to pay the project lead!
Agile practitioners often disagree but when the methodology is put into practice, the development team struggle to keep pace and documentation suffers.
At the cost of lesser documentation the users may get quicker temporary solution but in the long run, they suffer more when they need to change the software functionality.
Does Agile reduce the project failure rate?
Agile isn’t necessarily all it’s cracked up to be, says Dr Arif Jubaer
As a keen observer of the IT industry, I come across numerous buzzwords and phrases to describe new and improved technology products, services, and implementation methods.
In the software development world, one of the most prominent buzzwords has been “Agile” or the Agile Software Development Methodology, which enables developers to constantly assess if a project is on track through the entire development cycle.
Words and phrases like interactive and incremental, accommodative, cost-effective, faster development lifecycle and reduced project failure rate – among others – are used to sell the Agile concept. It’s even been called the ‘smart’ methodology.
But quite frankly, Agile is just another methodology not a solution to all your software development challenges.
Let’s start with iterative and incremental development where a little more is added into design and development each time more requirements are understood.
If we look closely, this nature of the Agile model combines the phases of the Waterfall model, such as, analysis, design, development and testing within an ongoing loop. It does not offer or add any new phases or elements.
A good project team should always be aware that requirements will change as they design and develop. The team should be smart enough to accommodate the changes with minimum disruption within the existing software development phases irrespective of which methodology is followed.
Agile also allows users to respond to features and review the product for changes on an ongoing basis. This is certainly a good feature but development teams often struggle to think about the bigger picture while they are busy addressing these ongoing reviews. This is because they are focused on the current agile iteration goals to avoid frequent negative feedback from the development manager or users.
Also, over-involvement of users do not always bring simplicity – it can introduce complexity as users constantly change their minds. Thus, software development 101 teaches us that there has to be a cut off point for analysing requirements or adding new features.
Add a large scale development team to this scenario and the accommodative features of Agile diminishes as the complexity outweighs the benefit.
Is Agile more cost-effective?
The cost-effectiveness of agile is also often misinterpreted. Have you noticed that the testing team is always involved as per the methodology or that the Agile coach often consumes a share of your mainstream development budget?You may also need to buy extra stationery to create and manage an Agile story wall, as well as software to manage the Agile process. Don’t forget, you also need to pay the project lead!
Is Agile faster?
Agile apparently builds faster and requires less or no documentation – far less than Waterfall.Agile practitioners often disagree but when the methodology is put into practice, the development team struggle to keep pace and documentation suffers.
At the cost of lesser documentation the users may get quicker temporary solution but in the long run, they suffer more when they need to change the software functionality.
This also has bad impact on the development team who built the software at the first place because it becomes much harder for them to remember the existing functions of the software without the right documentation, or worse, if the development team has changed.
Does Agile reduce the project failure rate?
Reduced project failure rate is another highlighted characteristic of Agile. There is no guarantee that a project will not fail if you follow Agile. A project that failed using Waterfall won’t necessarily be successful with Agile.
That prompts me to point out few reasons why project may fail, such as the incorrect assumption that requirements are fully understood at any given time of the project, that changes will always be manageable, and integration will be smooth.
In relation to these wrong assumptions, Waterfall never forbids the development team to keep understanding the requirements as they develop. It doesn’t prohibit changes from being addressed in small chunks.
Agile more suited to extroverts
Agile is more suitable for extroverts who can promote their work well during the Agile standup. But to the best of my knowledge often most of members of a development team are introverts.
These introverts – who are often very creative – contribute equally like any other team members and with Agile, their contributions often go unnoticed to the demanding project lead.
These introverts – who are often very creative – contribute equally like any other team members and with Agile, their contributions often go unnoticed to the demanding project lead.
Also, the less confident a project lead is, the more he or she likes Agile. I believe this is because each day, the entire team reports to him or her during Agile standup meetings, which gives the project lead a sense of satisfaction.
Ultimately, organisations should invest more in preparing leaders and creative teams and should not invest too much in another methodology that may or may not work for them.
They should find the best way for rational communications between team members and the business without any regular overhead.
It’s important to think about long-term impacts as well, instead of opting for a quick solution at the cost of documentation or any necessary elements, and don’t be influenced by competitors and the methodologies they are pursuing.
If Agile is the only best way forward for a given scenario, then go for it. But you do not need to fit into the Agile box. Creativity should take the upper-hand instead of the so-called ‘smart’ methodology. And the entire team should be vigilant at any given time to achieve short and long term application development goals.
Dr. Arif Jubaer is the founder of Daily Positive (D+). He also holds a PhD in IT from the University of Melbourne.
