A taste of an Agile ERP project implementation

Cartoon of 2 people in front of an Agile ERP project board.

Have you been wondering how an Agile ERP project would run? Today we are going to explain our version of the Agile methodology and how it applies to an ERP implementation.

This article forms part of my series on ERP implementation. You can check out an overview here.

Before we get into it we should point out that the term Agile actually refers a set of principles not a specific methodology. There are a number of software delivery techniques that are considered “Agile”.

Agile methodologies focus on early and continuous delivery of valuable software.

This line comes from the Agile Manifesto that was created in 2001 by some of the biggest names in Software development. If you are interested in reading more you can check out the the core principles of Agile.

Our agile methodology

What we describe here is our version of Agile delivery. If you are familiar with the specific Agile methodologies then you will notice that we use our own version of a Kanban based approach.

Using this approach we define the different things that you need the system to be able to do. We then track each one as it goes through design, development, test and deployment.

With our Kanban based approach we limit the number of things we are working on at any one time. This way we ensure regular delivery of new functionality over the life of the project. Another key aspect of this approach is that we use a visual board to show this work, which looks a little bit like this:

An agile ERP project kanban board

What follows is a more detailed explanation on how this happens when we put this approach into practice.

The pros and cons of Agile

But wait! Before we get started let’s have a quick look at the Pros and Cons of using an Agile methodology.


  • Agile projects are designed to deal with changing requirements well, which is great for projects that don’t fully understand their requirements.
  • Feedback and testing occurs throughout the whole project allowing for direct feedback from you, the customer, regularly
  • Working software is delivered regularly allowing you to start seeing benefits much earlier than a waterfall approach.
  • Requires frequent communication between the customer and the supplier to ensure the right things are being built


  • It is hard to predict the overall timeframe of the project as a result of the changing requirements.
  • As a result of the flexibility in requirements it can be difficult to determine when a project is “done”.
  • Requires a greater level of time commitment from the customer as they need to be actively involved throughout the entire project.

Kicking off of your Agile ERP project.

As we start the project we decide what you need and don’t need in your ERP system. Our approach is two fold – looking at your business processes and then looking at the standard ERP functionality.

First we want to get to know as much about your business processes as we can. An ERP solution should be a digital implementation of your business processes and so for us to implement this right we need to know how you currently operate. If you already have these documented before we get started then this will go much faster for you!

Cartoon of a lady with project scope ideas swirling around her

With your processes identified we work together to decide which of these processes we will implement (in scope) and those that we won’t (out of scope).

The second part of the scoping exercise we look at the standard ERP functionality and the best practices for your type of business. Again we need decide which parts you want and those that you don’t. A few examples of the areas to consider in an ERP system implementation are:

  • Financial Tracking
  • Customer Relationship Management (CRM)
  • Stock Control (raw materials or ingredients as well as sellable products)
  • Human Resources (tracking staff employment, leave, timesheets)
  • Project Management
  • and so on…

If you have already read out guide to waterfall ERP projects then you see some similarities up ’til here. It’s from here on out that things start to get a bit different.

Costing Update

Usually after we have discussed the scope we can provide you with a more accurate cost estimate for the whole project. The more details we have captured about each epic the more accurate we can become.

Keep in mind that Agile projects by their nature are very rarely fixed price due to the nature of the regularly changing requirements.

Platform selection

With the high level scope defined as a guide we start the real process of designing and delivering your ERP.

The first and biggest decision is which ERP platform to use? We use the information we have gathered during the scoping session to make this decision.

Documenting the scope of your Agile ERP project

So we have discussed the scope but how do we document it?

Picture of clipboards with a line drawn by a fountain pen.

As we mentioned earlier we use a visual board for tracking all of the work that needs to be completed. At this stage we start tracking our scope by writing something called an Epic, which we place into the backlog.

Wait… What? What on earth is an Epic?

– You (probably)

In an Agile project we often describe what you need (your requirements) as a ‘User Story’ (we will cover this a bit more in the next section). An ‘Epic’, just like in the fiction meaning, is just a really big story that is made up of many smaller stories which are logically related.

For example we may have an Epic titled “Production Scheduling” which is the high level scope for how and when you schedule your products to be produced. This will later be broken down into more detailed stories but it gives us a way to ensure the scope is tracked.

Pick an Epic

So we have captured all of the epics that you think you need. Now we can get into the real work of delivering your software.

To start with we usually pick the epic that has highest benefit to your business. If there’s a process that currently manual and can save significant time if we automate it then we would probably start there.

Breaking down the epic to user stories

A cartoon scene from a park used as a representation of  a user story

Now we start to flesh out that Epic by writing the “User Stories”. A user story is a specific way of writing requirements that is very popular in Agile projects and they take this form:

As an <actor> I want to <do something> so that <business goal can happen>

For example:

As a production manager I want to be able to schedule a production run of a specific product and size so that our customers purchase order (or orders) can be fulfilled

One of the key things here is the “so that…” section. With that we as the builders of your software have a better understanding of why you need to do what you want. Sometimes we may be able to suggest better ways of achieving that goal that save time and effort!

The entire Epic at this stage may not be completely written out as User Stories. We may just focus on the one’s that will deliver the best business benefit for our effort.

The Stories that have been written go onto the board in a column called backlog. This is the list of things you want the system to do but we haven’t looked at how to delivery them yet.

Choosing the user stories for implementation

With the stories being written you can now put a priority on them and choose the order in which we start delivering them.

As with choosing the Epic to work on the decision of which stories to tackle first is yours to make. We can advise you but ultimately you know your business best and what is going to deliver the most benefit to you.

When you have selected a user story that you want delivered then we move it from the backlog into the “Ready To Start” column.

The user story implementation

A cartoon of a person doing development on a laptop

When our team is ready to start a new story they move it from the “Ready to Start” column and into the “In Progress” column.

While in this stage we will:

  • Design
    • We determine the best way to meet the story with the ERP platform selected. Sometimes this is very minimal as the platform provides a clear way of meeting the story. Sometimes it may require some effort for more complex stories.
    • During this stage we may need clarification and guidance from you to ensure you get what you actually need.
  • Build
    • We configure or build the part of the system needed to meet the goals of the user story.
  • Verification
    • We test it and make sure we are happy.

The user story testing

Once we are happy with what we’ve build we we will move the story into the “Ready for Test” column.

This means that it is done and now ready for you to verify it. You need to make sure that the delivered system meets your needs especially the business goal.

If training is in scope then we will provide the material for this story and add it to the overall training guides being produced.

When you are happy the story moves into the Completed column.

Completing the user story

Once you are happy the system delivers the goal of the user story we will deliver it into your production system and you can start using it straight away!

Sometimes a user story may not be very useful on it’s own and we may have wait for other stories to be completed before you can start to receive benefits from the system.

After we put it into production the story gets moved one last time in final Delivered column.

And Around we go again

Agile is an iterative delivery methodology, which means we keep repeating the same process again and again until you have a system that meets your business needs.

As we move tasks out of the “Ready to Start” column it is your job to decide what happens next. We may have user stories ready to go so we will jump straight into implementation for these. On the other hand we may still need to expand an Epic and dig in and write more user stories.

What happens next is up to you!

Limiting the Work In Progress

Way back at the beginning of this article we mentioned that we limit the amount of work in progress. This is a key principle of the Kanban approach.

Let’s see how this works in practice with an example:

We have set a work in progress limit of 3 in the “In Progress” column and 5 in the “Ready for Test” column. If we have finished the 3 stories in the build phase but there’s 5 things already in “Ready for Test” it means we cannot move our story into the next column. Since we already have 3 “In Progress” we are also unable to move anything from “Ready to Start”. This means we have to clear something from “Ready for Test” before anymore work can commence.

One of the key principles of Agile is to deliver functioning software regularly. These limits ensure that we focus on delivering all the way through the process. We don’t want to start more work than the whole team can handle so it puts the emphasis on completing work.

Another benefit is that we have a clear picture of our process and where any issues may be allowing us to improve over the life of the project.

The actual limits we place in each stage will depend on the size of the team and the estimated size of the story. It may also change over the life of the project as we get a better understanding of the flow of work through the team.

Change Management

Change Management in an any project follows the same steps no matter which methodology you use.

Check out the overview of change management in our initial article in this series.

The biggest difference in an Agile project is that changes are being delivered continuously into your production systems. Which will involve a higher level of engagement from the impacted staff.

Your involvement in the Agile ERP project

Hopefully by now you have a better understanding of how an Agile project runs.

It should also be quite obvious that you (or someone you nominate) must be actively involved throughout the entire project. From helping to write user stories through to testing the delivered software you have to make decisions about the product that is being built.

Note that this doesn’t have to be a full time commitment from you. The beauty of Kanban and setting the work in progress limits is that we can set the number to achieve the pace of delivery that suits you and your availability.

A final thought

We have seen a number of projects that have started out with a vision of the software working a specific way but as the customer has used the software they completely changed the solution. At the end of the project looking back at what they originally described and comparing what they ended up with something vastly different. The solution they received using Agile was more efficient and even took less time overall.

Our recommendation on who should consider an Agile ERP project

If you answer yes to two or more of these then you may want to consider agile:

  • Are you unsure of exactly what you need the system to do?
  • Do you have pain points that could benefit from early delivery of working software?
  • Are your business processes unclear or not formally defined?
  • Are you excited to be actively involved in all decisions about the system to be delivered?
  • You hate the idea of having to review and sign off a lot of documentation.

Are you looking to get more information about what an ERP implementation in your business would look like? Use the form below to get in touch with us and we will be more than happy to talk.

Leave a Comment

Your email address will not be published.