How the COVID outbreak accidentally kickstarted SCRUM in our company

6 min readAug 20, 2020

This is a story. If you are interested in a step-by-step manual to reproduce the focused sprint experiment, head to my other article.

I am quite biased against all types of SCRUM simulations. I have yet to attend one where the “eureka” moment for developers are be of any long-term significance.

I believe that the problem is the transfer of learnings from the small controlled environment to the day-to-day life in the workplace. This is especially evident when the team is already working in some “dark scrum”, “scrum but” waterfall-ish workflow.

“Yeah, we saw how quick the stand-up was, but we do have stand-ups and we do discuss things. It must be the complexity and not the approach that slows us down.”

This is a story of how we accidentally created a SCRUM simulation with our teams that we all liked.

The actors: two dark scrum teams, our usual suspects

The IT department in the organization was composed of two teams: the back-office team (BO) and the front-office team (FO). Both consisted of 3 developers, 1 product owner and 1 tester.

The developers on the BO team were all domain specialist. Each one worked in a different part of the domain with some overlaps. The team followed a deeply rooted workflow combining waterfall with some SCRUM ceremonies that hadn’t changed in the past 3 years. The combination of substantial technological debt and this waterfall approach was apparent. By that time an average lead time of the team was 12 weeks with an average cycle time of 4 weeks.

The FO guys had been partially shifting towards SCRUM and cross-functional team in the past 4 months, cutting their lead time to an average of 3 weeks with 5 days cycle time average. But they had been impacted by recent layoffs and had little understanding of the back-office domain.

I was a former FO team-lead newly appointed as an interim CTO and responsible for both groups.

The scene: COVID 19 comes in

The national-wide measures to battle corona hit our company hard and the revenues plummeted. The possible solution quickly materialised in the form of the “MP project”. To briefly outline its merit, it was the drop-shipping implementation of our custom and complex fashion e-commerce solution. The process was simple:

Input several XML feeds with product data in the system
Do some magic and employee interactions
Send API requests with an order to our partners
More super cool magic in the warehouse
Satisfied customer at the end

Since there was already some logic present from Q1 that somewhat covered the WMS part, it all came down to two super user stories:

“As a customer, I order products from multiple partners and I will receive it in one package.” (Get an order from our system and notify partner API.)
“As an employee, I can enlist products from a new partner using a provided XML feed with minimal extra work.”

The logic already in place in our ERP would then manage everything in between.

The only problem: to satisfy the investors and to compensate for the falling revenues, we should deliver it in 2–3 weeks.

The plot: doing the experiment

Given the state of the teams and the data about lead times at hand, no rational commitment could be made. But we decided to take up the challenge and do an experiment. We set the rules of the experiment quickly:

Deliver it.
Do little to no overtimes.
Focus on MP project and nothing else.

Team loading a van with office stuff. — The team loading their stuff on the truck.

We did manage to obtain separate offices in the different part of the town (courtesy of our main investor) and moved the entire IT department there. The hypothesis was that the geographical distance allows us to limit distractions. Since the guys also pitched in with the moving, it was also a fun and energetic way to kickstart this two-week hackathon that awaited us.

Step 1: Storymap it!

Given the uncertainty, creating a story mapping was a logical way to start. We came up with the solution, identified dependencies and validated the map with product owners and stakeholders.

There was a slight disagreement on how the final product should look like — GUI/no GUI for internal users. We decided to go with no GUI option. The decision that we would reverse at the end of a first sprint.

Step 2: Mini sprints

We decided to split our teams into two new groups and do two separate workstreams, effectively creating two new temporary teams. Both teams then agreed to do a set of four 2,5 days long sprints.

We then agreed on rules for every sprint:

both teams would have brief planning together followed by detailed planning separately
separate stand-ups
do a shared review with stakeholders
show the results on the review in the production environment
do retrospectives separately

We put all other work on hold and moved towards trunk-based development. With no time, vague specification and having a single focus, we decided to skip JIRA and use the wall and post-its to track our progress.

Previously, both BO and FO teams would rigidly go through all the tickets on their reviews. This had been time-consuming, boring, and sometimes no stakeholders would show up.

Given the urgency, finally, there was no problem of getting the stakeholders on the review. And since there were no tickets, the teams just shared a screen and started explaining what’s new in the product. Reviews were short and engaging.

Unraveling the plot: see the results

Did we deliver a 100% working product? Of course not. There were still many unfinished things and the product would not go live for another two weeks. But both teams outdid themselves.

For two weeks, we managed to create an atmosphere of a startup. The YAGNI and Lean approach towards MVP were embedded in default. We tried multiple ways and prototypes before picking up the final option.

Whiteboards were regularly drawn upon. Ideas were discussed between members since 2,5 days sprint would not allow for any dead ends. There was no room for solitaire specialist.

We immediately and instinctively shifted stand-ups from mandatory morning status updates to short ad-hoc syncs. Temporarily ditching the JIRA and using the post-its substantially cut the stand-up times. Having just one focus showed both teams that agile and fun development is possible.

Doing two new micro-services from the scratch, we even managed to upgrade the tech stack a bit by using a newer version of the language and the framework. Something that hadn’t happen for more than a year.

And with the business value in the centre, our sprint reviews became interactive and immersive for all attendees.

The plot twist: the main retrospective

Now came the difficult part. How to transform the learnings to regular life? We did a long shared overall retrospective at the end of an experiment. We mainly focused on learnings and “what I like/missed” observations. It was one of the richest discussions I ever witnessed with those teams.

The experiment showed that a different approach to development is possible in our company. And the retrospective produced a set of action steps to help us move towards that approach.