Subsumption Architecture for Scaling Scrum/Agile?

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.

Is Scrum quite Not Working for your team? Have you tried helping them through a shared understanding

Scrum is simple, yet I see, many teams are struggling with getting the full benefits of Scrum. I hear teams saying – “too many meetings, time-boxing is too much, we never get to rest - it is sprinting, sprinting, and sprinting.” What's even worse is that they feel awful when they don't get to finish what they plan to do for a sprint. That doesn't sounds like Scrum is working for them. Why would that be the case?

Like I said, Scrum is simple and it's almost a perfect framework for a NEW product development. It has three pillars - Transparency, Inspect & Adapt. Three pillars hold Scrum together. It has one product backlog and 4 meetings, 3 to 9 people developing ONE product within 1 to 4 weeks. Simple, right? It is so popular. Some people use it to plan for a family vacation. Although, these days, I hear people complaining about Scrum. They say it is not working for them and they think Kanban might work better for them. Really? I ask Why?

Does your team have a shared understanding of Why Scrum, Why Working Agreement, Why Sprint Goal, Why Def of Done, Why Velocity, Why Daily Standup, Why Burndown Chart, Why Transparency, Inspect & Adapt? Why having a shared understanding of all these is so crucial to a successful Scrum adoption. This in turn, helps them build awesome products.

Let's first see - Why Scrum?

Does your team have a shared understanding of Why Scrum? Why did they employ Scrum? I've seen many organizations send teams to a 2 days Scrum training and expect them to understand what Scrum is about and ask them to start using Scrum without asking them why Scrum. What can be so difficult? But it can be. If it is imposed on them, they don't really see the benefits of Scrum. They don't really see why they need to use Scrum. They feel that what they used to do worked fine. So, why do they need to change?

How can Scrum work for them if they don't know why Scrum and if they don't know whether it will work for what they do? After all, Scrum is for the team, no one else. They need to understand the benefits of Scrum, what impacts it will bring, how to measure whether Scrum is working for them, most of all, whether Scrum is the right framework for what they do.

Scrum is not for everything. It is certainly not suitable for bug tracking, call centers, and maintenance. Although there may be some benefits, it tends to waste the team's time. Especially, in sprint planning, daily standup, sprint review, people tend to waste time since not everybody has to be there. You don't need the whole team to fix a bug that can be done by one person. What do you review during a review, all the bugs fixed in the sprint? It becomes quite inefficient since the work does not require the whole team's collaboration. They will find all the rituals are a waste of time. So, if the organization enforces Scrum to the maintenance team, they will hear teams saying - there are too many meetings. But, if you hear team’s complaining that there are too many meetings even for a new product development, in that case, I believe, the team has to have a conversation of "Why Scrum?'' So, have a conversion, and find out what benefits, impacts Scrum will bring & have a shared understanding.

Why Working Agreement?

Does your team have a Working Agreement? The whole team is building a product together, right? It is not one person building it, it is the whole team. If that is the case, the team needs to know how they work together, how to communicate with each other, what not to do, (I think what not to do is more important than what to do), what is the team's mission, what do they value? How do they respect each other? A phrase like “Be curious, not judgmental” brings the team together, as it binds them building the product together.

Does your team have a Working Agreement? Does your team stand behind it? If not, why not? Have a conversation, and find out Why Working Agreement & have a shared understanding.

Why Sprint Goal?

A sprint goal binds the whole team together for a sprint. It is something that the team agreed and planned for the sprint. A sprint goal saying "get everything done for the sprint" is not a good sprint goal. It doesn't really inspire the team. A good sprint goal is like a beam coming out of a lighthouse. It guides them when they are in conflict and when they are not sure of which direction to take. It also helps them to be self-managed since it can be used to make the decision rather than waiting for the product owner to make the decision for them. Most of all, a good sprint goal inspires and motivates them to march toward achieving it every day.

Does your team have a sprint goal that motivates and inspires them? If not, why not? Have a conversation and have a sprint goal that inspires and motivates them.

Why Def. of Done?

Def of done is what it means by done when the work is completed. One's 'Definition of Done' can be different from others. So, it spells out what a product owner(PO) says by DONE is the same as the team's Done. Without knowing and agreeing on what it means by done, how can the team know when the work is done? How much work is needed? Make sure the team knows how to verify it and validate it. The best way to define the Def of Done is through test cases. So, having acceptance test cases and conditions spelled out, helps the PO and the team to be on the same page. I hear lots of time, the team saying – “how can I know what to test before coding?” Perhaps there are cases where it might be difficult. But I ask you, how can you estimate anything if you don't know how to test what you are going to build. It might be difficult in the beginning but find out how you can. Test cases I talk about here are functional test cases.

Now, in Scrum, it suggests that the team develops a potentially shippable product at the end of the sprint. Now, I ask you? Is that feasible? If the team is new to Scrum and if the team doesn't have an underlying architecture nor a devOp environment to support it, is it possible to have a potentially shippable product at the end of the sprint? If not possible, have an honest conversation with the team, and find out how it can be done. Have a plan so that your team can build an env incrementally to ship a potentially shippable product at the end of a sprint.

Is that how your team understands Def of Done? If not, why not? Have a conversation and help them understand Why Def. of Done & have a shared understanding.

Why velocity?

Velocity is for the team, not for the Scrum Master, nor for managers. Oftentimes, this is used for managers to compare one team's performance to the other team to see if one team is performing better than the other team. It is not meant for that. The purpose of velocity is for the team to know how much work they can get done for the sprint. I think “Velocity” is like “WIP” in Kanban. WIP is the work limit in progress and Velocity is the work limit for a sprint. This is how the team can control the flow of the work for a sprint. The team constantly inspect and adapt it, so that they can plan for the sprint realistically. Don’t fire Scrum but adjust Velocity before hiring Kanban.

Is that how your team understands velocity? If not, why not? Have a conversation and help them understand why velocity and have a shared understanding.

Why Daily Standup?

Everybody seems to know this. The team answers three questions - what you did, what you will do, and impediments. Now, the key objective for a daily standup is to find out whether the team is progressing toward achieving the sprint goal. This is more important than answering those three questions. The team does a daily check against the sprint goal. If the team deviates from it, they need to talk about it and make a proper course correction. Now, if your team answers these questions exactly as planned and they report no impediment, perhaps everything is going perfectly. Perhaps not. Ask the team if they are achieving the sprint goal. Daily stand up is a daily "inspect and adapt" against the sprint goal.

Does your team have this type of daily standup? If not, why not? Have a conversation and help them understand why Daily Standup and have a shared understanding.

Why Burn-down chart?

A burn-down chart tells how much time is remaining to complete a sprint. Now, I ask you, if updating the remaining hours for a task for a one-week sprint takes too much time, is it worth updating it? Perhaps not. Perhaps instead of looking at the burndown chart, look at how many user stories (backlog items) are done. Especially. look at whether the team is marching toward achieving the sprint goal.

Does your burn-down chart reflect the progress of the sprint accurately? If not, why not? Have a conversation and help them understand why Burn-down charts and have a shared understanding.

Why Transparency, Inspect and Adapt?

Why are they so important? Because they give the opportunities to learn and adapt so that you can improve the product as well as how you work together. Like I said, these three pillars - Transparency, Inspect and Adapt – hold Scrum together. Without these three pillars, Scrum breaks apart. It simply doesn't work. They provide feedback for the planning, execution, product, and how the team is working together. In Scrum, we have 4 explicit ceremonies that give us the opportunities to get feedback. Sprint planning against the planning of what the team will be working on; Daily stand up against the sprint goal; Sprint Review against the product; and Sprint Retro against how the team is working together. Through these ceremonies, we continuously learn about the product as well as how we work together and make proper adaptations continuously. I believe this is the essential ingredient that we need in a new product development.

Does your team understand the purpose of Transparency, Inspect and Adapt? If not, why not. Have a conversation and help them understand Why Transparency, Inspect and Adapt and have a shared understanding.

So, why is having a shared understanding so important?

Why Scrum? What benefits & Impact? Is it the right framework for what they do?

Why a Working Agreement that all can stand behind?

Why does an inspiring Sprint goal bind and glue the team together?

Why an agreed Def of Done?

Why Velocity is for the team not for managers?

Why Daily Standup? It is not a status meeting for managers nor for a scrum master.

Why Burndown chart? Does it take too much time to update it every day? Is it a waste of time?

Why Transparency, Inspect and Adapt – Are the team learning from what they did and continuously improving?

Why understanding the purpose of these and having a shared understanding of these are essential to get the full benefit out of Scrum? Because it creates an env. for the team to be self-managed and autonomous.

Daniel Pink in his book - Drive, says

"Hundreds of research papers… point to the same conclusion. Human beings have an innate drive to be autonomous, self-determined, and connected to one another. And when that drive is liberated, people achieve more and live richer lives."

So, through understanding these and having a shared understanding, it binds and glues the team together and helps them become a self-managed and autonomous team.

I also believe that autonomous teams can put valuable products out to the market faster, not because they work faster but because they can make decisions faster and cut down the decision bottleneck and deliver valuable products through incorporating feedback early.

So, have a conversation and help them understand the purpose of "Why Scrum" and have a shared understanding so that they can build valuable products that bring joy to all!

Scrum Team Adoption - Published on Agile Journal on March, 2011

Published on Agile Journal – March of 2011

How can you transform your team into an effective Scrum team?

Scrum is simple, but why is it so difficult to adopt? The dictionary definition of “adopt” is “to take and follow (a course of action, for example) by choice or assent.” So, in order to adopt Scrum, one needs to change, and change of any kind can be inherently difficult, especially for people working in teams. It would be a lot easier if we could break old habits by beginning with a clean slate whenever a new innovation comes along. Given human nature, however, that is not usually easy to accomplish.

Most people in the software industry have used at least one or more methodologies such as Water Fall, RUP, Rapid Prototyping and many more. Needless to say, adopting Scrum requires learning new practices. So the question becomes, how can Scrum be introduced in a way that effectively and elegantly transforms an established team into a Scrum team? Based on my experience, the successful adoption of Scrum (or any process) happens when a team fully understands why they need to change and what benefits the new process will bring them. Scrum is, after all, a frame work for a team; the people actually doing the work. So its successful implementation takes place most effectively when the team understands why, when and how to use the framework to be an effective Scrum team. This article presents approaches that you can apply to your organization just to do that.

First, understand the current environment

Before introducing Scrum, understand your organization’s current environment. You can do this effectively by selecting one or two teams in your organization and finding out what processes they are currently following; what challenges and impediments they face in accomplishing what they need to do, and what improvements they need or would like to make . Conducting one-on-one interviews with each team member for an in-depth analysis, or a meeting with an entire team for a quick analysis can be equally effective. Whichever way you chose you’ll want, at a minimum, to find out the following:

· What is working well?

· What is not working?

· What are the challenges they face?

· What impediments does the team face? What are the issues underlying those impediments?

· What urgent improvements does the team need or want to make? Why are they needed?

It is important not to go overboard collecting too many answers to the questions above. Put a limit to the number of answers you get but do make sure that you get input from everyone. One way to limit the answers is to employ the Scrum’s time-boxing. For one-on-one analysis, make sure that you get everybody together to review the findings and agree on the improvements as a team. The findings will be used as the basis of the team’s transformation. To compile an effective and objective list of the findings, consider bringing in an outside facilitator to conduct these sessions. The results will give you a good idea whether your organization is running smoothly and effectively.

Find out what Scrum can do for the team

After gaining a thorough understanding of the current environment, the next step is to find out what Scrum can do for your team. First, prioritize the complied list, then work with an experienced Scum master or coach to identify what issues Scrum can resolve. For example, let’s say one of the problems is that the team constantly needs to work over time to meet their deadlines. There are probably many reasons for this, but working together with an experienced Scrum master or coach, the team will review the underlying issues contributing to the problem and decide whether Scrum will solve it, and if so how. You’ll also find out the costs or benefits of not addressing the problems at all. Do the same for all the challenges and impediments and, in the end, you’ll be able to generate a list of improvements and see, very clearly, how much more efficient your teams will become.

Set the stage for adoption and implementation one sprint at a time. (But be realistic!)

Let me make this point very clear - Scrum does not solve all the challenges and problems in delivering a successful software product. But a Scrum team will manage those problems more effectively through transparency, inspection and adaptation. Gaining an understanding of your current environment, the cost of not fixing the problems that have been uncovered, and discovering how Scrum can help, all give the team a thorough understanding of why they need to adopt Scrum. The next step is to put this knowledge into action by grouping related items behind a common transition goal. When setting transition goals, set goals that are realistic and achievable. Next, execute them one sprint at a time. There are a certain set of Scrum practices that the team must employ initially. See the next section for the part of Scrum that the team must include initially, and what part of Scrum they can be included incrementally.

Implement Scrum/XP incrementally

This part of Scrum must be employed initially:

Provided that the team has had its scrum training and a product owner has a product backlog ready for the team, the following meetings of Scrum must be included first. Failure to follow this process will greatly minimize the benefits you will get from Scrum. They are:

· Sprint Planning

· Daily Scrum Meeting

· Scrum Review (Demo)

· Retrospective

In addition to the above, you will need to make sure that the scrum team has a goal for the sprint.

Introduce and implement the following incrementally:

After finishing the first sprint, the team can take on more to adopt. As mentioned earlier, select the items that the team needs and wants and then have a common transition goal behind them. Having a common transition goal will guide the team and bring focus to what they need and want to change. A good time to do this is during a retrospective meeting. Below is a list of suggested items that they can adopt incrementally:

· Definition of Done. Continuously revisit the definition of done. This helps a scrum team estimate work more accurately. Start with a simple one and then revisit it continuously during the retrospective meeting.

· TDD – This is not easy to adopt for some developers, especially those not doing unit testing. If difficult, first start by agreeing with a product owner on a “what and how to demo”, then automate the test cases, finally moving them into TDD.

· Potentially shippable products - Continuously look at ways to automate manual processes via automated tools and scripts so the team can deliver a potentially shippable product while increasing their velocity.

· Cross Functional Team - This is not easy to implement initially. Put a plan together for how the team can become a cross functional team by looking at the team’s skills and the composition of the team. If this is difficult to adopt, start first with pair-programming and move them into becoming a cross functional team.

· Techniques used during a Retrospective – There are many techniques for conducting this meeting, so experiment with them to find out what works for the team, or invite an experienced facilitator to conduct the meeting.

· Velocity - Do not put too much emphasis on getting a correct velocity initially, but rather rely on an experienced Scrum master or a coach to suggest a team velocity. Do keep a log of each velocity. The team will improve as it gains experience with the framework and with working together as a team.

· Sprint and Release Burndown charts – Apply the same techniques as in Velocity to get these measurements.

· Release Planning – If your organization already does release planning, review the process but avoid spending too much time up front. A realistic and effective release planning is when it is done right after a sprint.

Conclusion

Yes, Scrum is simple. Yes, it is the most effective framework for delivering a software product in a complex and competitive market. But too many organizations jump right into Scrum without properly preparing and guiding their teams though the adoption process. As I mentioned at the outset, for a team, the individuals actually doing the work, it is vital that they understand why, what, when and how they should use the Scum framework.

I didn’t talk at all about the support need from the upper management and the rest of organization. Yes, they, too, are indeed needed for the successful adoption of Scrum. Fodder for my next article.