Learn Scrum's Validation from Subway

A Product Owner (PO) is a person who is accountable for a product at any point in time. PO acts as a bridge communication between the team and its stakeholders. The successful PO should understand and anticipate the client’s needs to more effectively manage the development process. It is a fact that product failure or success depends on PO performance. The PO needs to make sure that the Scrum team can make the best product possible. Therefore, understanding the needs of users is crucial to having a product that meets their needs. In practice, however, it is difficult and complex. Because not only does the PO have to act as the stakeholder representative in the development team, but he also has to act as the project team representative for the whole stakeholder community.

Do you know, when the POs' challenges arise? "Whenever each stakeholder of the system wants what’s best for the product from their own perspective and align it with their own goals." or "the stakeholders are starting to get feature hungry to the point that the quality of deliverables is getting affected by an increased amount of items in the sprint.". So, you might ask yourself " How stakeholders' expectations should be managed when they keep on raising the bar ?" The answers to the above question can be found in the Subway sandwich.

The Subway creates transparency between the sandwich creation and the customer. You as the customer start by saying "I'd like a footlong sandwich!" Subway employee says "great, what kind of bread?". Then the customer replies with "Wholewheat" so the Subway employee grabs a footlong loaf of wholewheat for your sandwich. Next, you move on to the meat, you put your request in, the subway employee adds it to the sandwich, then cheese, followed by veggies, and then ending with a sauce. In the end, when you receive your sandwich, you'll have the one that you want and there won't be any surprises or let downs because you were included in the entire process. As you can see, the customer makes sandwiches in the subway with the sandwich maker. Thus, the sandwich maker won't go very long without customer guidance. If you change your mind on sandwich ingredients along the way. “Oooh, those peppers look good, can I have more of those?” or "I don't like onions, please change it with more tomatoes". The sandwich maker can make adjustments based on your expectations. If a customer ends up with a sandwich that doesn’t have the mushrooms they want, whose fault is it? The customer should have said something along the way. Now think of a customer requesting a sandwich that is not on the menu like a cheeseburger (meaning that the subway has not the capability of producing it). Does the sandwich maker accept this request? "No!". If he has permission to accept, what will happen? Can he deliver it to the customer? Maybe he can, but definitely it takes a lot of time to provide it because they are not aware of unknown food ingredients and its production processes. Therefore its quality will not satisfy customers. What happens if the sandwich maker agrees to provide any food out of the menu to the customer? Nothing except "Chaos", "Complexity", and "Ambiguity". So, in Subway the sandwich maker knows what he should provide. He does not accept all customer requests because he knows what the food should be like to meet the customer's expectations. Sometimes, he gives advises to the customers "Sorry we do not have a cheeseburger, but we have a steak and cheese sandwich which contains the grilled beef serving with fresh vegetables!". He controls the customer's requests and also fulfills his expectations. In the end, the customer will better understand what is suitable for him and will be satisfied with the delivered product.

Now based on the Subway process, let's answer the question that I raised at the beginning of this article. " How stakeholders' expectations should be managed?". Using Scrum provides an excellent opportunity to collect stakeholders' feedback and to create transparency around the Increment. The Sprint Review event is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Moreover, the participants will validate changes to the Product Backlog or work on new features that can optimize the product's value. The stakeholders are the key audience in this event, where they incorporate their feedback into the Product Backlog. Putting the product in front of the stakeholders at least once a Sprint provides the following benefits:

• Engaging stakeholders: The stakeholders feel listened to and will have them coming back for more.
• Correcting course: The more often stakeholders see the product, the less you risk going in the wrong direction for too long.
• Creating accountability: The more transparency you create, the harder it is for stakeholders to hide behind ignorance.

Moreover, in my opinion, the role of a good PO is really important. A good PO is a domain expert who knows the business from many angles. In addition, he must also work closely with the Development Team. the PO should include the Development Team in quite a bit of tactical work on the Product Backlog, refinement, acceptance criteria, and other areas. This allows the PO to quickly navigate and adjust as new information emerges in synchronization with the stakeholders.

References:

• The Definitive Guide to Scrum: The Rules of the Game - Ken Schwaber and Jeff Sutherland.
• The Professional Product Owner: Leveraging SCRUM as a competitive advantage - Don McGreal and Ralph Jocham