Background
I was consulting with senior members of a product development organization at one of Canada’s largest telecoms. They were trying to bring a new product to market. 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. A Product Director oversaw the work of ~15 internal teams, multiple vendors, and two venture partners (AWS and a design agency/subsidiary owned by the telecom).
The Problem
Early plans were to release a “Minimum Viable Experience” (their words) before year end. By late Spring, the Product Director described two problems and asked for my help:
- Release dates for the first publicly available version were slipping.
- 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 many managers involved were adding to their wish lists of features to be included in the first public release.
- Stakeholders were repeatedly calling for reports and “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”.
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?
That’s when 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” (his words) 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 embark on major disruption only 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:
- 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.
- No single requirement had been integrated end-to-end.
To address this challenge, I facilitated a 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 could be avoided 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: a 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:
- They took more care to understand and define a requirement together.
- 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.
***
Closing
What’s your take on this? Is your experience similar to mine?
If you’re interested in learning more from me, visit my site and contact me to explore the opportunities for your organization.