Traditional vs Agile Project Management | My experience

In times of continuous change, project management has become a central activity in most organizations. Projects are used today not just for new product development or construction, but for numerous other reasons: product improvement, system deployment, process building, process re-engineering, software development, and many others. Yet, project failure, delays, and disappointment are still much too common to be neglected.

So where exactly the problem is? …. Or are we not following the principles, guidelines, processes and so on of the agreed & well tested methodologies. The answer is Yes, we follow but still things doesn’t work and fails.Why?

Possibly it could be the way we work, we think and methodologies we follow. All these forces to Need a Change in PROCESS BUT Why? Well the answer could be...

“To Seek efficient methods to address new development techniques”.

Now the question comes whether Traditional Method(s) are not efficient enough to manage and deliver the system successfully. Take a look below:

Facts about Traditional Methodologies 

• Sequential approach with formal hand-offs at milestones
• Rigorous planning and upfront analysis.
• Recognizes that changes and bugs are much more expensive to fix later in the development cycle.
• Expects Functional specifications to be explicit and clear.
• Integration testing and system testing often are formal steps at the end of the schedule

Actually, In Traditional techniques, one know's how far the finish line is and goal is to reach it as quickly as possible.

But still the project fails….

The survey says …

–       30 - 40% of systems projects fail prior to completion

–       Half of all systems projects overrun their budgets and schedules by 200% or more

–       67% of customer-relationship-management projects fail

Why?

Let’s take a look on following brief dialogues between Project Manager and Customer….

Project Manager

Customer

And finally here comes the Conflict….

So whom to blame Customer or Project Manager? Well answer is none of them; it’s the way we build software.The traditional way of building software simply does not work and fails to tackle:

• Demand for Quicker delivery of system
• Increasingly vague, volatile requirements

Here comes the Need of Agile

Agile is an adaptive approach to solving business problems that focuses on communication, collaboration, delivery and change. It is

• Building software iteratively and incrementally
• Specifically designed to efficiently cope with change

On an agile project, one don’t know exactly where the finish line is, but often knows we need to get to it or as close as we can by a known date.

Through this work we have to value:

• Individuals and interactions OVER Processes and Tools
•  Working software OVER Comprehensive documentation.
• Customer collaboration OVER Contract negotiation.
• Responding to change OVER following a plan.

But saying is easy, and to implement it is very difficult, the practices and philosophies has to be changed and followed with due respect!!!

New Philosophies

?         Do more of what works, and less of what doesn’t

?         Change at least one thing when you go to work tomorrow

?         Make your project a reality show

?         Always focus on providing value to the user

?         The tighter the feedback the loop the better

New Practices

?         Release Planning

?         High Level Design

?         Estimating Game

?         Planning Game

?         Daily Stand Ups

?         Refactoring

?         TDD

?         Continuous Integration

?         Pair Programming

?         Collective Code Ownership

?         Show & Tell

?         Common Workspace

Suggestions

?   I believe that every project has different needs. This forces us to let our process be flexible, to meet the needs of the client, and to always be providing value

?  If something doesn't make sense on a project, we don’t do it. The converse is also true. If there is something we can do that does provide value, we do it

?  This means we should take what makes sense

Development Environment

I believe most of the organisations follows or better to say tries to follow couple of Agile Project Management Practices BUT most of the times Ignores to configure Agile Development Environment.

There always arises conflicts among the development teams and team struggles a lot. In Agile world Build and Test Services always works parallel to each other. The code is placed into version/source control and built/compiled/integrated immediately when a change is made and Immediately after the system is built it is tested. For small projects, testing may be limited to Development Test but for larger projects, more in depth testing will occur. These all together constitutes "Continuous Integration", a very important part of Agile practice and beneficial in many ways such as:

• When testing fails or defects are discovered, the team has the option to return to the previous code base without debugging.
• Integration issues can be found and addressed during each cycle
• Early warning system
• Constant availability of a "current" build 

So, I strongly believe it is equally important to set up an "Agile Development Environment" for quicker and faster delivery of quality product. A high level representation can be depicted as follows but it may vary project to project:

Conclusion and Summary

?  Traditional methods are designed to prevent change, but fails, making it a very , very inefficient

?  Agile is designed to cope with changing requirements. It is efficient because it builds quality into it’s processes

?  Agile is hard work but it does work …

I welcome your comments......