Why a delivered Solution may not always be a Value !

Last post 10:23 am May 16, 2021 by JAYANTO BHATTACHARYA

No replies yet

10:23 am May 16, 2021

Yes! Many of us consider that if a solution is developed in small iterations & Increments against the problem of the end users, the primary objective as guided by Scrum guide is achieved. In fact that is a false bubble of Scrum we are living in because it’s not enough if we mere observe and understand the customers’ problem and develop & deliver a solution until the end user consistently use the solution to solve their problem and consecutively the respective stakeholders also earn profit out of it.

While working for Amazon, I learnt a very interesting fact in one of the training which is; when Jeff Bezos used to organize a meeting with his executives, the giant eCommerce tycoon used to keep one chair empty at the meeting room. The empty chair used to represent the customer. So Jeff Bezos along with his team used to make sure that every discussion in the meeting is focused towards that empty chair (customer) and at the end of the meeting, they together used to insinuate whether the developed solution as per the deep discussion would benefit the empty chair (customer) or not. Therefore, I believe that before developing a solution against any customer problem, the Scrum Team, particularly Product Owner should put themselves in the shoes of customer by asking one simple question to themselves that if they would have been the customer, are they be interested & excited to use the developed solution !

Let’s understand it with an enchanting example, son (customer) says to father (stakeholder) that he is hungry (problem) & want to eat some spicy dish (requirement). Father (stakeholder) communicates about son’s (customer) requirement to mother (the team) & funds mother (the team) to buy all necessary ingredients (PBI’s) to make a spicy dish (solution) . Mother sees the ceiling while obsessing and gets innumerable options (possible solutions) like pizza, burger, hot dogs, noodle, fried rice, pasta etc. but finally mother (the team) decides and makes (develop) spicy noodles (solution) which is when served (delivered) to son (customer) has not liked the taste so the spicy noodles (solution) becomes a waste (Lean). Here solution was developed but the customer doesn’t like to use the solution to solve their problem so in this case the solution is not a Valuable Increment.

Let’s take another enchanting example, Mary (customer) asked her husband John (stakeholder) to go to a potter and order a customized clay pot with a good design on it. John met a Potter (the team) and ordered a designed clay pot. In few days, the potter (the team) made a good design clay pot (Solution) and delivered to John (Stakeholder). John (Stakeholder) gifted the deigned clay pot (solution) to her wife Mary (customer) but Mary (customer) didn’t like the design so denied to use the Designed clay pot (solution). So though the solution was created but the solution doesn’t fit into the bracket of customer’s expectation so in this case also the solution is not a Valuable Increment.

I believe to make a solution valuable, we need to deeply do 4 things

a) Observe & Engage with the end customers to meticulously understand their problems & requirements. Asking “5 Whys” could help to reach to the core customer problem.

b) Develop & deliver the mutual agreed solution in small increments in order to mitigate the risk of cost & effort as well as to learn new things through out each & every iteration (Plan — Build — Release)

c) Release the increment frequently in the market in small batches & pull customer’s feedback each time

d) Every time use the customers’ feedback data for continuous Inspection & Adaptation to adjust the further development of increment according to the customers’ feedback, product market fit and the changing environment after every iteration till developing the whole product

Scrum guide clearly says that an Increment is only Valuable when it is usable and in fact to build the Valuable Increment is the only primary objective of Scrum. I believe that a solution as an Increment or a set of Increments should be considered Valuable when it is both Simple & Usable. Most often in our everyday life we only use those applications which are not only usable but is also simple to use.

Let’s get an insight about it with an interesting example, I often convert my Word documents into PDF format. Before I used to use different applications for this requirement which often had much complications with innumerable advertisements amid confusing interface & navigation, too many columns to fill, too many check boxes to tick or even too many web pages with too many terms & conditions to accept so I never used to be loyal to any one application, I often use to switch in search of simple application for my requirement, finally I learnt from my brother that while saving a Word document, if I click save as option and select PDF format rather than Word format, the document is directly saved in PDF format then & there which indeed saved my both time & effort and indeed is very simple to use so thereafter I always use the Microsoft Word application to save my Word document in PDF format directly without wasting my time & effort for searching Word to PDF format converter at google.

“It takes too much effort to make something Simple” — Steve Jobs

“Simplicity is the ultimate Sophistication” — Leonardo da Vinci

As like solution which needs to be simple & usable, if we navigate through the Scrum Guide 2020 over Scrum Guide 2017, we would find that now, not only Scrum is a lightweight framework but the shortened, sweetened & simplified content which communicates about Scrum is also lightweight in terms of easy understanding & interpretation.