Tommi shed light onto our IT department's structure with his first article; he mentioned Scrum and some roles on our team. Some of you may already be familiar with the framework and this is by no means intended as an introductory course to Scrum. But we figured many of our users might be wondering what some of this information actually means.
Scrum is a framework for developing and sustaining complex products in an agile way. What we mean with product in this context is the Cardmarket platform under development, where an agile approach is needed to accommodate for an ever-changing environment with a constant opportunity for improvement. As a contrast you can imagine a classic waterfall project, like building a new road: The variables there aren't expected to change much and a project manager should be able to set the plan more or less from the beginning to the end, including all milestones and deadlines. This approach certainly doesn't apply in the software development sphere, and it isn't always the most successful one to begin with. Or are new roads always built according to predictions where you're from?
To be able to respond to the needs a changing environment and empirical realizations bring, Scrum was introduced in the world of software development (officially in 1995).
If the product is the Cardmarket platform, and I'm the product owner, it means it's mine, right? There are many people out there wondering about the origin of this particular naming decision. Believe it or not, the platform doesn't actually belong to the product owner, and the fathers of Scrum never really explained why they chose "owner." However, since the responsibility of the product owner is to "maximize the value of the product under development," I believe this name was picked to emphasize accountability toward the product, and with it the responsibility toward its users and other stakeholders.
Imagine building a new deck. There is a limit to how many cards you can put in, so every given slot needs to be justified. Which cards you pick depends on your goal—what are you trying to achieve with that deck? Do you want to storm your opponent on turn three? Go for the long run? Build a deck with your favorite and prettiest cards? Either way, you will probably have a strategy in mind when building that deck. And based on this you'll make decisions on which cards to put in, which to sideboard, and which to skip entirely. Similarly, this will help you keep your deck up to date and to find alternatives, with similar effects, but at a better rate.
Then a new expansion comes out, new mechanics are introduced, and your once strong deck needs updating to keep up. Though the analogy is not perfect, I'm comparing my product backlog to a trading card collection. As the product owner, I need to decide what we will work on and when, so that the product we build brings the most value to you, the end user, and consequently to us.
And what is the product backlog made of? Unlike with a TCG collection, I didn't buy booster packs of requirements and traded them with friends. Rather, our backlog is created by talking, and listening, to all involved stakeholders, observing what they're using and how, finding out the reasons and discovering their needs. It often also involves testing and analyzing current solutions. The product backlog consists of ideas, wants, wishes, and requirements based on those.
You're more interested in what we're working on than my specific role in this whole process, I imagine, so let me take off the lid. As we have split Cardmarket into the API part and the website part, it only made sense to split the team into two as well, with each team working on their specific parts of the platform. We have a vague roadmap in mind in order to build the process from user registration to a completed shipment as soon as possible, to be able to build on top of it, test it thoroughly, and gather feedback.
As mentioned in Tommi's article, we're taking the Domain Driven Design approach to guide us when designing and splitting the platform into smaller, manageable parts. We ended up with six core domains and a few supporting ones. The API team started with the User Domain (account management), continued with the Product Domain (product catalog management), and is now digging into the Marketplace Domain (article and inventory management).
The website team follows and builds on top of the API and provides the best feedback for the API team. The process is about as linear and predictable as the world in 2020–2022. For the API team this means that, while moving forward to new domains, they also need to adjust and/or fix previous iterations. For the website team it means they sometimes need to mock endpoints. Still we're moving on steadily, with the website team belly-button deep in the Product Domain itself.
How could it?
The Cardmarket we know and love was initially built by one person and grew organically according to new ideas, needs, realizations—which led to a monolithic solution. Besides a completely new architecture, some features you know might change, even if just by a little. We'll preserve the behaviors and functionalities we know work well and take a closer look at those that are in need of optimization.
This will be balanced with the desire to finish Cardmarket 3.0 in early 2023, so not much will change from the perspective of a website user. Not before the release of 3.0.
The API team has three and a half core domains left to tackle, besides the enormous amount of testing that awaits us. After the Marketplace Domain they will start on the User Balance also known as "Wallet" Domain (deposits and withdrawals) and then continue on with the Shipping Methods and then Shipments Domains. The Website team will follow in the same general order, and when we have those, we'll be able to test core processes, vital for the platform. From that "MVP" state we'll have a long way to go before 3.0 is ready for release.
And after the release of 3.0? While we're focusing on re-building Europe's largest TCG platform, new ideas for the future are still being developed and contemplated. While the IT has no mana to spare on those yet, they're slowly being added to the product backlog as very rough drafts. At the same time, we listen to the feedback and suggestions of our users, as Cardmarket always has, and incorporate those that will bring the most value to the most users.
I hope you have a better idea now of what we're up to and what awaits you in the not too far future. For the time after 3.0's release I'm interested to know: What are your favorite ways of providing feedback?