In 2020, I had the pleasure of speaking at the first digital version of SolidusConf. It was also my first SolidusConf as a member of Solidus’s Core Team. I’d been a contributor to the project since before the fork from Spree was publicly announced, but when I started Super Good I was able to dedicate more time to managing the open-source project and that quickly landed me a seat on the Core Team.

In my talk I discussed what Agile is and how we can use something called the the Agile Fluency Model to help refine our team’s approach to software development to get the benefits of this style of development.

Solidus provides better support for Agile software development than any other eCommerce platform out there. It builds on the Ruby on Rails ecosystem to allow you to develop your application test-first, leverage Continuous Integration (CI) and Continuous Deployment (CD), and iteratively deliver features.

If you make the most of this, you’ll get the features you’re building in front of your customers faster. In eCommerce, that has a real affect on your bottom line. Your optimizations start driving conversions immediately, and if a feature doesn’t have the desired impact, you can quickly redirect your efforts.

One of the tricky parts of Agile software development is that the values of the Agile Manifesto don’t provide any framework for implementation. The original co-signers all had different vision of how to do Agile software development. These ranged from process like Scrum to Kanban to (my favourite) Extreme Programming, to name a few.

The Agile Fluency Model

That’s where the Agile Fluency Model comes in. It provides a way for teams to evaluate their development processes and find what areas to focus on to help improve those processes in the most impactful way. The model outlines four zones that teams progress through as they hone their approach to software development.

The first zone is called “Focusing”. That’s where you are if your team is focused on delivering business value and addressing customer needs. There’s no point in moving faster if you aren’t working on the right things. That’s why this is the first zone.

The second area is “Delivering”. This is where you master the technical practices associated with iteratively delivering that value. Here is where you work to shorten lead times, address technical hurdles, and help the team ship work in step with business needs.

Third is “Optimizing”. Here you’re further empowering your team to help make decisions and act independently in the interests of the business. This often requires a structural shift in the team’s relationship to the broader organization and buy-in from leadership.

The final zone is “Strengthening”, in which teams are able to take initiative to improve the broader organization through their work.

Agile in eCommerce

So, how does this all apply to eCommerce? Projects in the eCommerce space have a lot in common. You’ve got customers who you want to make purchases on your site (and hopefully they want to make those purchases too.) You’re typically trying to drive some very measurable metrics like AOV, RPR, and conversion rate.

You’ve also probably got customer service, merchandisers, marketers, fulfillment, and other users internal to your organization. All these different users have different needs, goals, and ways they interact with your eCommerce application.

You can build tools and features to benefit each group. Larger organizations often see huge benefits from automations that reduce manual work performed by internal team members, but at the end of the day, it’s the external customers who are the reason the business exists. It’s important to find ways to weigh and prioritize work that impacts each group.

Focusing

This zone is where you work to make sure that you’re working on impactful work for the business. If you’re doing Scrum, or Kanban, or the non-technical parts of XP, you may already have fluency in this zone. Most popular planning frameworks help very directly with focusing.

If you’re succeeding at this zone, it’s usually easy to tell. Are you being transparent with your stakeholders about what’s being worked on and how it’s progressing? Are the things that you’re working on actually valuable to your stakeholders? If so, then you’re probably doing okay.

Established eCommerce companies or retail brands branching into eCommerce sometimes view the software team as a necessary evil, a cost of doing business that they have to pay to sell things on the Internet. This can lead to organizations throwing requirements over the wall to the software team.

Getting to the point where you’re actually collaborating with your stakeholders in those organizations can be tricky. First, you need to figure out who your stakeholders are. Just because someone is requesting a feature from your team, doesn’t mean that person is the source of that feature request. You may need to do some exploration to learn who owns which streams of work or priorities.

Once you’ve established who you need to collaborate with you can implement your preferred off-the-shelf Agile process, like Scrum, Kanban, or the non-technical parts of XP. (Pro Tip: Do XP.) Now you can work to improve that collaboration, look at what’s getting worked on, and weight that against the organization’s broader priorities.

You should be able to demonstrate the benefits directly to your stakeholders too. There should be fewer misunderstandings, because you’re working directly with stakeholders. The engineering team should be able to make suggestions about how to solve problems, since they are exposed to the reasoning behind requests. Finally, the stakeholders should be able to intervene if the team is headed the wrong direction.

If you can get these fundamentals locked in, you have the first piece of a really successful development process.

Delivering

Delivering is where teams learn not just to focus on the right work, but on how they deliver that work. The goal here is low defect rates and high productivity. Who doesn’t want that? The goal is to ship work at a cadence that makes sense for the business. Teams that are proficient at Delivering differentiate themselves from teams that are merely proficient at Focusing by being able to ship features at will.

Proficiency here involves mastering a number of technical skills. Fortunately, Extreme Programming gives us a pretty good framework for these skills. If you’re fluent in Delivering, you’re going to need Continuous Integration. There’s no way to get to the point where changes can be shipped quickly unless you have solid acceptance tests and are integrating your regularly.

In order to lower risk and increase the confidence you have in releasing changes, you almost certainly need to be doing something like TDD or at least have a rigorous testing approach. It’s not feasible to manually validate every change if you want to move quickly. Manual verification is often necessary for certain things, but you can’t be manually verifying anything that an automated test could instead. Save manual verification for things the computer can’t verify.

You also need to be really diligent about refactoring the system. As requirements evolve and grow more complex, different parts of the system may drift and become out-of-sync with each other. If you want to be able to continuously make changes, you need to make sure the system says consistent and congruent.

Besides XP, you’ll also want to steal techniques from the DevOps movement. Continuous Delivery is a big one. You’ll want to use techniques like feature flags to help merge and deploy features and have them ready to go when the business needs them.

From a technical perspective, most of these approaches are the defaults with Solidus. Your store comes with a suite of tests and is ready to deploy to platforms that support frequent deploys. Out of the box, you’re ready take advantage of this within your team.

The trick is that simply doing these things isn’t enough. You need to be good at them. You need to stop working with long-lived feature branches and other similar practices that stand in the way of proficiency in this zone.

Building these skills takes time. You can’t just drop in the practices and instantly reap the benefits. Fortunately, these techniques pair really well with eCommerce. Not all software projects can support lots and lots of changes per day for fear of alienating their users.

The transactional nature of eCommerce means that’s much less of an issue. I wouldn’t start moving your cart button around every day, but the average user won’t even notice iterative improvements to your storefront. For most stores, it’s safe to deliver features as fast as you can build them. It’s up to the business when to launch them.

Code Review is another skill that you need to invest in, and that means more than having someone take a quick glance at code and approve it. It means learning how to structure PRs and commits to make them easier to review. It means soliciting and giving relevant kinds of feedback.

TDD and testing are a whole constellation of skills that relate to each other and all contribute to this proficiency. Continuous Integration is a skill. It means more than just having a CI server validating your changes. Feature flagging is a skill. You need to learn what can be feature flagged and when it should be. There’s overhead to feature flagging and you need to build the infrastructure to support it and learn when to use it. Finally, refactoring is it’s own domain, but aggressive refactoring takes time to master and learn when to use.

Optimizing

Optimizing is the really hard part. This is the big differentiator for a lot of teams. If you are proficient here, then you are actually getting the supposed benefits of Agile. This means higher value deliveries and better product decisions. It’s about knowing what your market and business need and achieving that. It is way harder to achieve in eCommerce than the previous two zones.

The Agile Fluency Project puts it like this:

The distinction between an Optimizing team and a Delivering team is that the Optimizing team makes its own decisions about what to fund and where to focus their efforts.

In eCommerce, you’ve got all these different internal needs pulling you every direction, you still need to keep the customers in mind, and succeeding here is going to require a lot of trust between the engineering team and the rest of the organization. That level of trust has to be built up through the other zones.

If you’re going to succeed in eCommerce, you need your team to be working in sync with the other parts of the organization. I’ve encountered teams that were responsible for the bounce rate of certain landing pages, but they weren’t able to collaborate with the marketing team that managed them. They saw the bounce rate tank, but they had no technical solution because the marketing team had just sent a ton of unqualified traffic to those pages. These are the kinds of disconnects that need to be addressed to create proficiency here.

Fixing these kinds of problems typically requires actual structural change within organizations. Working from the outside as a consultant like myself, it’s relatively easy to achieve the first two zones. The broader organization needs to be on board for you to have any hope of achieving proficiency here.

Typically this involves integrating the engineering team into the other parts of the organization that they are impacting. This almost necessarily leads to better decision-making. This accelerates your ability to cancel low-value projects. Higher-value projects are much easier to identify and prioritize. It improves the whole organizations ability to evaluate and prioritize work.

Because the engineering team is at the centre of all these these different parts of the organization, they need to be given more autonomy. This can create pushback in many organizations.

We have no shortage of metrics in eCommerce and can try to use them to help smooth out this process, but it can be difficult to measure a potential change in conversion rate against some kind of fulfillment optimization.

The most important way to overcome pushback in your organization is to show off your wins. Keep an eye on where you’re benefiting from these structural changes and make sure that everyone knows about them. If stakeholders don’t see the value in the changes you’re making, they won’t see them as worth the effort.

Strengthening

The final zone is where teams find ways to strengthen their organization and make it more successful. I’ve seen teams that are able to do that, but this is the bleeding edge of Agile. I’m not going to lie and claim I know exactly how this fits into eCommerce. It’s going to take more time with more teams in this space to flesh out how to consistently succeed here.

Beware of Bad Investments

This model provides a way to look at what your team is doing and find where to invest in your process to have the biggest impact. The zones build on each other for a reason. Don’t ignore that.

If you haven’t mastered Focusing and get sign-off to spend a ton of effort getting your CI/CD infrastructure in place, you’re going to undermine trust in your team. Stakeholders don’t care how fast you can deliver features if they aren’t the features they want. You need that trust to succeed overall.

As you iterate on your process, you need to continuously evaluate where you’re investing, what benefits you’re seeing, and adjust as you go. In a way, you need to be Agile about your Agile process.

Solidus is Perfect for Agile

I don’t think there’s another platform that works as well as Solidus does for building a high-velocity, Agile eCommerce team. If you are comfortable with the processes and techniques above, then you should be implementing them out of the gate on your Solidus projects.

Solidus is designed specifically to support all of these practices. The biggest mistake you can make with Solidus (or any custom eCommerce platform) is to fail to capitalize on its strengths.