How to rescue an Adobe Commerce build

In summary
  • You have options. Exercise those before “giving up” on your agency. Switching to a different agency will bring additional billing as the new team comes up to speed.
  • Get involved with the project. Hoping a challenging task will get done by itself doesn’t work.
  • Take control of the flailing pieces. Understand what is happening and master how these affect your operation.
  • Ensure you are 100% in sync with your agency. Regular communications will make (versus break) the project.
  • Do everything you can to pull back the scope of the project. It’s better to disable modules or rip out functionality than go for the stars and never get the project launched.
  • Get a second opinion from a trusted provider.

Are you a merchant? Is your Adobe Commerce build not going well? The ship is listing badly, and you are tasked with getting this project back on the right track.

This article details how to accomplish this and make yourself MVP of the year at your organization.

Let me start by saying that Adobe Commerce is an excellent and powerful platform. There is nothing outside the purview of its capabilities. The system is 100% “open source,” which means you can modify anything. This opens our conversation.

You can modify anything in Adobe Commerce. There is no customization that extends the reach of this platform. You can change anything. Do you get the message?

This is one of the great selling points. Service providers sell this platform stating that the sky is the limit. When they get down to delivering “the sky,” they don’t do it with the methodology necessary for a significant software project. The results are catastrophic.

The scope: this article relates to new builds or migrations to the Adobe Commerce platform. However, it’s also applicable to long-term maintenance engagements. And it has widespread recognition with other ecommerce platforms.

You might be facing a job crisis—and it’s not your fault. Delays smash deadlines. The project costs balloon, and the website is never released. Adobe Commerce looks terrible (“I was responsible for releasing our Shopify Plus site in 30 days”). Everyone is frustrated.

This conversation is for you if you find yourself in such a situation. Many merchants have found themselves in a similar case, if it's any comfort.

Get involved

You must designate a champion or product owner. If that’s you, I’m sorry. If there is no champion, establish one quickly. This person has the responsibility to push forward.

No one is perfect. Neither is an agency nor a merchant. Accept responsibility for the state of the project and look critically at what happened. More often, merchants trust the agency too much and don’t properly flesh out the project requirements or own this project as their own. As the merchant, you have enough on your plate to hope for a company that autonomously builds the exact solution you want. It doesn’t work like that.

The reality is that the agency gets in too deep, and the merchant comes to the point of thinking, “this isn’t what we need.”

Take control of the situation

Focus on critical issues. Come up with a checklist of items that prevent launch. Sync with your agency on this list. Defer any item that can wait. Keep this list in front of your team and your agency (see the next topic of Establish Regular Communication).

Many builds are completed for a fixed fee. If the agency isn’t pushing change orders, their developers are likely to get burned out as they revisit the same problem repeatedly. Options for improving this project are minimal and may involve switching to a new service provider.

If this project is being billed on a time/material basis, identify whether you are more interested in a faster completion or a consistent budget. There is “X” number of hours to get this completed. A better team should be fewer hours. A less competent team is more.

You can establish monthly limits. You could also request bi-weekly budget updates.

Establish regular communication

We have found that face-to-face meetings consistently are critical. Daily. Twice a week. Whatever it is will significantly help to ensure you are in sync concerning priorities.

I believe the most significant cause for frustration is that merchant/agency priorities are out of sync. The agency completes tasks in the order that the merchant is not expecting or wanting. Just because the project started with initial priorities doesn’t mean they remain constant.

Pull back the scope

Ray Bogman at Adobe has an excellent line of thinking:

As an Adobe Commerce Business partitioner, it would be best to follow as much as possible the 80/20 rules for implementations. Use 80% Adobe Commerce core functionally and 20% bespoke. The more bespoke the higher TCO (maintenance, upgrades) will be. And will lead to slower time2market. True this may not always be possible, but keep it as close as possible to the 80/20.

If you choose to massively customize your instance, no matter what platform, you will encounter problems associated with custom code (technical debt).

A significant reason for failed projects is bloat. You, the merchant, have asked for too much to be delivered on the initial round. More often than not, features are more negotiable than you would think. Think critically about what can be immediately omitted and pushed to version 2.

There are some cases where the minimum viable project is significant. We worked with Grandstand Glass to facilitate a workflow that involved pricing complexities, artwork workflow, and approval queues. There is only so much you can cut back when you are 75% of the way through the project.

Starting right from the beginning is the best, but it’s not always possible.

Ensure excellent documentation

It is within your power and best interest to ensure every single ticket contains proper information.

If you can hold off until you have 2-3 reoccurrences of a problem, you will save a significant amount of budget. We have chased many 1-timers to find out they are already fixed or not a problem after all.

Bugs
  • Precise details of what happened. A video recording, evidence of problems, etc. The more you provide the less time the developer will have to spend.
  • Exactly when this happened. The closer to the accurate timestamp, the easier this is to triangulate in the logs.

New features
  • A straightforward user story: What efficiency are you seeking to gain? What problem are you solving? How will this help you, the customer, or some other system?
  • Acceptance criteria: How do you know when this task is complete? What critical tests can your QA complete to verify that this piece is functioning as expected?
  • If this involves UI changes, ensure some mockups contain rough diagrams of how the workflow should occur.

Keep a record of the problems

You’ve probably had numerous instances of playing whack-a-mole. This is frustrating as once you fix a problem, you experience a reversion.

Being familiar with the project (and fixes) is critical. Chime in with your gut feelings as to what is happening. Some people might take “offense” at a “non-developer” providing advice—but a good developer will appreciate this.

Your record doesn’t have to be a list of Jira tickets. It may be a text document detailing significant problems and their resolutions.

Push back to ensure the root cause is resolved

This comes back to the game of “whack-a-mole.” When an issue repeatedly arises, you observe a sure sign that the root problem is not dealt with.

Request that your development team looks into the root cause of this problem. Remember that there is nothing random in computer science. There is a reason, and it is up to the developer to identify this problem.

Consider a second opinion.

If you can’t get this project under control, look to get a second opinion. This should comprehensively audit the code base and UI/UX.

The audit should cover:

  • Modules installed and their current version
  • The quality of custom code. Does this match or exceed Magento coding standards?
  • The frequency of critical code smells. Is ObjectManager in templates or code (excluding factories)? How many preferences exist in di.xml files? Is the code formatted and documented cleanly?
  • The structure of the customizations.

This audit will make the unknown known. At this point, you will understand the quality of your developer output and will be able to make appropriate decisions going forward.

Note that audits do increase a merchant’s alert level and they may start the process of parting ways when they find out. Take your time to investigate the agency providing the audit in case they need to finish the project.

Call in a rescue mission

There is a time for everything. If you have tried all of the above, it may be time to consider a new service provider.

When you do, I recommend you evaluate:

  • What is their percentage of certified developers? Is it possible to find one that’s 100%? For the record, SwiftOtter maintains a 100% certified bench of developers.
  • Can they assure you they have the experience to approach a new codebase and resolve problems?
  • What are some of the biggest challenges they have resolved? Are any of these similar to your situation?

About us

I write this article from an agency’s perspective, having seen many merchants floundering. When the website finally gets to production, it’s marred by bugs. This causes the merchant to believe the problem is Adobe Commerce—when, in reality, it’s more a management and agency problem. We have righted quite a few projects. If you’re interested in an audit or second option, I'm happy to chat.

Get in touch
circled-checkbox
We have experience in turning these projects around. We wish we didn't have to do this, but at least we are good at it.
SwiftOtter, Inc.
It relates to Magento 2, Project management and Quality Assurance.
Joseph Maxwell - president / senior developer at Swift Otter

President / senior developer at SwiftOtter - @swiftotter_joe