Quick Links

Agile Methodology vs. Traditional Forms of Project Management for Software Developers

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.


Iterative Design

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.


Written by Michael Dehoyos

Michael Dehoyos is a project manager at PhD Kingdom and Academic Brits. He assists companies in their marketing strategy concepts and contributes to numerous sites and publications. He is also a writer at Essay Help, an academic service.

Share This Post
  1. It would be informative if someone could answer a couple of questions about how to apply Agile to fixed price projects.

    If the customer initially requests “A”, and part way through the project changes their mind and selects “B”, who pays for the change?

    If there’s not a set of specifications and a written design up front, how is scope creep controlled?

    Thank you

  2. Michael Boskin’s misgivings are similar to but differ from mine. My question is how to get started, how can I mount a business case without at least a high level waterfall type budget estimate. But I agree with you about large slabs no longer relevant / not delivered. ,My own compromise pre-agile has been modular development: get a broad brush strategy translated to requirements only for non non-negotiables, eg, legal, leading to design strategy as basis for initial cost estimates. This is not popular with finance managers, especially when you explain the likely errors of estimates.
    Then, like Agile, prioritise deliverable chunks, although I think a two week cycle is too limiting. Neither approach avoids the problem of the client’s shift of the big picture leading to redundant development.
    It has not been my (spectator’s) observation that there is anything intrinsic to Agile that encourages more team unity (yes, in theory, but so should a well run traditional approach). Indeed the boy’s own jargony climate can contribute to an us/them attitude..


Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>