Does Agile Work for Short-Term Projects Only?
Read this article to find out if long-term planning and management of large-scale projects is or isn't possible with Agile methodologies.
Join the DZone community and get the full member experience.Join For Free
we know agile as an iterative approach to managing projects and change, based on building plans for short intervals only and hitting the reset button at their end to start again from scratch.
should this imply that long-term planning and management of large-scale projects is not possible with agile methodologies?
this line of thinking would have a fundamental flaw — an assumption, that good results actually stem from a plan . as if making the decision to achieve a given result was equivalent to having this result materialized.
isn't it more likely that it is the process itself that forms the outcome of a project? and that putting an emphasis on the project execution and caring for details should, therefore, bring better results than having a great master plan?
does it not make sense then to have as many opportunities to rethink the next steps and to exercise many short-term goals, rather than complete a large plan without any critical view on it along the way?
requirements will change for long-term projects even more-so than for short-term ones, so having to re-evaluate the best way forward a number of times cannot be a bad thing, can it?
agile therefore greatly supports long-term jobs with the following:
multi-level verification makes for a better product
thanks to this, you get to prove the value of the project's assumptions various numbers of times, rather than just once without ever looking back. this is fantastic for highly competitive product development, as you're able to rethink each aspect of the product numerous times, often by involving different groups of people and hence adopting multiple perspectives.
improving globally while evaluating locally
while viewing an aspect of a repeatable project a number of times, there is a chance that teams will be able to actually spot fundamental flaws in their work overall, and therefore use these as opportunity for large-scale process and methodology improvement. you could say, that single project improvements breed global method polishing.
being agile means great flexibility
with taking on an agile approach you give your team time to actually respond to any new demands, to make appropriate changes at the time they are needed, instead of having to go on with original requirements — which everyone can know to be outdated halfway down the line - just because this was the plan.
the quality and accuracy of the result is the goal, not the perfect alignment with the initial plans. this is highly valued by the stakeholders.
though it may be easy to associate agile with sprints and quick action taking, it's worth keeping in mind this can be used to great advantage for large scale and long realization term projects.
Published at DZone with permission of Anna Majowska, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Fun Is the Glue That Makes Everything Stick, Also the OCP
Best Practices for Securing Infrastructure as Code (Iac) In the DevOps SDLC
Integration Testing Tutorial: A Comprehensive Guide With Examples And Best Practices
Write a Smart Contract With ChatGPT, MetaMask, Infura, and Truffle