Launch Wrangling

Imagine being one of five testers in an organisation with over 400 developers. Picture a pace of 1,251 production deploys in a week. Now throw in a distributed workforce that communicates almost exclusively online.

Last night I attended Sheri Bigelow's talk at WeTest. Sheri works as a tester at Automattic in what I believe to be quite a unique environment. She shared some fascinating insights into building a testing culture in continuous delivery, in a team where testers are vastly outnumbered and testing is an optional activity.

Of all the things that Sheri spoke about there was one in particular that resonated. It's something that I can imagine applying in my own organisation, despite our vastly different contexts in developer:tester ratio, rate of release, and risk profile.

Launch Wrangling

Many people who develop software consider a release to be the end of their process. The idea that once a feature is in production, being used by the hands of customers, the development team can move on to their next piece of work.

When Sheri talked about deploying to production she said that it's "not the end of the game, it's kind of the middle". At Automattic the developers have work to do beyond creating the code itself. They are expected to monitor their changes in production and help to provide support to users when required. A true DevOps culture.

In the middle of a sports game, the players will usually take a half-time break. They'll have some refreshments, reflect on the game so far, take inspiration from their coach, then return to the competition.

In teams where deploying to production is halfway in the process there'll be a similar lull in activity. That little bit of time between something being finished and being released is an opportunity for refreshment, reflection, then a return to action. A half-time break.

In this relatively empty time, Sheri saw an opportunity. She started asking delivery teams to use the space around their releases to participate in, essentially, a bug bash. People put aside their day-to-day duties and those from every type of role worked together for a short period of time to test the product.

At Automattic this activity is called launch wrangling. Apparently when your Company Founder is from Texas there's a strong cowboy influence in naming things!

Sheri has used launch wrangling as an opportunity to introduce testing as an activity to developers who may not have tested before. She also talked about getting a lot of eyes across the application to improve the chances for important problems to be discovered prior to release. This means that launch wrangling is both a coaching tool and a way to improve test coverage.

No matter what type of delivery schedule you adopt, breathing space around deployments is likely to exist in some capacity. In my experience the amount of time available will correlate to the size of the changes being made to production. Big changes create a bigger pause. Utilising this gap seems like a sensible way to appropriately time-box a bug bash activity.

I like the idea of launch wrangling to foster testing across disciplines and improve the scope of testing where resources are particularly limited.