Paul Kuijten

A short introduction about how you can make working with value more practical as a Product Owner.

A lot of people talk about scaling Agile. It’s all the rage nowadays. Everyone wants to scale Agile. But what does that actually mean? What does it imply? What are the underlying assumptions? Capital-A Agile When people refer to capital-A Agile, mostly they are referring to the value statements and principles in the Agile Manifesto. Commonalities that a group of well-respected craftsmen came up with in 2001, with regards to their ways of developing products. How do you scale that? I have no clue! What I can come up with is that you still want the Agile Manifesto values and principles to be in place when you scale something else. What is it then that you scale? Product development, not capital-A Agile! “To Scale” According to the dictionary: “Represent in proportional dimensions; reduce or increase in size according to a common scale” Invariably people perceive “scaling Agile” as increasing in size according to a common scale, aka “scaling up”. But wait a minute, wasn’t Agile about decreasing in size? About splitting things up into manageable chunks, about working in small batches, and about frequently inspecting and adapting in shorter timeframes? Interesting! If you perceive “scaling Agile” as increasing in size according to a common scale, wouldn’t you be at risk of impeding agility? Wouldn’t you achieve more agility if you decrease in size? Let’s look at the other part of scaling: “to represent in proportional dimensions.” This is commonly referred to as fractal, “a natural phenomenon or a mathematical set that exhibits a repeating pattern that displays at every scale.” The larger part resembles the smaller part, and the smaller part resembles the larger part. If you have a team that is really agile, you want the larger context in which that team operates to resemble that team, if you want that context to be really agile. Thus, looking at scale, it is the decreasing in size, and the representation in proportional dimensions that fit with achieving more agility, not so much the increasing in size, or scaling up, that people perceive when they hear scaling Agile. Up or out? In computer infrastructure, there is another concept. It’s called “scaling out.” Imagine you have a website with an ever increasing amount of users. Now there are two things you can do: Scaling up: keep buying a bigger machine to be able to handle the load Scaling out: distribute the load over multiple machines, and add machines as the load increases It has long been established that option 2 is the better option here. Now when you’re scaling Agile, are you doing the first or the second? Which is the best? Concluding Agile can not be scaled. What we can scale, is product development. We want principles and values from the Agile Manifesto to apply when doing this. We want to scale out, not scale up. This means decrease in size (many small servers instead of one big server in the infrastructure analogy.) The context in which we scale out must resemble the thing we are scaling if we want to preserve its properties, e.g. agility. I fell in love. From these basic conclusions, I found that I love the concept of Scaled Professional Scrum with the Nexus Framework, as it supports all these conclusions. We’re not building a bigger machine, we’re building an exoskeleton, a Nexus, in which the small machines can align and coordinate, and share the load. So we’re decreasing in size, not increasing in size. The Nexus is based off of Scrum and represents Scrum in different proportional dimensions. Thus, we preserve the properties of Scrum that allow you to develop product in line with the values and principles of the Agile Manifesto.