March 02, 2016
Or: The Difference between Pre-Launch and Post-Launch of an E-Commerce Project
March 02, 2016
Or: The Difference between Pre-Launch and Post-Launch of an E-Commerce Project
Every e-commerce project has this one moment that changes everything: The launch. From that magical moment on your efforts are made available to real users and are due to earn real money. The whole organization faces a major shift. The parts of an organization external from the development team change their modus operandi. In their perspective, what used to be an abstract future suddenly becomes an active system facing customers.
It’s a known fact that in any e-commerce project, the development never stops. Throughout the whole project there will be bugs to be fixed and new features to be implemented, no matter on which side of the cut-over you are. What changes is the attention brought to the project from the organization as well as the emergence of topics. Thus, the development of the e-commerce project faces its biggest struggle when switching from implementation to in-life-support mode. This struggle cannot be ignored by the development process.
In the beginning there is a deadline, usually decided by marketing or top management, hopefully validated by the development team. The launch of an e-commerce platform goes hand in hand with marketing campaigns, in order to bring a maximum of attention to the new e-shop. The whole development then is organized towards this date, with flexibility in scope but to maximize the business value.
We at Valtech utilize the agile methodology for our projects and organize our development in a scrum-flavoured process, necessary to provide high quality software. We introduce the scrum roles and scrum meetings. The development is organized in sprints, ending with a review meeting, in which we bring the surrounding organization (aka our customer as well as further project’s stakeholders) and the development team together. In our case this is usually once in a fortnight.
During those review meetings the organization provides feedback, but also voices their most urgent requirements based on the current state of the system. There is the marketing director, explaining how he likes the looks of the page, but would need another feature that allows them to communicate their campaigns better. Or the shop manager, describing how they usually work on products and prices, which differs a little to the new way and maybe should be tweaked. Also, all of them will do a little clicking around every now and then, and report any problems they notice.
All of that is excellent. Feedback is what we need. It’s the valuable input that helps us increase the quality of the output, which is the reason why we organize our projects like this. After all the review meetings specifically ask the organization to provide responses, comments and opinions. These will then be discussed and eventually be reflected, in one way or the other, in the software. Improvements based on this feedback are, e.g., scheduled for the next sprint and will be presented two weeks later. That is the development time period we are talking about in our typical projects: one sprint. If something is very urgent, of course we can make an exception. But the process is set up for (potential) deliveries after a sprint.
With the launch of an e-commerce platform, the perspective of the organization to the shop suddenly changes. A lot. From the cut-over on this is the platform that actually faces customers and has to be the breadwinner. That increases the pressure and shortens the timeframes we can think in.
If a bug is being found, it has to be solved as soon as possible. If marketing needs a feature for communicating their ideas, this is often urgent. And if the shop managers have problems with products and prices, it has to be addressed quickly, too. Each of these examples can cause a serious decrease of the customer experience, costing the organization money in one way or the other. Therefore it is not an option to wait until the next sprint with these issues.
Quick deployments therefore become a common thing, releases that violate the sprint cycle become the rule rather than the exception. Out of a sudden, everything is an urgent bug and has to be solved immediately. This is the time, where a strong Product Owner becomes crucial, a person to decide what really needs to be solved immediately and what not. There is usually a thin line, as this involves not only the technical expertise, but political awareness and people skills to deal with all the pushing stakeholders.
In the end, it doesn’t make sense to just follow an original plan. Plans change, we embrace that, which is why we’re agile. It has to be handled carefully though, to not fall into panic. With a new system and new features out there, new requirements emerge. And some of them can be urgent. However, as a scrum team it is not always easy to argue, that features can’t make it into the production system right away, but have to be arranged into the sprint rhythm. For the organization this often seems like an unnecessary delay. And that’s a valid point. Why would we forcefully hold on to a biweekly release cadence, if it doesn’t help the customer the way they need it, if it becomes more of a process overhead?
When developing new features, we make an effort to include the customer into the development process. It is important to collaboratively design user stories and to review and discuss the outcome together. Thus we can evaluate whether or not the implementation fulfils the needs, pinpoint what needs to be changed and eventually are able to make a valuable delivery. Scrum was designed to structure this development process, to benefit the customer by making the development more effective.
When working on an e-commerce platform post launch, developing larger new features is only part of the deal. To a large degree, and especially during the first few months following the launch, much of the efforts are fixes and improvements. Stabilization works on the software, improving the environment for the merchants, content managers or online marketers based on immediate feedback, etc.
Bugs are always of highest priority (stop and fix), but these “improvement issues” are equally important to the organization. Each of them results in a competitive disadvantage and costs the organization money or decreases its value (which again costs money). Reasons can vary, for example de-scoping before the launch or gaining new insights once the system runs productive. It therefore makes sense to use aspects of the Lean Startup method, in which we have build-measure-learn cycles.
In addition to the implementation of larger features, just the way it was used or planned to be before the launch, this makes three types of issues: bugs, improvements and features. These give the product owner a hard time prioritizing and a regular sprint planning becomes quite challenging. Quick fixes are the low hanging fruits, which make sense to be harvested as soon as possible. Bugs are always to be tackled first, obviously. But we must not forget about the further feature development. The share of each of those types can vary a lot, according to their nature or the organization’s current needs. These needs are urgent, but usually do not follow the two week rhythm, which leads to violation of the sprint cycle.
If multiple different issues are being squeezed into a sprint, but during the sprint new urgent needs need to be fulfilled, you’ll end up violating the sprint cycle all the time. And then during review meetings, there is hardly anything to be discussed, because most of the work is productive already. This causes the organization to feel, that the development does not make any progress and “everything takes too long”. But sprints also limit the product owner’s work, who needs to be able to react on changing environments and be able to re-prioritize accordingly. And on top there is a bad feeling in everyone’s gut for continuously breaking the scrum rules. We need to be more agile than scrum allows.
Simple put: Kanban gets rid of the sprints in scrum. Not planning a sprint anymore means that you can’t violate it, by changing the scope all the time. This makes it easier on the preparation side; specified tasks that the product owner and the team agreed upon can be worked on straight away. No need to plan for an upcoming sprint and deal with other things first, because they were scheduled two weeks ago. The priorities of the upcoming tasks can be changed by the product owner at any point in time. This provides a higher flexibility.
But the flexibility comes at a cost. Not having sprints, also means that there are no regularly scheduled review meetings. But review meetings are crucial. This increased flexibility requires the organization to be ready for smaller reviews on short notice. You won’t have a potentially shippable software increment after the end of a sprint either. This needs to be taken care of in parallel. A flexible release planning is therefore part of the deal, because the new developments need to be delivered properly. The gained flexibility here can easily mutate into chaos, if there is no structure. In any way, it has to be carefully discussed how and when to release, as the workload can be immense, depending on the project’s infrastructure. Kanban is less prescriptive than Scrum, which needs to be compensated by additional working agreements.
Due to these trade-offs, switching to Kanban is not a decision to be taken easily. The team and the customer have to be aware of the possibilities, but also of the pitfalls. Not until you’re able to face the challenges of switching from one process to the other, you should seriously consider it. In our case this is pretty straight forward. In the project I am currently working in, we analysed the situation and understood that we need the higher flexibility of Kanban. To approach the backsides, we introduced a release manager role who synchronizes with the developers to build releases and deploy them in collaboration with the product owner. The product owner’s tasks are enriched by collecting reviews from within the organization and gathering people to discuss problems and solutions in little ad-hoc planning and review meetings, whenever necessary.
However, it is important to reflect on the Kanban development regularly. Retrospectives make a lot of sense here. In my personal experience Kanban should only be seen as something temporarily, like a bridge over the troubled waters that a launch can cause. While valued very high, it certainly should be the goal to leave the high flexibility zone as soon as possible. It could easily evolve into a course of events where stakeholders keep piling up new requirements, thinking they will be done immediately. And by adding more and more new requirements on top of the stack, it appears that nothing ever gets done. A more restrictive process supports the product owner to not change the roadmap at a whim.
We try to develop software of high quality that benefits the customer. Timing is a vital aspect of that. Even perfect software delivered too late is worth nothing. Therefore, we switch to Kanban mode after the launch of an e-commerce project; at least for a couple of months, until the organization can work efficiently with the new systems and further development is merely about the realization of larger features.
Switching from Sprints to Kanban doesn’t necessarily make the life of the development team easier or worse. But it can make their efforts of more benefit to the organization. And in the end that’s why we do agile: To increase the business value for our customers.
Thanks to Ines Stuppacher und Dirk Lässig for reviewing this post and discussing the topic with me.