Something of a revolution has occurred in the software development arena over the last few decades. Many companies, large and small, have converted to Agile project management methodology instead of the classic Waterfall type approaches that had dominated the development landscape some years ago.
In my view, the reason for this is simple. The software development industry had one of the worst track records for delivering products on time and according to budget. Companies simply were not able to adapt to moving targets; they were not agile enough.
While it is true that now the software development community has, by and large, adopted Agile, not everyone is certain exactly how it differs from the traditional methods of project management. I’d like to suggest the following key differences, which suggest why Agile is the way to keep moving forward especially in this industry.
Planning vs. Starting
Traditional project management philosophy called for a seldom ending supply of paperwork. A company could spend years developing specs before any development began. A common issue with this approach was three years down the road a company finds itself working on a project that is no longer relevant. An Agile approach, on the other hand, hits moving targets and does not get bogged down with mountains of paperwork. It starts development right away with an iterative approach.
A Focus on Functionality
We’ve all heard that with any given piece of software only about 10% of available functionality is utilized. This means developers spend lots of time and money on functions that the end-user has no real use for. The Agile solution for this is to focus on the most important items of functionality first ensuring that the most useful functions get priority and are properly implemented.
A standard development cycle builds a prototype at the very end. By this point, a great deal of time has gone into planning and designing. Lots of meetings, paperwork, proposals, and back and forth between the development team and the client has mostly likely occurred. Within an Agile framework, the aim is to create a prototype as soon as possible allowing developers to show something to the client or end-user that they can interact with. This interaction provides valuable feedback at each level of iteration or each Sprint. Gene Gervontas, a project manager at Britstudent and Write My X, states, “The whole point of iterative design is to get the product in the hands of the end-user as much as possible. The software development field has always suffered from a poor understanding between the client and the developer and the iterative approach is how it can be solved.”
Changes are Embraced
David Erving, a business writer at Australia2Write and Nextcoursework, points out that “Development cycles are often long and many changes occur along the way. The end product is not what the initial design phase had come up with. These changes are much more difficult under a traditional Waterfall type approach since these are static philosophies which do not lend well to change.” Alternatively, because of the iterative nature of Agile, any team that takes up an Agile approach to software development will be well situated to incorporate change. Changes can be made at any step of the way with relative ease, since with an Agile approach, a new prototype is usually only two weeks away.
Encourages Teamwork Not Encapsulation
One of the main premises of Agile methodology, especially under the SCRUM framework, is that entire teams meet together to help solve problems. In a traditional setting, backend and front end developers might have never seen one another. This type of environment bred a “not my problem” attitude, where problems become encapsulated within the specific area in which they arise. Now with more software companies embracing Agile, problems are taken on as a team and solutions come to more easily.
There Is Always a Working Product
It happened all too often that projects were terminated because funding ran out. And, if funding ran out before prototype testing, the client had nothing to show for it. Because of the constant development of prototypes focused on functionality, Agile methodology results in always having a working product. The same cannot be said about traditional Waterfall approaches.
So, what do you think? Are you seeing the benefits of Agile in software development projects? Are there improvements yet to be made in methodology? I’d like to hear from you in the comments below.