Is this the moment I should adopt Agile? Where else, apart from IT, can Agile be useful? Are there any situations when you’d better not take it into consideration? This is the first article in a series in which I am going to answer your questions and clear your doubts as regards Agile.

When should I consider doing Agile? There are several reasons why companies consider implementing Agile. I am going to present the most popular ones:

#1 Tasks the team is supposed to deal with are difficult or it would take an unreasonable amount of time to estimate the timeframe and/or workload.

What time would be reasonable to estimate the timeframe and workload? Well, it would have to be much shorter than the time you need to complete the tasks you plan. However, sometimes planning takes much longer than the work itself.

When does it take longer to plan the work than to actually do it? 

It may happen if you need to do some research. For instance, an advertising agency plans a new product campaign. The team is not able to determine how many days it will take to develop it  because they have to do some market research first. Depending on the findings they will adjust the campaign they work on or do some more research.

Ok., but every project has a deadline. You have to be able to estimate the time you need to complete the project and set the deadline.

Of course, every marketing campaign has a deadline. In reality however the team usually will say: “Well, we will do what we will manage to do in the time given so as to cover at least the necessary scope of the assignment”. But they will not strictly follow the schedule

How can Agile help me in such a situation?

Thanks to the „Inspect and Adapt” philosophy Agile lets you start a project even if you know only the direction in which it is going to develop – and not its definite and detailed goal. It also provides a mechanism that allows you to control any changes in the way the team works during the project, in regular intervals. In addition, Agile assumes the goals will change as the project develops and it lets you introduce those changes without having to start everything from scratch, if only it is physically possible.

#2 You are not able to determine how much time your team will need to complete the tasks.

There are instances you cannot determine how much time you need to reach your goal, no matter how much time you spend planning your work.

What do you mean by saying it is impossible to determine the time needed to reach one’s goal? If I know what I have to do and how it should be done, I will be able to tell you how much time it will take me to do it, right?

Yeah, I often hear this catchy but fallacious argument. Let’s take my favourite example, the recruitment process. Most HR department have a set of recruitment procedures. Forms, channels, requirements, and so on. These are usually ready or you need only a while to have them ready. And this is the moment we should ask ourselves a question: “If we know what we are supposed to do as regards recruitment, why does it sometimes take us a week and sometimes 2 months to find the right person?” The answer is quite simple – you cannot determine the time you need because you operate in an environment that changes dynamically. This causes certain problems. How can you plan to recruit more people if you don’t know how long the current recruitment process will take?

So why not assume that we need 2 months to reach our goal. After all, we know 2 months will be enough.

Sure, you can assume you need maximum 2 months to find someone suitable for the position. And what if you find that person within a week? How will you plan the team’s work then? Often, traditional management methods are not helpful in such situations.

How can Agile help?

In Agile we have a queue of tasks to be completed. It is not something that differentiates Agile from other project management methods but what makes it different from them is the fact that in Agile there are self-organising teams. Each member assigns tasks to themselves and they do them in the optimal time. Such an approach makes it possible to balance workload for each employee in a given department

#3 You don’t know the scope of the project and its scale at the start of the project.

How come you start a project and don’t know its scope? Well, that’s simple: it happens when you know the need but you don’t know how to address it.

In what kind of project aren’t you able to determine its scale from the very start?

There are a number of need-based projects whose scale cannot be predicted, for instance:

  1. Optimisation of processes in an organisation.
  2. New product development in line with dynamic market trends.
  3. Taking over and starting the maintenance of a product developed by an external partner.

And there are many projects whose aim is known to us but you can still discuss what steps to take to reach that aim.

How can Agile help in this situation?

In Agile you work iteratively. To put it short, this means that every large project is divided into a set of smaller stages called iterations. What makes Agile iterations different from iterations in other project management methodologies is the fact that after each iteration an increment is produced. And what is increment? Well, it is a ready-to-use fragment of the final project. Or, in other words, after each iteration you get a fragment of the final project and you can use it straight away. In the examples I discussed above an increment could be:

  1. One or more optimized processes.
  2. A module of the product based on market research.
  3. A fully or partially taken over fragment of the product.

These are just a few reasons why you should consider using Agile. If you know any other and you would like to share your opinion with other readers, leave a comment.

Follow the blog to make sure you don’t miss my next post. I will be talking about instances when Agile should not be used and I will explain why.

Coach, mentor and Team Leader. Certified .NET developer, Agile enthusiast and Machine Learning specialist. In his free time ̶ avid scuba diver and fantasy books reader.