Agile vs Waterfall for ERP Implementations • Everyone is Wrong

Every now and then, I’ll see the ol’ LinkedIn argument about whether Agile or Waterfall methodology is better for ERP. It goes something like this in the comments:

The Fatal Flaw in the Typical Argument

💡 An ERP implementation isn’t one project. It is 3-10 projects run in parallel.

The methodology should be specific to each subproject. Therefore, a combination of EVERY methodology can be used within a single ERP project.

And there are more methodologies than Agile and Waterfall!

The ~Ten Projects

What are the supposed ten projects?

• Functional Architecture
• Process Design, Configuration, and Testing
• Business Processes Reengineering and Change Management
• Technical Architecture
• Development, Customizations, and Add-ins
• Integrations with Internal Databases or External Systems
• Data Migration from Legacy Systems and Cutover
• Data Warehousing, Reporting, and BI
• Environments, Cloud, Hardware, Device Procurement, and Licensing
• Security
• Documentation, End User Training, and Rollout

Depending on the size of project and business, you may combine some of these and not require others. That’s why it’s a range of 3-10 projects.

Microsoft has a website dedicated to learning more about these areas of a project, called “Success by Design”. Microsoft’s structure is a bit different, but the core concepts are similar.

https://learn.microsoft.com/en-us/dynamics365/guidance/overview

Useful ERP Subproject Methodologies

• Waterfall: A linear and sequential approach where each phase must be completed before the next one begins. Ideal for projects with well-defined requirements and no expected changes.
• Agile: A flexible methodology that emphasizes iterative development, customer collaboration, and the ability to adapt to changes quickly. It focuses on delivering small, incremental improvements.
• Iterative: Focuses on developing and improving the project through repeated cycles (iterations), allowing for incremental refinement of the system over time.
• Just-In-Time (JIT): Emphasizes efficiency and flexibility by initiating tasks only as they become necessary, reducing idle resources and responding dynamically to demands.

-Chatty G 4.0 Feb 3, 2024

How is Anyone Supposed to Manage All This?

It’s hard. Managing one project is hard – managing ten projects at once with four different methodologies is some kind of masochism.

There has to be a component of the project that is a big picture function of time – Milestones. The point of milestones is NOT to:

• Bludgeon employees and consultants that things are “late”.
• Pick some arbitrary date well into the future and say, “All 10 projects are going to line up perfectly here!”

💡 The point of project Milestones is to periodically synchronize work from all 3-10 subprojects and demonstrate how the overall implementation is coalescing.

Naming these milestones might be helpful for some projects. Conceptually it’s easier to think about blocks of time. Depending on the size, staffing levels, and complexity of the ERP implementation, normal blocks might be 2, 4, 6, or 8 weeks.

Names of Phases

Each Methodology has its own style of naming phases.

Waterfall: Discover, Design, Develop, Test, Train, Rollout

Agile: Initial Requirements, Prioritized List, Go-live

Iterative: Iteration 1, Iteration 2, Iteration 3, UAT, Training, Support

Just-In-Time: I have no idea. Star Trek TNG characters? Picard, La Forge, Data, Worf, Troi, Riker

Over Budget Clusterfuck: Kickoff, Go-live.

Phase naming is kind of irrelevant. Use one, use them all, I don’t care. It’s somewhat helpful for figuring out what needs to be accomplished at a roadmap level by the next milestone.

⚠️ However, at a big picture level saying “we are in this phase” confuses the hell out of everyone. “We are at the end of the Development phase and we have some additional things to develop in the Test phase.” 😐

The Idea in Pictures

Here’s a spreadsheet showing different methodologies and subprojects in a Roadmap view.

This file is open source under the MIT License.

“My ERP Implementation is Smaller and Definitely Waterfall”

Agreed!

💡 Any sufficiently small project or task can be broken down into a Waterfall style flow of Requirements, Development, Testing, and Deployment.

Waterfall is the most intuitive methodology because we’ve all experienced it at some level. However, Waterfall doesn’t scale with complexity. There are unknowable topics that require prototyping, feedback, and experience. Requirements fluctuate. Priorities change.

Task Tracking

Every methodology requires a different style of tool for tracking individual tasks. I would advocate for a roadmap being the comprehensive plan. Each methodology is going to have its own favorite tool.

Staying in the Microsoft world, some good tools might be:

Waterfall: Microsoft Project for Web; dependencies can be defined between tasks.
https://www.microsoft.com/en-us/microsoft-365/project/project-plan-3

Iterative: Azure DevOps; User Stories can go into each Iteration or re-assigned to the next iteration where appropriate. (No one can “Sprint” week after week and month after month. “Iterations” are better.)
https://learn.microsoft.com/en-us/azure/devops/boards/sprints/task-board?view=azure-devops

Agile: Azure DevOps; User Stories can be stack ranked by priority. Note that Agile and Iterative don’t have the same tracking requirements, so a single DevOps project may not be appropriate.
https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview?view=azure-devops#backlog-priority-or-stack-rank-order

Just-In-Time: Anything with task tracking.

Reporting: Power Query or Power BI. At a subproject level, the individual tool is probably enough. At a comprehensive ERP Implementation level, Power Query can summarize data from multiple tools or even Tenants into one place.

Why Does Joel Care?

At Cooptimize (https://cooptimize.org/) we do (actual) Agile development. We manage a prioritized list and work through it as fast as we can.

For data projects, managing estimates or due dates at a User Story level is nonsensical. That’s not how Agile delivery works and it’s not how data projects work. Instead, the feedback is based on priorities and progress.

We still need checkpoints when collaborating as part of a larger project. That’s why I care – because we are not in the driver’s seat for defining Milestones (nor should we be). We want to understand the next Milestone so we can validate our priorities, fit into the big picture schedule, and communicate what we expect to accomplish.

We also need constraints based on our clients’ budget. Data work isn’t a one-time project, it’s ongoing. We constrain the amount by putting together a Fractional Data Team. This team (or person) works for a client on the same day(s) every week (Focus Time™️).
https://cooptimize.org/pricing/

Our approach gives us the freedom to actually be agile. We avoid wasting time on entering timesheets, reconciling budgets, writing detailed but vague contracts with “buckets of hours”, and needing project managers to coordinate our work. We have the freedom to do Quality work without worrying about whether it was pre-approved. We automate whatever we can because more automation means we can deliver more value without impacting our Revenue.

“This is So Brilliant; We Admit We Were Wrong; Change Incoming Immediately!”

😂 I doubt it. It took me far too long in life to realize that a logical approach <> change happening. I do hope it provides some context for what makes ERP Implementations challenging.

And now I can respond to the Great LinkedIn Waterfall-Agile Wars with something that will definitely end the fighting. Go in peace. With the WaterGileIteraTime (©) Methodology!