Ever since the idea of Agile Development was first introduced in 2001 by several veteran software developers as an alternative to conventional Waterfall development, it has proven to be a polarizing force. Compared to Waterfall, which was considered dysfunctional and slow, Agile encourages flexibility and speed when responding to the changes in requirements by users and business needs.
While some in the business and IT sectors were enthusiastic about the ability to achieve quicker results and were welcoming to a shift away from the old ways, others were opposed to it. One of the main reasons for those disliking it was that it involved making what they saw as disruptive alterations to processes that were already firmly established and that it could be burdensome for some users. On top of it, a classic human resistance to change has also greatly contributed as a fear factor.
Although the truth about Agile is closer to the center of both sides of the argument, some myths need addressed to make sure constructive discussion can be had between business leaders and IT teams. Let’s debunk some of these myths.
Agile Means You Don’t Need to Plan
Agile will only be effective if you have planned things out thoroughly, just as is the case with Waterfall. The major difference between the two styles of development is all about the timing. With Waterfall, most of the planning takes place at the start, whereas with Agile it is ongoing.
Thanks to its incremental approach to planning, it keeps the startup costs low and ensures projects can rapidly and readily adapt to any changes.
There is No Documentation For Projects with Agile
With any development of software, there is always documentation. It acts as a road map for the work required, explaining how the system will operate, what it will involve and helps the development team to stay focused on their business objectives and ensures that the needs for all, including the developers and users, are fully aligned.
The reason some believe that Agile requires little to no documentation is that there is a greater sense of collaboration when using this methodology there is not the same need for documentation every step of the way.
Agile is Some Kind of Cure For All Challenges in Software Development
As most of the champions of Agile proclaim that it is better than Waterfall in terms of earlier risk/issue assessment, quicker delivery with working functionality and much clearer alignment with what the stakeholder wants, some feel it is the most effective in any given situation.
However, this is not true. There are various reasons why projects involving the development of software fail and often its simply down to not executing the development method correctly in the first place. The one downside is that Agile is not always the best option for projects where there is no way to break down things into smaller work units for completion at increments of one to four weeks.
Agile Equals Scrum
To put things simply – Agile is a methodology and the mindset whereas Scrum is one of the agile frameworks. There are multiple frameworks that exist within Agile, but Scrum is by far the most widespread, used and successful one. In fact that is the way most people start their journeys into the Agile world – by becoming a Scrum Alliance Certified Scrum Master. At the same time, if you are more product focused and would like to drive the requirements side of product development, then a Certified Product Owner may be a better starting point for you.
Agile has its roots into Extreme programming and lean programming, yet other hybrid models are popular these days as you need to find the model that fits your business the best. In fact, the great thing about Agile is that they don’t need to fully go with one approach, they can simply cherry-pick the most relevant and appropriate existing processes to adapt better to stakeholder needs, deliver the software incrementally and increase collaboration with the stakeholder.
Agile is Only Suited to Smaller Projects
Some people seem to believe that Agile is only effective for smaller projects when the small, cross-functional groups involved in collaboration through Agile are just as effective when working on and more complicated systems as they are on the smaller point solution ones. As Agile teams tend to take a “divide and conquer approach, it is beneficial to larger projects.
_________________________________________________
Interesting related article: “What is Information Technology?“