As you probably guessed, the answer to this question is: “No”. And, if not properly understood and applied, Agile methodologies could even add some complexity, as they mean additional information to absorb, a new way of interacting with others to adopt,…( I elaborate some ways to interact efficiently in another post).

However, compared to other methods of project management:

  • they will encourage a better level of communication between the actors involved in the project
  • they will give you more frequent occasions to check the progression, update the teams with latest and up to date inputs, and many occasions to rectify the direction, if needed.
  • above all, they will focus on delivering value

We could compare it to having a brand new GPS for a trip: it will provide you with much more accurate positioning than your good old compass and map, but first you need to learn how to use it, understand that you need a least 3 satellites to work efficiently….And it will tell you exactly where you stand, but will not gurantee this is where you want to be!

What are the main Agile methodologies:

There are actually many: at least 42, specially now that the more traditional project management methods integrated some agile principles and created their “hybrid approaches”, but the most frequently faced when dealing with an ERP or CRM project will be :

They however all rely on the agile principles that focuses on delivering a valuable piece of solution or product, leaving the knowledgable experts self organizing themselves and trying to limit all factors that disturb or slow down the delivery team ( named “impediments” in the scrum glossary). It is based on a “bottom up” management approach where people in charge of doing the job are best placed to tell how to organize themselves and make sure the goal is reached. This applies for both the expression of needs ( for stakeholders) and for product delivery (the Developpers and the Scrum team).

What are the limitations of using an agile methodology?

They are actually not limitations linked to the methodology itself, but the tendancy to expect too much out of it and consider it solves it all.

As per my experience, one of the main conclusions i made out of using agile methodologies is that Agility does not replace a “clear design vision” and, agile or not, you need senior resources aware enough of the product’s capacity to succeed in your challenge. I give an example below.

A short real life example

To illustrate the limits i am thinking of, I will take a short real life example I faced several times on projects where SCRUM was used.

For these 3 projects, there were many departments at stake, a lot of heterogeneous expectations to consider and a high degree of uncertainty about what would be the “final unified expectations”…in other words, the business expectations were not mature, and to compensate that it was decided to use SCRUM as a framework “so that we can adapt over time when things get clearer”.

Now let’s say that in your project you want to optimize the way you interact with your business partners. These partners are interesting for the professional and personal roles they may have and you want to capture the right contact information to optimize ther way you interact with them. They can be customers, prospects, but also in the mean time prescriptors or influencer for your brand, decision makers for some association…they have several “caps” for you and all of them are of interest.

One of the reasons you bought a CRM is to limit the duplicates in your database (we are talking of one single person after all), you expect to have one contact per physical person and track these various “roles” toward the other contacts or companies (s)he may be related to. Your request to the teams is therefore to be able to “manage contacts and their various roles“. One important thing is that, of course, the phone number, email and even the address you need to use may vary depending on the role of this person: you will not use the same contact details for John Smith when you send documentation at his house for his family insurance, or when sending documentation for his company’s investments, or his role as administrator for the Charity club of his town. John Smith actually represents 3 roles, with their own and very specific contact details, and you need to use them if you want to be relevant in your approach.

Let’s look at the way it would be managed with the Agile approach:

the product owner and the developers will probably end up creating a backlog with the contact and roles management very high in the value and priority they hold….”Reducing the number of duplicates” would probably be quite important too.

Based on this priorization, they will start the sprints customizing the contact records, the contact form and datamodel so that one contact can have several roles (1:N relationships), each role carrying specific email, address, phone number,…

As we focus on value and fast demonstration of value, the stakeholders will quickly see the contact forms with all the roles this person may have, the exact phonenumbers and emails they need to use depending on the context…and this will look GREAT!

After a few sprints, you have nice contacts and companies forms, with clear visibility on their influence map, the latests activities,…The momentum will be there, people trusting in the product and teams capacities…And this is good news because with 5 to 10 persons in one team, each month easily ends up costing more than 80 000USD…but at least we see where goes the money…

But then a topic starts getting more importance in the backlog: the way to use these nice contact details in the marketing campaigns of course! You do not invest in a contact and customer database not to be able to use the data you collect…who would do that?

For some reason that “obvious detail” has been kept for later: it is a formality, you first needed to design the contacts before talking about the campaigngs, it is standard in Dynamics (we see there is a module clearly named for that), you have no specific need just the basic ones to distribute some emails and letters, sometimes do some phone calls to confirm people will attend an event…nothing huge. The real value is to be able to track all the roles of your contacts, the way to use that information is standard.

But here is the point: up to January 2021 at least, MS Dynamics marketing list have a technical constraint. They can only consider as a source of information the contact information coming from a lead, a contact or an account…and nothing else.

By your side, all the relevant information is not on the contact or company side anymore (and even less the lead), it is on the ROLE! And you end up unable to reach that with the native marketing functionality you counted on.

The options you have are not very fun: either you drop all the work you did during the previous sprints and reconsider the design, or you start finding a workaround to use the information on the roles….in both cases your amount of work and budget to deliver the expected feature has just doubled….at least.

In this example, the SCRUM Team has defined user stories and build their spint backlogs with:

1-the WHAT: the user wants to be able to manage the contacts with their different roles they can play and related contact details.

2-the HOW: we are going to customize the contact entity and form and link them to the roles so we can manage as many roles as needed

3-the WHY: the user wants to optimize the database and have a 360° view of the roles one contact can have.

But some other user stories were hiding behind, and this, only a resource with some experience could detect it:

here one of the “unexpressed user stories” would have been : the user wants to manage the roles of the contact so that (s)he can address the person on the right email or address when sending invites.

and this would have changed totally the outcome of the sprints.

Main conclusions

I mention this short example to highlight the importance of not being lured by the latest trend or methodology, and the importance having a partner with global vision who will be aware of the “real use cases” and questions to ask, even if they are not expressed or identified initially.

Agile methodology will enable to check how we progress to one direction. It will not guarantee it is the right direction, but it will give you many occasions (at least once a month, at the sprint review) to check it and adjust if needed. If you adopted SCRUM or another agile methodology, then you need to understand its principles and events, but you also need strong product experts in the developers team at least, and how to interact efficiently with them.

As a mean of comparison, with waterfall methodology, it would be likely that for the scenario described above, the design is not validated before a solution is found, and therefore no “code” work has been initiated. But it means also you spend more time on the design and theoretical phase, and potentially postpone some milestones without having shown any demo to the stakeholders…there is no perfect recipe, only tools you apply to a given context..