What is Agile?

Agile was founded in the early 90s as an alternative method for project management by a group of dissatisfied programmers. Just like many people who carry out projects against the well-known list of ‘project problems’, they ran into high work pressure, unachievable deadlines, budget overruns, tensions between project members, quality problems, and so on. The question was whether there would not be a better project approach that would overcome most of the above problems.

Traditional project approach

In the traditional project management methods (also called waterfall approaches) a large project plan was made in advance in which the path to desired results are described as well as possible, and costs and timelines are estimate, to which the project leaders then try to keep the project team to stick.

The Agile approach is based on a different approach: Agilists assume that it is very difficult – if not impossible – to capture a project in a realistic plan and design beforehand. As a result, schedules of time, money and project results will always turn out differently than in the plan. Why then would you spend so much time writing a project plan if it does not work out?

Agile projects follow a different approach whereby the project timeline is divided into a number of short iterations of, for example, 2 or 3 weeks. The team then goes on to see for each iteration what is the most important work at that moment. Then, after the work period of 2 or 3 weeks, the situation at that moment is examined.

The following video by Henrik Kniberg explains the Agile process:

Agile Product Ownership in a Nutshell

In essence, the Agile approach comes down to this:

Instead of making an extensive project plan beforehand with prior research and designs, you will immediately start working. You build part of the project in a short time frame (iterations, timeboxes or in Scrum terminology: sprints) of about 1 to 4 weeks. And then after that period (iteration, timebox, sprint) you again see what is most important to do in the next iteration. In this way you arrive at the end result in a ​​number of iterations. There are a number of details and further aspects, but in a few sentences that is how the Agile approach works in essence.

After the success of Agile methods such as Extreme Programming, Scrum and DSDM in the ICT world, the approach is now used more often in other environments. There seem to be parties that want to apply Scrum everywhere, but that is not a good idea. Nor is Agile always a better approach than traditional project management.

Sometimes it is a good idea to think through a project carefully before getting started. Working in an Agile way is not without pitfalls or disadvantages.

Types of Agile, what is Scrum?

Just as with ‘normal’ project management, various schools have arisen within Agile. The best known are: Extreme Programming, Scrum, DSDM, Chrystal Clear and many Agile methods for large groups (‘scaled Agile’). Scrum has become escpecially popular and is now the most used Agile system, although … read also: What is Scrum?

Just as with the project management methods, almost no one follows the Agile methods to the letter. And this is the same with Scrum.

There are all kinds of variations on Scrum and therefore the discussions about what works or not, how strict you have to apply certain Scrum rules (“should iteration be a fixed period or may it vary?”) And even whether a project management system should be called Scrum or Agile.

We meet teams who think they are ‘Agile’ when they meet once a week and discuss a todo list (which they have renamed to the Agile name: ‘product backlog’). Or a construction site where Scrum was introduced because the team now starts every morning with standing work meetings (even though nothing else was adopted from the Scrum method).

The fact that organizations experiment with different methods and apply their own Agile ‘sauce’ or brand of project management can only be a good things. Things need to be appied by individuals and should be custom-made to fit people’s requirements. So we must continue to innovate, including at the organizational level.

The confusion that arises from the various ways Agile is applied sometimes can be inconvenient because it can brings confusion and miscommunication.
For example, as a result of our Agile Scan, we encountered an organization where there were three different definitions of the Scrum roles and their related tasks and responsibilities. No wonder the Agile projects were not running well and people kept blaming each other!

A project team (and mother organization) must at least decide between eachother what Agile means to them before they apply their own Agile approach. But we often come across companies that do not yet dare to work with Agile, or only want to ‘half’ implement it for various reasons. Or companies that stick with a project leader, even though an Agile team does not have this role and, moreover, such a role gets in the way of the Agile process. We also regularly come across. statements such as: “we do not have to plan because we use Agile” or “Agile is more of an attitude and mindset, so we do not have to work in a structured way”. But in fact Agile is not that flexible and is certainly more than just a mindset. The more important underlying question is: how should we organize our project and what agreements should we make about the approach?

The advice to organizations and project leaders is therefore: learn the Agile approach so that you can decide whether, how (and if) you can use it in your projects.