Large Organization Software Development Misconception #3: Should Our Team See A Narrow View Or A Whole Product View?

Small teams are great, and mandated by the definition of Scrum. Scrum also mandates a Product Backlog and Product Owner.

Most companies have more than 11 people working on any given product. Just to make Scrum fit (a local optimization), they will redefine “Product” to mean something narrower than the whole product. This is the first step into a house of mirrors where words mean the opposite of their original intent.

The next mistake is to give each team a “Product Backlog” which astute observers will notice is really only a Team Backlog.

And then give each team a separate “Product Owner” who is really just a Team Output Owner.

This leaves us with multiple separate “Scrum Teams,” each with a narrow view of the real product. Unfortunately this is recommended at the end of Henrik Kniberg’s extremely popular Product Owner video (a great video up until the few minutes at the end).¹

Managers worry these teams would run around like chickens with their heads cut off unless we pulled them together somehow. The traditional way of managing lots of people, dating back at least as far as Julius Caesar’s army, is to add hierarchical layers. Humans have trouble thinking of alternatives to hierarchical layers. So now we get “Chief Product Owner” or “Business Owner” or some other way of filling the gap above the multiple Team Output Owners.

Calling someone a “Chief Product Owner” or “Business Owner” is a symptom of an unnecessary intermediate layer. The Scrum and LeSS term for the real business decision maker is simply Product Owner.

A decendant of the failed Rational Unified Process (RUP) approach called Scaled Agile Framework (SAFe) adds a multi-layer stack of traditional management on top of our “Scrum Teams.” It sells because it’s really just renaming all the traditional roles to Agile-sounding roles.

These traditional/Agile hybrid approaches leave the biggest problems in the traditional space rather than the Scrum space of single-list prioritization and team self organization. With a narrow view of the product, only our toes wind up being Agile. The rest of our body is still hidebound by traditional management.

Scrum Masters (and management, if you have it) should help eradicate narrow views and encourage a Whole Product Focus instead.

Japanese version: 大規模組織におけるソフトウェア開発の誤解その３：チームの視野は狭くて良いか、プロダクト全体を見るべきか?