Project management

Agile project management vs classic methodology: which one shall I choose?

Agile methodology. Many say it is not a methodology, but it is the attitude towards solving tasks and problems that come up during projects. Believers of the traditional and agile methodology often argue which approach is the right one, but the truth is that you can support the suitability of both by practical examples; so, it is always the particular project and its parameters that should decide which way we should go. We do not want to decide either, but since our company practices agile methodology successfully at software implementations we would like to show what projects, what company culture and attitude can make a system implementation successful with the agile approach.


What do we call agile methodology?

Flexibility, dynamism, speed, efficiency, people centeredness. Maybe these are the words that best describe the agile approach. Agile methodology is a project management approach that facilitates the cooperation of the members participating in a project, and focuses on the fast and good quality delivery of the ready software in a way that the client’s expectations are fully met in the meantime.

It is important to understand the client’s needs and for this the cooperation of talented and motivated people is necessary, that is, good teamwork. So, it is not the methodology that makes a software development/implementation successful, but the excellent teamwork of members working together in a project. Documentation cannot be for documentation’s sake; documentation always has to serve the software and its operation, but it can never be more important than the well functioning software. A contract always regulates the cooperation of the contracting parties; however, it should never damage cooperation between the parties. In case of the agile methodology we plan, but if a change occurs in the project we cannot pass by it only because it was not there in the original plans. Instead, we have modify the plans according to the information that has come to light.

Agile vs. traditional

Let’s start with the classic methodology that others call traditional, it is already a 40 year old concept. The fact, in itself, that it has been applied since 1970 does not mean that it would be obsolete, the problem is not rooted in this.

According to Dr. Winston W. Royce who dreamt up the so called waterfall model, software development projects have to be divided into two main phases: analysis and realization. Of course, while we get to the working software these phases have to be divided into further phases (system requirements, software requirements, program plan, coding, testing, pilot and actual operation. The basis of the traditional methodology is that the expectations from the software are defined at the beginning of the project, we make a plan, and we implement the system by following the plan. At the same time, as we go through the different phases we only have the chance at the very end of the process to check whether we have managed to put together a software that meets the requirements. We could say there is nothing wrong with this, since we followed through the plan; at the same time, there is one thing that is for sure during a project and that is: CHANGE! So, we set everything in the beginning of the project in vain, during the work, almost always, you have to do something differently from what has been agreed on. During the development information can come up that upsets previous plans and they result in new, changed requirements from the client’s side.

What happens then? Is it correct not to take these into consideration and pass by new information because they were not part of the previous plans and we are not implementing a software that serves the client’s needs? There is no project manager who would answer yes to this. We experience day by day when we implement softwares that yes, we have to change the previous plans and that affects the planned cost and timeframe as well.

Project management Agile Classic
Apply in case of medium sized projects yes no
(suitable for handling large projects)
Time of system implementation even 2 months Min. 6-12 months
Assures a low and fixed level of costs yes no
(operates at a high and changeable level of costs)
Medium resource requirements on the user’s side yes no
(high resource requirements)
Risk factor rate: low yes no
(high risk realization)
Handles changing and expanding user’s needs flexibly yes no
(inflexible in terms of changes)

The iron triangle of project management

We call the three criteria (scope, costs, and deadline) on the following diagram the iron triangle of project management; they are defined along quality:

You can apply the above diagram for both of the methodologies the difference lies in which criteria are fixed and which can only be estimated. With the agile methodology the iron triangle is called the reverse iron triangle; we will tell you why in a moment.

While in the case of the classic model the scope (requirements for the software) is fixed because we defined them at the beginning of the project and we progress along them during development or implementation in the case of agile methodology we do not know the scope precisely, it is created during the project and it is equally spread out in the full length of the project. This does not mean that we start software development without plans we simply leave the door open for the solution; we only fix one thing in advance: the kind of business problem that we would like to solve and how we would do all that is shaped by the team throughout the project. This means that with agile methodology the scope can be fine tuned while with the classic way it remains strictly fixed.

There is a difference also in terms of costs and deadlines. The agile approach has fixed costs and deadlines while with the traditional model these can only be estimated. What does this mean? While the believers of the agile trend ask “How much can we do with this amount of money and this much time?” the representatives of the traditional model ask “How long does it take and how much will it cost to do all of this?”

What can be a sprint during a software implementation? For example if we do not launch the software in its full functionality at the client and we do not dump it on the users, but they start using the different functions of the software gradually. In case of our Bixbit software that incorporates 4 important areas (document management, collaboration, task management and workflow) it is recommended that first only the collaboration and document management functions (using the wall/news feed, opening a topic, commenting, document sharing) would be used in the beginning then in the next sprint the functions of task management can follow such as task distribution and reception and key users can practice these. Later, when these functions work smoothly workflow planning can be introduced with setting and using simple and more complex workflows. This way, our bixbit collaboration software can be implemented in even 10 weeks!

So, based on the above, if we work in a quickly changing environment where the needs of the client change often then the agile model would useful; while in an environment based on rules and commands and free from change the application of the traditional model would be practical.