From the Trenches: Small Batches for the Win

Background

This is a story about a former client.

I was consulting with senior members of a product development unit at one of Canada’s largest enterprises. They were preparing to bring a new product to market — it was both a mobile app for consumer use and a platform that could be white-labelled for other enterprises. It was a large investment (hundreds of millions) and one of the company’s high value strategic initiatives.

Capital investments began early in the year as hundreds of employees and many vendors were composed around the massive initiative. The Product Director oversaw the work of ~15 internal teams, multiple vendors, and two venture partners (including one of the world’s largest cloud providers and a design agency/subsidiary owned by the enterprise).

The Problem

Early plans were to release a “Minimum Viable Experience” before year end. By late Spring, the Product Director described two “problems” and asked for my help:

1. Release dates for the first publicly available version were slipping.
2. Scope was expanding.

I asserted those were symptoms and I helped him to see related factors:

• Each team could deliver only a portion of an increment. All teams suffered many dependencies as none of the teams were cross-functional. They could not deliver a ‘Done’ increment on their own.

• The managers of each team were writing their own requirements and adding to their wish lists of features to be included in the first public release.

• Stakeholders were repeatedly calling for “updated timelines” but the Product Director had no way to express (1) how much work had been done, nor (2) how much work remained.

• Any change to existing plans was met with calls for more estimates and warnings of “risk”.

I was concerned they would invest millions but still have a waterfall product development organization that takes 12 months to release new features. To address this challenge, I facilitated a brief series of workshops and coaching sessions for the Product Director and the adjacent managers/stakeholders.

What To Do About It?

I felt I must help the Product Director reframe the vision and mission. The mission should not be to build and release a product within the year — rather, it should be to build a development organization that can release increments of a product many times per year. And I wanted the stakeholders to arrive at this insight on their own … somehow.

A pivotal insight occurred when I asked them if they were aware of the International Space Station? Of course, they were aware and they were confused about the relevance of my question. I followed by asking if they remembered when NASA flew the Space Shuttle for the last time? They looked up the date: July 21, 2011. I asked how they felt about the fact that NASA had a laboratory in space but no way to transport scientists to the station. (A little history: USA relied on Russia for 9 years until Space X successfully launched a manned mission to the ISS in 2020.) They all agreed it was an embarrassing and costly oversight.

I then asked how they’d feel about spending their budgets to launch a new product but be stuck with a development organization that couldn’t transport new features into the marketplace?

The lights went on. A-ha!

This is not needed: A product in market that is difficult to maintain and update by a product development organization that cannot move faster than the company’s slowest department.

This is needed: A product development organization that can deliver frequently, get fast feedback from the marketplace, and respond (inexpensively) as the marketplace evolves.

With a new outlook on the mission, the next challenge was to align the teams and help them to deliver integrated features incrementally.

The Solution

The discussion got heated: the Chief Architect argued against “forced convergence” and suggested the engineering managers should continue to select their own priorities; a Scrum Master suggested all 300 employees should be recomposed into cross-functional teams (a massive re-org!); a Jira admin argued all the teams should combine their requirements into one list so the Product Director could rank-order all the requirements (note: there were ~3000 Jira items across 3 separate Jira instances).

Each argument had some merit but some of the suggestions would cause tremendous disruption. I felt the company should only embark on major disruption if less-disruptive experiments fail.

I suggested the answer would be found in “batch size”.

You see, all the symptoms were the result of working with such a vast batch of requirements. Each team had started building requirements they had cherry-picked from an enormous scope. The result of this was twofold:

1. The managers of each team were struggling to coordinate their work because no two teams were working on the same functionality at the same time.
2. No single requirement had been integrated end-to-end.

To address this challenge, I facilitated another series of coaching sessions for the Product Director and the adjacent managers/stakeholders. My objectives were simple: to encourage the Product Director to get all teams to (1) care about the same small batch of requirements at the same time, and (2) coordinate their work so as to fully integrate and test that small batch end-to-end before moving on to the next batch.

If my advice was sound, a re-org wouldn’t be necessary and each team could continue their own ways of working and maintain the autonomy they had previously enjoyed.

Two new planning tools were introduced to help all teams focus on the same small batch of requirements. First, a tool called the PR/FAQ (the Press Release & Frequently Asked Questions); and second, a single-page list of broadly defined requirements that the Product Director could prioritize or descope.

The first document, the PR/FAQ, was authored by the Product Director and a tight-knit group of product managers. The document served to describe a near term Product Goal: an upcoming beta release. The document described just two valuable features and was published for all stakeholders and teams. Everyone involved was instructed to clear their own backlogs of anything not described in the new PR/FAQ.

The next document, a single-page list of high-level requirements, enabled the Product Director to focus the teams on a small set of priorities and delineate what a requirement must achieve (versus what it may achieve in future releases). All teams were instructed to reconcile the sequence and acceptance criteria of their own backlogs with this list.

The Result

The result was immediate.

Having focused everyone on a small batch of requirements at the same time, and asking they commit to implementing and testing the new functionality end-to-end, two behaviours emerged:

1. They took more care to understand and define a requirement together.

2. They managed their immediate dependencies better/smarter.

For example: grassroots “requirements refinement” and “Scrum of Scrums” meetings were initiated by the teams.

And within 1 month, end-to-end features were available for testing. Alignment between the teams, stakeholders, and the product vision had started to strengthen and the stakeholders had started to see tangible progress.

***

This article is also published at scrum.works.

Learn more from David in his upcoming Professional Scrum classes or hire him for private Scrum & Agile training.