Classical Project Management vs Agile Project Management

Classical Project Management vs Agile Project Management

7-9 minutes

Whether you are a Scrum Master , Project Manager, Product Owner or Team Member or simply someone who wants an answer to the question “How do I run an Agile Scrum project in the real world”, this article can definitely provide an answer for you.

Traditional Project Management

The traditional Project Management (waterfall) approach is linear where all the phases of a process occur in a sequence. The approach depends on predictable tools and predictable experience. Each and every project follows the same life cycle which includes the stages such as feasibility, plan, design, build, test, production, support, as shown in the figure below.

Waterfall vs Agile software development The entire project is planned upfront without any scope for changing requirements, such as Waterfall, PMI’s PMBOK, and PRINCE2 are all rigid and highly controlled. They outline distinct stages for project planning from start to finish, and assume that you have all the requirements and information you need upfront.

This approach assumes that time and cost are variables and requirements are fixed. This is the reason why traditional project management faces budget and timeline issues.

Agile Project Management

When a traditional system focuses on upfront planning where factors like cost, scope, and time are given importance, Agile management gives prominence to teamwork, customer collaboration, and flexibility.

Agile rejects these traditional project management methodologies as cumbersome, restrictive, and unsuitable for the new era of speed. Agile project management is iterative and aims at constantly incorporating user feedback and continuous releases with every iteration of software development project as shown in the Figure above. Every task output is a product you’re selling to stakeholders. Team and work structures are designed around creating things that are directly useful to the customer or client.

Traditional or Agile – How to Choose?

According to the 2011 CHAOS Manifesto from the Standish Group, Agile projects are three times more successful than Waterfall projects. The graph below shows the specific results reported from a study conducted based on projects executed from 2002 to 2012:

Agile vs Traditional Iron Triangle in Project Management

Success in project management has been traditionally associated with the ability of the constraint parameters of projects in scope, time, cost, and quality called iron triangle as shown in the Figure below. It is a popular metaphor pointing out that the project manager is asked to reach a reasonable trade-off among these constraints.

Agile vs traditional iron triangle in project management

What is the Problem of Traditional Iron Triangle?

For example, a project can be completed faster by increasing budget or cutting scope. Similarly, increasing scope may require equivalent increases in budget and schedule. Cutting budget without adjusting schedule or scope will lead to lower quality. In practice, however, trading between constraints is not always possible. For example, throwing money (and people) at a fully staffed project can slow it down. Moreover, in poorly run projects it is often impossible to improve budget, schedule or scope without adversely affecting quality.

In traditional sense, Iron Triangle in project management is clearly insufficient as a model of project success because it omits crucial dimensions of success including impact on stakeholders, learning and user satisfaction. Iron Triangle in Agile Sense – A Paradigm Shift In traditional approach, the triangle would typically look like the one on the left as shown in the Figure below. As you can see, there is a fixed scope of product requirements. So in order to ensure the product can be completed all of our required features, we need to be a little flexible with our resources (and budget), and schedule (deadlines). If we absolutely need the product to have a list of features described in the upfront requirements pecification, perhaps we need to delay the release date by several months or more in reality.

In the Agile sense, there are a fixed schedule (in Scrum we do this through time-boxed Sprints , and fixed resources. Thus when things doesn’t work according to the plan, it is the scope that needs to be reduced. In Agile, however, we ensure that even if we have to compromise on scope, we are still delivering the highest priority items in the product backlog for maximizing the value yielded by the project.