Part of the “Agile ERP” series
Software is changing the face of business today, and the speed at which your business can innovate will often be determined by the speed at which software can change.
Of course, the same applies to your competitors: Whoever can manage change and deliver value most efficiently will have the commercial edge. Applying lean and agile principles will optimize application development processes and remove waste.
But it’s not just customer-facing “systems of engagement” like websites that need to be changed quickly. In the digital age, all applications need to be delivered faster – including those in your ERP suite.
I’ve already looked at why you should adopt agile for ERP and some of the objections that may need to be overcome. In this article, I’m going to suggest some steps you can take to get started so that ERP development can be as responsive as the business needs it to be.
1. Understand what agile is
This might sound obvious, but it’s important to understand that agile is not waterfall.
Waterfall ERP projects are typically pre-planned with solutions designed upfront. They are then delivered via a structured series of steps from development through testing, regression, and release.
A key difference between agile and waterfall is that with agile, possible problems and associated solutions are not necessarily well understood or documented upfront. Agile breaks projects up into smaller chunks that can be delivered in shorter iterations called sprints rather than attempting to solve everything at once. This might seem counterintuitive in ERP, where things are often documented to a very detailed level before any work starts.
In agile, we have to learn to accept uncertainty and the fact that solutions evolve. Problems are managed as part of the process. The fact that we’re not tied to a spec allows us to question and adapt as we go, so the risk that we deliver the wrong thing is dramatically reduced.
2. Work out who your stakeholders are
Not everyone is going to think agile is a good idea and support it. In fact, in ERP, there are many who will happily find many reasons not to do it.
So you need to look at who in the organization will be impacted and make sure to involve them in the process. Exec management, business owners, development, and testing teams all need to be included. There will be people who you can rely on for support, and there will be people you can expect to derail you. Understanding who these people are from day one will help you no end. People need to understand what agile means for them and what benefits and changes they can expect to see.
Some realism is also required. People may be expecting a “silver bullet” that will cure all the problems with the current processes, and they may quickly become disillusioned if this is not achieved. So you need to manage expectations and help people understand that adopting agile is a journey. In ERP projects, I’ve seen most success where there are champions in both management and project teams to help get the message over and smooth out the inevitable bumps on that journey.
And once you’ve chosen a framework – for example, Scrum – it’s a great idea to run some training courses on the methodology and process so everyone understands how it’s going to work. The training should not be onerous. A couple of days should be enough.
3. Build a business case
Before you embark on an agile transformation, it’s important to understand what benefits it can bring so you can convince the powers that be that the idea is actually worth looking at.
Applications need to deliver business value quickly to promote innovation and increase competitiveness. Agile enables ERP to do this and also brings responsiveness to change.
I recently wrote some advice on this topic for the kind of SAP users we work with, but regardless of your specific ERP platform, you’ll want to ask questions like:
- What does it cost to deliver applications now?
- How much would it cost to delay application delivery?
- What’s the cost to respond when a competitor takes market share because they got there first?
- How much could faster delivery translate in revenue terms?
- What is the current cost of application failure and downtime?
- How much do you spend on application development and testing?
- How much waste is present, for example, in reworks, where time is spent constantly testing and fixing?
Looking at historical data and timesheet bookings will help you to evaluate the time and cost of development and testing activity. You can expect an agile approach to reduce development cycles, improve quality and stability, add efficiency to the application delivery process, and provide greater collaboration and feedback.
An agile transition is not without cost, but even conservative estimates on improvements can become a compelling business case to get started.
4. Start small
You can’t expect to switch over to agile processes overnight and assume that everyone will be able to instantly adapt to new ways of working. Many of the companies we work with that have had success with agile started on something small and safe in order to learn and prove the process.
It’s OK to make mistakes, try different approaches, and work out what works and what doesn’t as you go along. Although agile is a common approach, it will be applied slightly differently in every organization. Learn what works best for your specific teams.
A good recipe for adoption in ERP is to start out with one team as a nucleus, then branch out to others when you’ve got it nailed. When you can demonstrate success, you can scale it to other teams to get them on board too.
5. Reorganize teams around projects and products
Traditionally in ERP, we are used to handing over requirements to development, who then hand over to test teams, and then cycle around various other teams in an attempt to deliver what was asked for.
Agile requires that we address how teams are structured and interact with each other. As there’s not a detailed spec to work from, you’ll need to have very open communication channels between team members, and you’re going to need trust. Ideally, you’ll want development and testing to work as one, with a business representative overseeing things as a product owner/manager. Successful adoption of agile in ERP is often seen in the form of many smaller, multifunctional teams working together to deliver specific related requirements.
For fixes and smaller enhancements, this can work very well indeed, as they can be delivered much faster and with more flexibility. It works for larger projects too. Regardless of the fact that a program may be delivered as a whole at some point in the future, there’s still a strong case for smaller units of delivery that enable the business to see results sooner.
6. Create a prioritized backlog
Agile focuses on business outcomes and working solutions, where a backlog of requirements is created in the form of user stories for specific personas.
This backlog should be prioritized so that stories that produce the most business benefit are addressed first. That means you need to look at what’s most important and what the dependencies are between requirements.
In ERP, due to the high level of integration between modules and processes, the management of dependencies is particularly important to help you understand what can be delivered independently, and what needs to go together. It’s also important to make user stories manageable so that they represent smaller, discrete portions of work.
The product owner needs to learn how to do this.
The backlog is not something that should ever be set in stone, though. Agile provides the flexibility to adjust priorities and support scope changes, making them much easier to manage.
In ERP projects, it’s a huge benefit to be able to respond to changes in priority and scope as you go along, rather than having a design and blueprint that’s fixed and won’t be delivered for many months. In each iteration, it’s important that testing is a key part of the process so you can aim to deliver something tangible at the end.
7. Organize some sprint meetings
Agile promotes constant feedback so everyone understands what’s going on and where gentle redirection may be required. Team members need to attend sprint planning sessions so that everyone understands what’s wanted and can estimate the effort required. Timebox them to an hour or two to keep people focused. Short daily stand-ups need to be run so that everyone can report on progress and highlight issues and blockers. Keep it short (10-15 minutes) and don’t try to solve problems in them.
After a sprint is finished, you’ll need to have a retrospective session to review what was done (or not) and to look at areas for improvement. It’s really important to use this to improve and evolve the process. Playback sessions can also be used to present what’s been built to the organization. This is an important feedback loop and an opportunity to demonstrate achievements.
During this process, it’s important to acknowledge that not everyone will be comfortable being in the spotlight or enthusiastic about changing. You’ll need to understand the personalities involved and ensure that everyone is supported. Ultimately, this constant communication ensures that the business gets what they wanted – even though at the start they might not have known exactly what that was.
8. Choose some automation
The simple fact is that if you want to be successful with agile, you’ll need some tools to help you manage the process. This might start off as a big whiteboard and a selection of sticky notes to represent each user story. You can then physically move them around the board as they progress. This highly visible approach is great to start with, as suddenly everyone can see exactly what’s happening. When your process is more mature, dedicated tools like Jira can be used to manage the process and provide the required workflows and reporting.
But you also need to think about ERP itself and how you’re going to manage all those transports. A mature change tool that can manage and automate transports and ensure that dependencies are handled correctly is a must for larger ERP projects.
It takes time to adopt and trust agile processes. In my experience, it can take at least a year to embed the process and cultural changes needed to make agile really successful. But the high levels of engagement, transparency, flexibility, and responsiveness are hard to argue against.
If you’re looking to get started but are meeting people who put barriers up and say it can’t be done, take a look this e-book on some of the most common misconceptions about agile for ERP and how you can start to challenge them.
This article originally appeared on the Basis Technologies blog. This adapted version is republished by permission. Basis Technologies is an SAP silver partner.