G9 Experiments: The Greatest Hits (So Far)!

Robin Ehrlich
Group Nine Media Product Team
5 min readMar 6, 2019

Compiled with help from Chris Bradshaw

Whether you are in fin-tech or digital media, most software development teams will encounter variations of the same problems. At Group Nine Media, we fully embrace the scrum imperative to experiment frequently to improve and get past those problems, and hardly a retrospective goes by where our teams (aka pods) do not come up with some hypothesis on how to improve in the coming sprint. While not all experiments are created equal, some have really stood out for their spectacular successes, and others for their wild failures. As we continuously adapt and improve, we’ve been able to share experiments among our scrum masters and pods, so dear internet, consider this our humble offering to you and your software development teams — in no particular order, the greatest hits experiments from Group Nine’s development teams!

If your team likes to keep hand written notes, a sprint journal can be helpful come retro!

1. Sprint Journals

I did not understand the magnitude of this experiment until after the fact, when for the first time I was on the other side of the retrospective conversation and being asked to recall the last two weeks. I generally can’t remember what day it is, forget about trying to remember the past two weeks. This was a simple experiment developed by our Ad Pod to help them have more productive retrospectives.

The pod had noticed that when it came to gather data, the negatives tended to outweigh the positives and there were also times after particularly hectic sprints where everything was just a blur and they were grasping at straws for things to say. Thus was born the sprint journal — this is by no means an extensive document. The pod treated it as a sort of scratch pad, some literally using a pad of paper and pen, other using their word processor of choice, to just jot down quick things during the sprint that were of interest. We tried hard to de-emphasize thinking about things in terms of “good” and “bad” during the sprint, and just write down whatever you felt like writing, as much or as little as you like.

The results? The pod got a lot better at remember the good stuff! It’s easy to forget the good and get really hung up on the bad. It also helped provide more context to the bad stuff, allowing for better conversation and more opportunity to improve.

Making sure those unreads are in public channels

2. No Direct Messages

We are a team that uses Slack a lot, so much so that my company email inbox is pretty much just Jira notifications. Each pod has a dedicated public channel to facilitate work and transparency, but at some point or another, everyone ends up direct messaging about work that really should be public facing so everyone can know what is going on. The operations pod had been struggling with this a bit, messaging folks on other pods to help them troubleshoot, but in the process leaving all that important conversation locked behind a DM wall.

So, we set a lofty goal: No DMs for the entire sprint (except for personal, non-work related conversation). Needless to say, this did not work. But it was also not a total failure! Even though

everyone ended up in DMs about work eventually, everyone agreed that they had thought a lot more about how and when they were communicating.

Deploy Day: Or how to get better about shipping value

3. Deploy Day!

In an ideal scrum world, you would be shipping a product increment at the end of each sprint. In reality, this can be a hard target to hit. Our Data Platform Pod spent several sprints experimenting with ways to get all their hard work deployed with each sprint, as more often than not the last few hours of a sprint became a hectic scramble to deploy, with pleas to keep the sprint open for 10 more minutes!

First, the pod agreed that they would dedicate the last day of the sprint to deploying. No surprise, that still turned into a scramble, with code still changing and everyone still feeling like they were racing to the finish line. Next sprint, the pod decided to tack on a code freeze. Half a day before deploy day, we would go into code freeze and focus on QAing and getting everything in shape for deploy. The pod nailed it — the features were going out and our stakeholders noticed the uptick in quality. Our completion rates went up, and the team felt good about producing high quality code.

However, keeping deploy quarantined at the end of the sprint was not exactly best practice, and the pod soon felt comfortable enough to transition to a continuous deploy model. With this last iteration of the experiment, the pod’s velocity started going up, with completion rates remaining stable. This experiment is now codified as process for the pod, and the pod all point to this experiment as a turning point for them.

4. Lean Coffee

Our Media Management pod is one that really embraces the opportunities scrum provides to talk about what going on with the team. However, they started to feel like retro was not enough or there were topics that for whatever reason never quite made the cut for retro. So, the pod arrived at introducing a lean coffee style meeting to try and capture these things that were seemingly falling through the cracks.

The first meeting was also the last meeting. However, it did send a message to the pod — their retros were actually more productive than they gave themselves credit for, and they were talking about the important things. Those cracks were actually well sealed!

5. Talking about QA

It should come as no surprise that our client-facing pod is always looking for opportunities to optimize their QA process. There are a lot of people clicking on everything all the time on our sites!

After identifying a potential roadblock during retro, the team decided to experiment with what source of truth (or really, what tool of truth) to use for measuring web pages since it turns out, everyone was using something different. The Product Managers, Developers and Designers took the time to sit down and have a comprehensive conversation about this and a few other QA process items. After simulating a QA item, it became clear that a font file was causing line heights to be calculated improperly. This discovery, along with a few other tweaks, led to QA back and forth to be reduced by 40% — — Just goes to show, constant inspection really can make all the difference!

Let us know in the comments about your experiment success and failures!

--

--