Back in April of 2017 when I was taking an Enterprise Scrum for Business Agility class from Mike Beedle, I didn’t know I was introduced to subsumption architecture while playing a Lego game. The Lego game started out by Mike handing out 15 or so business model canvases to us and asked us to arrange them for a venture capital firm. Basically, he asked us how best to structure this venture capital firm for today's marketplace. In a nutshell, the above picture shows one of the ways to organize such a firm. Before we go more detail into how it was done, let’s first find out the relationship between Scrum and subsumption architecture.
Did you know Scrum is based on subsumption architecture? Although subsumption is not mentioned in the Scrum guide, Jeff Sutherland, co-creator of Scrum, tells a story of how iRobot enabled Scrum in his blog “Subsumption Architecture: How iRobot Enabled Scrum”. He learned how iRobot got a breakthrough using subsumption architecture after many years of failed attempts at using an intelligent central processor to control a robot. He thought why not try this subsumption architecture for his team developing software products. That is how Scrum was created.
So, what is subsumption? Here is a snippet from the blog that may help you understand the subsumption architecture - “So I am taking a radically different approach with the subsumption architecture. This robot has no central processor. Each leg has a chip that can move a leg. There is a chip in the spine that coordinates the legs. A neural network chip in the head figures out what to do. There is no database. The world is the data and all data is created by sensors.” Put it another way, the subsumption architecture relies on each level doing its own work and then the level above does its own work as well as relying on the actions made by the sub level. It repeats this hierarchical behavior for the whole to function properly. Notice that it doesn’t have a central processor to control all the behaviors of the robot, rather relies on the sensors. This subsumption architecture should be applied when we scale Scrum, rather than relying on a central role(s) to make decisions for Scrum teams. The role based hierarchical structure is the culprit of delayed decisions stemmed from underlying dependencies. This is far from what Scrum is intended for.
Scrum has 2-level subsumption and Scaling Scrum should expand to n-level subsumption. Jeff said in his blog - “It has always interested me to see people trying to tweak Scrum without understanding the subsumption architecture. It is like a caveman coming upon a smartphone and trying to fix it.”
Indeed, Jeff. If so, when we scale Scrum, shouldn’t we apply the same subsumption architecture like iRobot did. Leg -> Spine -> Brain and all controlled by sensors. How would you apply the subsumption architecture when scaling Scrum? Let’s see how Mike Beedle showed us in the class.
The Lego Game for the Enterprise Scrum for Business Agility class. The picture above is the final picture of the Lego game we played for a venture capital firm using the subsumption architecture. Now, the lowest level of this design is teams working and delivering a value proposition for ONE customer segment. The next level is a portfolio(collection) of value propositions for the same customer segment. The level above is a business unit serving the portfolio of customer segments. Finally, the top level is a company that holds the portfolio of business units. So, the subsumption hierarchical levels are Value Proposition -> Customer Segment -> Business Unit -> Company like Leg->Spine->Brain in iRobot.
Are you applying the subsumption architecture when scaling Scrum? If so, how are you doing it? Is it similar to what I described above? If not, why not? Do you have a lot of dependencies to manage after scaling? Dependencies kill innovation, decrease team autonomy and collaboration and result in delivering the products and services late. Most of all, it ain't Scrum anymore. To reduce dependencies and to get the (well, almost) same benefits as you would get from One Scrum team delivering ONE product, you might want to consider the subsumption architecture when scaling Scrum.
Lastly, you might ask why use a customer segment, not products, as the basis of the subsumption architecture in the organization design above. Well, that will be the subject of my next blog.
댓글