(Originally published on Odd-e’s blog)

In our industry of product development, it is common that we try to learn from success. Successful people summarize a few factors from their experience, often presented as best practices, then others would learn to apply them. For example, if it is believed that “A” leads to success, then learning is focused on how to do “A” well. However, in reality, others often fail miserably after adopting “A”.

Why “A” does not lead to success for others, and what goes wrong?

(Originally published on Odd-e’s blog on Jun 15, 2018.)

As part of the LeSS trainer application, I was asked to give a graphical representation of LeSS. Here’s the result showing my view of LeSS:

In this article, we shall investigate why the learning and development of multi-functional specialists in Scrum is the core of organizational Agility and value optimization. Many Development Teams are not collaborating as real teams, but as a collection of narrow specialists focused on “their” tasks (QA, Backend, iOS, Android, etc). This leads to an ever-increasing number of explicit and implicit backlogs, “dependencies”, more Work-In-Progress (WIP), queues, and unsatisfactory lead times. How does it affect organizational Agility and what to do about it?

Making People Busy is Not the Goal

Recently I observed a few teams in a large service company during an extended enterprise Go See effort. I attended various Scrum Events, followed teams collaborating daily, noticed how they dealt with conflicts, and much more. We have done it for a very sound reason - to uncover the underlying system structures and come up with deep interventions. What immediately caught my attention was the focus on resource utilization during Sprint Planning. Some of the phrases that caught my attention:

• “Do we have enough work for the designer in this Sprint?”
• “Seems like testers are already filled up with work.”
• “Can we pull another item for our iOS developer to make her busy?”

The fundamental issue in complex environments is that work is never distributed evenly for a cross-functional team in a Sprint. Over the years, my observation has been that many teams do not respect the order of the Product Backlog because it means facing a painful skill gap.

Respecting the Product Backlog order means facing a skill gap!

(Bas Vodde and Craig Larman)

More with LeSS: Simplifying Organizations with 7 Design Principles

Why adopt agile or LeSS? Unfortunately, many organizations aim to increase individual or team productivity, activity, outputs, velocity, or resource utilization without realizing this usually leads to lower overall value delivery, longer cycle times for customer features, and less adaptiveness. LeSS does not focus on local optimizations such as increasing individual productivity, but on optimizing an organization for maximizing customer value delivery and organizational agility (adaptiveness)—the ease, speed with which an organization of people can change direction based on learning.

That’s not my job!