Over the years, Xebia has been the driver of Agile software development at Intergamma, known for the GAMMA and KARWEI DIY stores. A year ago, we set out to replace the checkout process for their webshops. The existing checkout was slow and cumbersome to use, and no longer on par with other parts of the website. We knew there was a lot of room for improvement. In order to justify the investment we needed measurable results quickly. Within a year, we’re consistently seeing a significant conversion rate improvement.

Before starting out to replace the checkout, we discussed the technology stack and general approach. We had prior experience with React and Next.js, but decided against Next.js because of the complexity it adds. A checkout app also doesn’t need to be indexed by search engines, which is why you’d otherwise want to use Next.js. We decided to stick with a standard React setup, which enables us to focus and keep things simple. In order to measure our success, we set up A/B testing to directly compare the old and new checkout running in parallel.

Minimum Valuable Product

Our initial goal was to go to production as soon as possible. This meant building a minimal version of the new checkout, without sacrificing quality or usability. We call this the Minimum Valuable Product. Because we were shipping this product to our customers, we couldn’t compromise on quality, usability or performance. However, we could omit features that are hardly used, especially with control over who’s seeing our new product. Taking the Minimum Valuable Product approach means you should:

• Minimize the work required to go live
• Offer a working, usable product
• Not compromise your quality standards
• Measure your results, and adapt

Our approach was twofold: reduce the number of features and keep things simple. In order to get away with delivering less features, we set up our cart page to direct a customer to the old or new checkout based on the contents of their shopping cart. This allowed us to avoid implementing complex parts of the checkout such as in-store delivery, big parcel handling and separate shipments, as well as dealing with logged-in users and multiple languages. We also initially offered only iDEAL and credit card payments. However, the features that we did build were fully functional, including any edge cases. With this approach we were able to go live in just a few months.

Reduced friction, improved performance

Reducing friction for the customer was our main goal for the new checkout. We did this in many ways:

• Avoiding page reloads by putting everything on one page rather than 3 separate pages and calculating shipping costs on the fly.
• Change the order of steps so we avoid asking for information we don’t always need (i.e. phone number) and explain why we need it if we do.
• Make sure the browser can properly autofill the form fields, and offer suggestions for possible mistakes, such as a typo in the email address.
• Offer a zipcode autocomplete, but also allow entering the address manually.
• Integrate directly with our payment service provider to avoid navigation to an external payment page.
• Automatically scroll the viewport when necessary to reveal form fields.
• Validate user input as soon as possible and provide actionable error messages.
• Provide ARIA hints for screen readers and allow keyboard navigation.

Improved performance was the second goal of the project because it has measurable impact on customer satisfaction and ultimately, conversion. Unfortunately many parts of the process are hard to optimize, and we didn’t want to touch the back-end too much. We focused on improving the perceived performance instead. This means having the site’s skeleton load as quickly as possible, showing signs of progress while data is loading in the background. The front-end is essentially a static website, served entirely from a Content Delivery Network (CloudFront) for optimal performance. This is known as the App Shell Model promoted by Google.

Component-Driven Development

The webshop we built for Intergamma is whitelabel, used by its two brands in two countries. This means being able to change the site’s visual branding and serving it in multiple languages. To manage complexity, the various parts of the webshop are built as separate web applications, currently including Shopfront, Checkout and MyAccount. To make sure these parts form a consistent whole, we reuse a lot of components between applications. These shared components are built separately as part of a design system, using Storybook for development, collaboration and documentation. The components are published on a private npm registry so they can be downloaded from a central place. Each component is dynamically themed to match the brand experience and translated based on user preference.

One great aspect of Storybook is being able to build components in isolation, so developers can focus on building the user interface, without the need for a fully functional application. First we focus on building individual components, then we group them together to form a greater whole – first sections of the UI, then entire screens. In development we work with fake data to iterate faster and be able to cover every use case. This approach is known as Component-Driven Development.

Going live

Part of our strategy was to release the new application as quickly as possible, so we could start gathering customer feedback early on. The deployable application shell is fully static – just a bunch of JavaScript files and static assets. This has great benefits: hosting files on AWS S3 is cheap and files are served by the CloudFront CDN to make it load as quickly as possible. We did however need to setup Lambda@Edge to dynamically add CORS and CSP headers. Luckily all of this is automated using Terraform from our CI pipeline, so there’s no manual work involved.

We deployed the new application in parallel to the existing one, and used dynamic routing to direct customers to the new or the existing application. This was done based on a set of predefined rules, such as the type of products in the shopping cart and whether or not the customer is logged in. That way we could direct customers with “complicated” shopping carts to the existing checkout, while customers with “simple” shopping carts had a chance to be directed to the new checkout. This allowed us to go live in a very short time, with only a subset of features.

Agile Chef

As a real ‘Foody’ I love to spend hours in the kitchen and experimenting. I also watch a lot of TV shows and documentaries about food. The other day I was watching an episode on Michelin star Chef’s and this one was about Richard van Oostenbrugge. He recently received his first Michelin star in his own restaurant ‘212’ in Amsterdam.

While I was watching it suddenly struck me that Chef Richard and his team were actually working quite in an Agile way. ‘We take a dish and try to improve this again and again, instead of starting some new every time’. For me this is a great example of ‘Inspect’ and ‘Adapt’. Continuously and in small steps improve your product until it is perfect and worth of a Michelin star. If you have dinner in restaurant ‘212’ you can look from all tables straight into the kitchen. All the food is prepared right in front of you. For me a perfect example of ‘Transparency’.

Scrum Values

So, what about some of the Scrum values like courage, focus, commitment, respect and openness in a restaurant kitchen?

Without courage there will never evolve a new Michelin star worthy dish. It takes a lot of commitment to put in the needed work hours day in day out. You need a sharp focus on quality, preparing methods and ingredients to get and to keep your Michelin stars. All team members in the kitchen, from the dishwasher to the chef have a lot of respect for each other and they all need each other to deliver the perfect dish. And finally, there is lots of quick feedback amongst the team members, a sure sign of openness.

I really like the extreme focus of a Michelin star restaurant on the end product and to see all teams work close together. For the perfect end result and best customer experience you also need the ‘black brigade’ and they also need to be aligned perfectly.

All in all, I think a Michelin star restaurant (and a lot of other restaurants) are a perfect example of an Agile mindset. Next time you go out to a nice restaurant put on your Agile glasses and see what elements of their way of working you can use in your team or organization.

Read more →

The best way to avoid regressions and get fast feedback during development is automated testing. Especially if you’re testing manually by speaking to your voice app. The logic of your voice app is implemented in a webhook called a fulfillment. Since fulfillments are regular JSON APIs they are tested using existing technology.

Read more →

Whenever I give or facilitate an EventStorming training or workshop people always ask me, what is inside your suitcase? What are the essential items I need to do a successful EventStorming? Most importantly what do I need to buy! So in this post, I will give you the EventStorming tools that are in my flight case and where you can buy it!

Read more →

At some point in your application’s lifecycle, there might come a time when you need to start scaling your data storage. If you are storing media files or other blobs that have no relations between them, you can easily add storage capacity to solve the problem. For (semi-)structured data in a database however, scaling is a whole different story. Simply adding database instances is not enough. You will need to reconsider the usage patterns and decide what solution solves the problem you have. If your database is hitting resource limits because it is accessed very frequently, adding an asynchronous read replica might be the way to go. If the size of the data is the issue and lookups become very slow, you might consider sharding your database.

Read more

Over recent years, a tool called EventStorming became one of the go-to techniques for Domain-Driven Design consultants to collaboratively explore complex business domains at customers. Since consultants travel a lot from company to company helping with their questions about approaching software delivery this poses a small 1st world problem; How can we still comfortably travel while still carrying the required equipment to do an EventStorming at the customer (without breaking our back or needing a personal fitness coach). This was exactly the conversation we, Maxime Sanglan-Charlier and Kenny Baas-Schwegler, had during DDD Europe 2019. In this post, Maxime and Kenny will share their quest in finding the perfect EventStorming backpack.

Read more →

This blog is part of a series about comparing Cypress and TestCafé.
In part 1 (link) I introduced both of the frameworks with some examples of how they work, epic features and more.

In this part of the series, I will give you a straight-forward comparison of the 2 frameworks which hopefully will help you in your quest to find the best framework that suites your ambitions.
If you have any remarks about the content, please feel free to contact me.

Read more →

Read more →

The asynchronous workflow pattern, also known as the publish-subscribe pattern, is an architecture pattern which is typically used to asynchronously perform resource intensive and time consuming tasks. To separate the request from the task itself we can use a queue where the sender puts messages that another service can pick up.

This pattern is a subset of the CQRS (Command-Query Responsibility Segregation) pattern. CQRS defines a clear separation of a command and query model [MF-CQRS], while the asynchronous workflow pattern only defines a command model without caring how the result of a command is being read.

Read more…