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.

Agile brings a number of new principles and insights to projects such as:

• Team members have much more to say about the project and are therefore often in multiple alternating roles: advisor, executor, designer, planner
• The design of a project result gradually develops over time and is usually not predetermined
• Project steps (milestones, interim results) are cut into smaller parts, making the work easier to understand and can be adjusted more quickly if an element to be built does not work out as desired
• Teams are invited to try out things that promote innovation and creativity (and more motivation!)
• The planning of the project is based on smaller elements, which is more realistic (compared to large deadlines over ‘a few months’)
• The team will start building almost immediately and will not wait for instructions from a project plan

Working in the Agile way has a few major advantages:

• The iterative approach allows you to steer the project in a different direction if necessary, for example if the specifications of an intended project result in change in the interim
• By regularly delivering intermediate results, problems and errors are more likely to come to light
• The whole team is involved in the construction and development of a project instead of this being done by individual specialized designers, project leader(s), builders and testers
• The team is less under pressure because there is less chance of ‘cramming’ too much work into an iteration (compared to the pressure to reach a deadline that is not realistic).
• The relatively short iterations make the progress of the work more visible, which motivates the team and provides more insight into the progress to clients

(see also: the Agile manifesto)

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.