Well…it actually can make very much sense if you have the building blocks needed in place. … You might also need some magic.
So, what is needed?
H: The customer has a clear and realistic business case – they know what they want to achieve with the program. No wishful thinking.
O: The project owner comes from the business. You need resources from the business side, and the business management can give those to the project, not IT.
C: During the discovery phase, the business case and other requirements from the organization are transformed into user stories with different priorities (MoSCoW method) – must haves, nice to haves…. Plan it so that delivering the “must have” user stories means that the business case will be realized. This helps in maintaining your focus and doing prioritization.
U: On both sides, there are competent and motivated business and solution leads that are capable of distributing the work to other team members effectively after the Sprint planning sessions, and who have continuous dialogue with different stakeholders of the program. Teams are self-guided within their own scope.
S: Naturally, we need a strong and experienced Scrum Master who will master the entirety and give continuous coaching to the project teams members, shoot down unrealistic thoughts in the Sprint planning, and drive continuous improvements to the program through the lessons learned in the Sprint retrospectives.
P: Project managers (on both sides) whose main tasks are making sure that project team members can allocate their time to the project (basic stuff), being active and proactive on cost control, and prioritizing tasks when budget limitations emerge. Special attention should be paid to risk management practices. When you are delivering the project in two week Sprints, you don’t have the luxury of using the “let’s wait and see” approach. You have to do risk mitigation 24/7. If you see a red flag being raised, you are late. How do you do it? Open communication is the key success factor. It also helps if the project managers have a suspicious personality.
O: Proper and active use of common tools (e.g. JIRA, Confluence, MS Teams…) is a must. There is no shortcuts. It helps if the customers have used the tools before. If not, arrange sufficient training BEFORE you start the project.
C: Focus on Sprint execution and aim for steady progress. Typically the Sprint progress curve looks like a hockey stick followed by hangover/coma/start of a new sales quarter. When the deadline starts to be close, the intensity rises and things are moving on the Jira table very fast till the bell rings. A new Sprint starts and people are exhausted or busy with other tasks. Days go by and things are moving slowly. The deadline is starting to get closer and people start to walk faster and eventually start to run – here we go again…GOAL! Naturally, more steady progress would be good, also for project manager’s health. Good Sprint planning and proper resource allocations might be the cure for this. Or not.
U: Visibility to project progress both on a detailed and overall levels is crucial from the project steering point of view. Burnout charts, situation with “MUST HAVEs”, calendar view of backlog item updates etc. should be available through a single user interface – you can see the overall situation at a glance.
S: Communication is the key. Constant communication in and between the teams ensures that everybody knows what is happening now and next. If this, also informal, information flow stops, we have a big problem.
Managing an ERP project with agile methods is not a walk in the park nor piece of cake. You have to be awake all the time. Every Sprint counts.
The above mentioned thoughts have a loose connection with a program where ERP, CRM and eCommerce platforms with integrations needed are implemented using Scrum.
