We’ve all heard of the famous giant projects intended to replace a technology in one big bang. Many industries have learned those lessons the hard way about how these years long projects can stretch on and on and never deliver anything. 2 quarters becomes a year, then one more quarter, and pretty soon you haven’t delivered that replatform a year and a half later.

This article isn’t really for the agencies and tech native companies, this is for the merchants, the brand side. If this is you, or you’ve seen this in your career before, this article is for you.

What causes this?

In one sentence… Too much scope for an initial release, and unwillingness to change processes.

It’s easy to define the root causes, and when I say them they may feel obvious. However, the solution may feel less obvious to companies that aren’t inherently tech companies.

The temptation when starting fresh on a platform migration is to solve every single process issue you’ve had over the last 3-5 years (The average merchant stays on an ecommerce platform for 3-5 years once they survive that first year). The second temptation is you’ve been through this at the company for 3-5 years, you know how all of this works. You know what works you know what doesn’t (Or so you think), so you think it should be simple, replicate your existing processes on a new platform.

Accumulation of wants and needs

It’s easy to get taken in by a process in requirements gathering that becomes a laundry list of what features you must have. Whether those are features that replicate existing processes, features that address existing shortcomings, or nice-to-haves.

If you did not have a particular feature on your existing platform before, my recommendation is if your new platform doesn’t have it, don’t make it a prerequisite for your initial launch (if you can commit to an iterative release process).

Ridgid Processes

One of the most important things I’ve learned, and I’ve read is when introducing new technology, if you do not adapt your processes based on that new technology, you’re doomed to replicate existing bottlenecks, problems, and ultimately fail with that new technology. I originally read this in Eliyahu Goldratt’s Beyond the Goal.

Agility

By now, it’s been 25 years since the Agile Manifesto was written. If you’ve been around technology projects for a while you’ve probably heard of agile development. If you’ve been in business for a while you’ve heard of agility. But what does it all mean? How can it help you? And why are you not the exception?

To truly solve these problems you can’t embrace Agile or Scrum or another framework or philosophy as a cargo cult. It’s a both a mindset and a set of processes - the processes without the appropriate mindset and commitment to iteration, commitment to transparency, and commitment to collaboration will guarnatee that adoption of these news processes will just make things worse for you.

Reading the agile manifesto

The agile manifesto is 4 core value pairs. 4 items on the left, 4 items on the right. The items on the left are to be prioritized over the items on the right, but not solely at the expense of the items on the right.

Each organization has unique ways to these things apply, and should apply these principles in ways that make sense and work for them. Highly regulated industries, like pharmaceuticals, for example may need to produce more documentation and do more planning than your average retail organization. Smaller organizations may have fewer rigid processes than larger organizations.

Another way to read it is simply a list from top to bottom of things to value. Individual relationships, working software, customer collaboration, responding to change. Yet another way I’ve thought about it is your team is made up of inviduals trying to deliver software collaboratively, and to do so in such a way that they deal with inevitable changes.

Alistair Cockburn summarized it well, “The heart of agile is Collaborate, Deliver, Reflect, Improve.” Meaning each point in agile is about one or more of those, and successful frameworks for implementing agile have parts that fit into all of the 4.

Individuals over processes

• No process is sacred. Including processes that touch on project management methodologies.
• Practice continuous improvement both in terms of your codebase, yourselves, and your processes.
• Be transparent and vulnerable with eachother. Scrum has something called retrospectives in its list of rituals, many companies skip this. Some companies do it, but consider process improvements sacred. To have a good retrospective nothing must be sacred save for respect for your colleagues and making that meeting a place that’s safe for feedback.

Working software over documentation

Thinking about this from both the top down way and the left to right way… Working software should be prioritized. Deliver something early, let people interact with it, break it, iterate! Your bug reports and feedback, if tracked appropriately then become part of your documentation.

Note - As merchants, we do have a requirement to document our changes, and have a change management process, it’s right in PCI… Section 6.5. That doesn’t necessarily mean that you need to say “Documentation over working software”. But it does mean you have an added, and important requirement.

Customer Collaboration over contract negotiation

This one sounds like it’s purely an agency thing, and it doesn’t apply to internal development teams, or hybrid development teams. But that’s incorrect.

For an ecommerce site, what the agile manifesto is referring to isn’t your customer buying your product, it’s the individual department that has an interest in a particular part of the software. Your site merchants, your marketing department, your accounting department, your customer department to name a few.

What many organizations fail to do is identify the customer for their features. While a well-managed project may have one overall product owner, that person is not “The Customer” for every feature. “The Customer” for the feature should be identified before you get started.

It means don’t get into “Well you said this on this date, therefore that’s what we built.” It means go shadow your colleagues and see how they’re working today. Ask them questions while you observe. That’ll help you define requirements more quickly and clearly than having a conversation in a conference room. If you cannot get the time to shadow, there are tools like Scribe.ai (Which I highly recommend) that people can use to record their processes and document them merely by doing the process and narrating it. It’s both a helpful tool for making SOPs, and a helpful tool for requirements gathering.

Spend less time talking, more time listening and watching, less time arguing.

And like anything else… This can be in tension with our industry’s specific rules and regulations. For example, PCI requires us to have a change management process. Although, in practice, that means while you’re collaborating, write it down in your issue tracking software (You have that right?), make sure your source control references tickets in your issue tracking software, and plan when that’s released.