IT Project/Program Management: Development Methodologies: Agile vs. Traditional

 At a network group meeting I was asked the question if I had used Agile and Waterfall development methodologies. My reply and response was yes. I was asked which do, or did, I prefer. I said I had used both and while each has it pros and cons, I have used each and have combined/mixed activities and processes of each and been successful during the 21st century. The following is my public response to the question of Agile vs. Waterfall or Traditional system/software development methodologies.

Summary

There has been a long standing argument as to which development methodology is the best. This article debunks the myths and sets the record straight with some pros and cons of each methodology.

Introduction

In the IT industry, there seems to be much debate about Agile vs. Traditional methodologies (e.g., Waterfall). With system, software, and application development, methodologies have continued to be improved upon from Waterfall to Agile. That is why we have Total Quality Management (TQM) and process improvement activities and processes. But there will always be debates between individuals that want to prefer one methodology over the other.

A true statement is: No methodology is a silver bullet. However, some methodologies may be more appropriate (or suited) for a particular project or program. The questions and selection should be what methodology is best for the type of program’s or project’s solution and within the current parameters of the project/program such as time, cost, and quality and client/user satisfaction.

Each methodology (and there are others that are being used) have their pros and cons, and you have probably heard a number of them, along with the debates or discussions that follow: Traditional is sequential, non flexible, etc. Agile has iterations but lacks strong requirements definition, management, extensive planning and costs estimates, etc. But let me state Traditional, or let’s just say Waterfall, has its successes: remember the shuttle and space programs, and other government projects and programs. It also had an improvement process which included incremental activities/processes, parallel development, modular code development, etc. and now the use of object-oriented development… and it is important to realize much of its application was in environments that system reliability and the safety of people were the primary concerns. Agile with its iterations and incremental development, along with SCRUM has it successes with improving areas of team sizes and management, improving requirements definition, and full or complete development cycle (like Waterfall) for iterations (iterations still have to go through requirements definition (with limited documentation), analysis, design and test).

While Agile has been on the scene for less time than traditional methodologies, and has its criticism such as not being suited for large complex projects and programs, there has been/and is a natural progression of improvement in areas such as larger team development and management, more extensive planning and cost estimating, and stable requirements definition for each sprint. But for each methodology, TQM and lessons learned are all about contributing to the process or project’s improvement and providing best (and good) practices.

Several Successes in the 21st Century:

1. With Agile:

For a web application development project an Agile methodology was used with a project management process (Scrum and a weekly PM meeting with the client).

Challenges that were overcome:

• First time for some team members using the Agile methodology
• Determining the size of teams and if they could be co-located
• Ensuring that QA/Testing activities were appropriately included for each iteration

2. With Traditional:

A project for system and firmware development used the Waterfall methodology based on the client having executed successful projects with it and some failures using others.

The project was considered a success and had several out-of-scope changes.

Challenges that were overcome:

• Ensuring requirements were stable and mutually agreed to by the customer/users and developing company
• Ensuring configuration management was implemented properly and correctly from the beginning of the project

3. Agile and Traditional methodologies combined/mixed:

A project and program that required both methodologies to be used and in one case the client expected and mandated that a traditional waterfall (sequential) approach be used for certain areas of its business application development because it was concerned about the impact it may have on its finance, billing and payroll. The client/customer wanted to ensure that the critical requirements were addressed up front and more detailed planning costs were provided. Note: Why? On a previous project the cost was different then was negotiated in the beginning. Do not use/negotiate a fixed priced contract without having a very good project or program for an example of useful historical information and data.

Challenges that were overcome:

• How to use virtual project management
• Establishing small and large teams but at various/different locations geographically
• How to release the functionality (or sprints)of the product until full product release as contracted when using a combined/mix methodology
• Customer being technically capable (having an IT department but not having resources available) wanted/ mandated several requirements definition activities and the methodology

Each of the projects and programs had their challenges, risks, issues and project, product, and system changes that were addressed by early establishment of the appropriate development methodology and supporting CM and QA processes. The projects closed successfully within approved budgets (cost), on schedule, with the acceptable requirements and to the satisfaction of the client/users.

Conclusion and Recommendations

I learned early in my career from my coaches and mentors that there are no silver bullets, so prepare for changes and improvements, be open, flexible, make the necessary adjustments and focus on the client.

So let’s step back a moment.

For a solution, if an Agile methodology is determined to be the best methodology to use, make good use of it and Scrum. If a traditional methodology is selected, or mandated, make good use of it and the project/program methodology. Or if a combined/mixture is determined to be the best approach moving forward with the use of best ( and good) practices to develop or improve any area, then make good use of the combined/mixed methodologies.

Recommendations

I’ve been comfortable with each methodology as long as there was an evaluation to determine which was more suited for a particular project. Moving forward from the use of best ( and good) practices to develop or improve any area is what should take place, but one discipline over the other can sometimes be extreme because neither has stopped a significant number of failures alone. But let’s see over time if the IT project (and program) success rate increases beyond 50 %.). Keep in mind:

1. Select what methodology is appropriate, tailored as required and/or combined if required (sometimes it’s mandated to use one or the other). Remember both are still based on the foundation of the SDLC (System/Software Development Life Cycle).
2. Document and use lessons learned, share knowledge and improve any area including best practices.
3. There is no silver bullet so continue to improve a development methodology that will suffice now, through and beyond the 21^st century. That is what innovation and creativity is about. But be open- minded, make the necessary adjustments, and continue to be successful because we surely need to increase the success rate of projects (and programs) in the IT industry.

Tip for choosing a methodology: If you understand math, there are different ways to solve a problem with the same answer (solution) but for a development methodology, make it the most effective and efficient one.

Thank you and good luck!