How to leverage agility in e-commerce

The transparency it creates between the stakeholders minimises friction and frustration, allowing problems to be resolved further upstream and providing the dev team with more independence that, in the long term, makes them more responsible and capable of owning the delivered products.

So, where’s the problem?

Many e-commerce projects suffer from constraints such as a set budget, fixed deadline or rigid list of specifications. In these circumstances, how can the dev team estimate its user stories during sprints if everything is already so set in stone? It goes directly against the principle of business flexibility and risks indirectly leading to a V-model form of project management and thus creating frustration amongst teams. Another common error made by inexperienced teams is the belief that carrying out a project in an ‘Agile manner’ means that everything will go smoothly. In reality, simply saying your running an Agile project doesn’t mean you actually are. It requires a few prerequisites such as engagement and maturity on behalf of all stakeholders; not only those part of the project team, but also anyone else in your ecosystem (upper management, team managers, other teams, etc.).

Does that mean that agile methodology and e-commerce projects are incompatible?

Rest assured that it is entirely possible to use an Agile methodology with e-commerce projects! The first step is to analyse early on, from the kick-off if possible, the possible frictions and find a solution for each one. That might mean one or several people taking part in an Agile training course, writing down the main principles that will guide the production team (independence, transparency, engagement, etc.) or assigning an experienced Scrum Master (if it is a SCRUM) who will be available at the start of the project, if the team thinks they need it.

Great, but what about the list of specifications I have to adhere to?

While it’s true that a dev team needs visibility on the project so they can adapt their work accordingly, let’s not forget that a need expressed at the start of a project is most likely to change as development progresses. A specific need may be refined or, inversely, might be deprioritised or even scrapped. Why not simply provide a loose outline of the need so that everyone has a general idea of the end product, and then wait for this need to be refined naturally and for the project to progress enough before drawing up a list of concrete specifications?

This approach avoids the team taking two steps forward and one step back, which would incur additional costs and delays. When working in an agile manner, you don’t need to precisely and definitively plan out all the functions from the outset — leave some room for the need to evolve. It is also important to note that a developer who spends time on a function, only to see it abandoned a few weeks later by the business team, may feel frustrated and less motivated for future sprints. It’s essential that teams remain motivated and stimulated if the project is to run as smoothly as possible.

I also have a deadline and a budget...

One thing is for sure, the dev team will always be the best placed to estimate the various functions to be developed. The more they talk with the Product Owner, the more independent they will become, honing their estimations and mastering their velocity (production capacity). For the business team, the important part is prioritising the various functions as best as possible. They must sincerely question how necessary each one is for the first version of the end product. Ideally, they should deprioritise the more immature ideas and plan a V2 right from the start, postponing less critical needs until after the release of a functional MVP, or even waiting for feedback from the first version to redesign and adapt functions accordingly. It’s a win-win situation: it saves the dev team time by enabling them to later refine its design, documentation, unit testing, performances, etc. and also ensures a better time-to-market for the client.

My Dev Team/Product Owner don’t understand me

It’s important that for each sprint, everybody knows their role and responsibilities and the responsibilities of the other team members. The dev team must be engaged, transparent and guide the Product Owner when the need manifests itself (writing specs, technical support, testing). For a Product Owner, being the middleman between the business and dev team is not always easy to do for the entire duration of the project. They need to remember that the dev team knows the project best: the product owner must listen to what they say, accept their choices and heed their warnings. And that also means saying no to the business teams if necessary.

Lastly, it is also good to remember that the dev team and Product Owner are all part of the same project team and need to work together in harmony. They both need one another.   While a set budget, rigid list of specifications or fixed deadline may seem like obstacles to applying Agile principles, what often happens is that they become less of a problem as the project progresses, since the business team matures in its thinking and all the teams become more invested. Being aware of them and planning ahead thus gives you more peace of mind when taking on the project and enables you to aim for success in an Agile manner!