The Perfect Dumpling Quest
Dumplings & Software Product Information Feedback Cycles
So how does making the perfect dumpling relate to developing software based products?
On the surface, these two activities appear to be worlds apart. Beneath the surface, the parallels are quite astonishing. Besides both activities depend upon having a certain level of technical proficiency as a prerequisite, both requiring a high degree of organisation and preparation.
More interestingly is that both activities achieve their goal by using the same controlled evolution process. The dumpling maker incorporates feedback from his/her consumers, to zoom in on the perfect the balance of flavour and hence ingredients. The software product/feature developer does the same thing, yet the dumpling maker appears to be better at doing it, well at least here in Sydney, where there are so many excellent dumpling places. To name a few:
It’s self-evident that the dumpling maker enjoys a much tighter feedback cycle, which brings obvious benefits. The dumpling maker can probably complete a hundred cycles before I could complete one feature or enhancement development cycle. Notwithstanding, “User Feedback” has been a buzz phrase for more than a decade and it’s still misunderstood. We also don’t get the leverage from it the dumpling makers do.
What is Feedback?
I am assuming like me, you also like dumplings, all sorts of different dumplings. I like dumplings to the extent that I have declared myself a “dumpling connoisseur”. Full disclosure, I am no Dumpling Master. I have tried to make them and watched Masters make them, but that is about it.
So as a connoisseur, when I eat a dumpling, I experience comfort and joy. A good dumpling manages to deliver an intensity which fills my palate without being overly bulky. The amazement that something so small and soft can balance the combination of sweet, sour, salty, bitter and astringent tastes at the same time. I have no understanding of decisions and interactions which have to lead to this experience, only my observations of the experience.
From this perspective, the only valid feedback that I can provide to the Master is what I felt and experienced when I consumed his dumpling. He is the one to adjust the next batch of dumplings based on my feedback. I eat another dumpling and, in my mind, there’s a contrasts to this experience with the one sensations from the first batch of dumplings. The pleasure that flows across my face is all that Master needs to confirm is his interpretation of my feedback and the steps he took to intensify my experience. I did not have to say anything about the size, the ratio of ingredients or what I thought would cause of the desired sensation I experienced in the second round.
As a dumpling master, he interpreted by feedback, using his casual mental model. He reasoned about what brought about my reaction and responded accordingly. I am sure that if I got into his implementation and talked about the texture of the pork, the elasticity of the dumpling skin and other concrete observable factors, the second batch would not have been an improvement.
- Firstly, I would have been substituting my opinion of ingredient interactions for the Master heuristics, who developed over millions of dumplings. Doing this robs the Master of the information he needs to interpret and adjust to achieve the experience I desirer.
- Secondly, my interjection into how he prepares dumplings can only confuse the situation. We are unlikely to have a shared understanding of the terms each one of us would use to describe the same thing.
Poorly formed feedback happens all the time in software product development. The person implementing a feature seeks out a domain expert or reference users for some feedback. After some back and forth, it turns into “Developers are Mars and Users are from Earth.”
“WYSIATI” — “What you see is all there is.”
One cause expressed in two different ways; as humans with naturally occurring biases, we usually make judgements and impression according to the information we have available. We don’t automatically consider the unseen or hidden factors. We form a first impression of a person within a second. We become “fixated” or “put off” by some misaligned GUI element. Then we have to break these impressions before we can move past them.
Burden Rest With The Master
As a developer, the Master of this thing I am building, the burden resides with me to elicit, direct and manage feedback. Many of us have experienced the variability in results when we walk up to someone to do some “hallway usability” testing. The variables here are whom you ask and why your asking?
My override motivation when implementing a feature is the materialisation the benefit the justifies the investment in the feature. Dodgy chasing that benefit materialisation requires continually asking “Have we got it yet?”. Part of the challenge is that only the consumer can answer this question with any legitimacy. Ask them too soon, and we risk getting fixated on the irrelevant, asking them too late and a tonne of rework follows. (“Often it’s better to delete the feature branch”)
Hence the need for clear benefit definitions that include desirable and undesirable behaviour characteristics. Benefits can ground feedback interactions and unite the participants around a common goal, the materialisation of the benefit. In other words, getting feedback at the right abstraction level is important.
The next part of the challenge is the elapsed cycle time. From the perspective of the provider of feedback, this is the time since they provided the feedback until they see some concrete materialisation of that feedback. The delay between these two points in time is a make or break factor. In this regard, the dumpling Master has it much harder. For a dumpling, the consumer’s memory is the constraining factor. Wait too long, he/she memory of the last dumpling fades, resulting in a faulty basis of comparison.
With software, we can always refer back to the previous build and run them side by side. This approach helps with recall and contrasting and is good practice if we are talking elapsed time of a two or three days.
As elapsed cycle time moves beyond a handful of days, we see the enthusiasm of the feedback provider fade. They start to perceive providing feedback as a high-effort, low-reward activity. Gradually, they become less zealous in their pursuit of the benefit. Left unaddressed, this becomes a fracture point within the team structure.
Tighten The Loop
There are no silver bullets when it comes to reducing cycle times. It quite easy to say “shorter iterations”, as though there was a formulaic method which delivers shorter iterations. Iterations only provide a cadence to coordinate the forward movement of the development endeavour. The duration of an iteration is arbitrary. For a long time, teams have fallen into this rabbit hole of delivering something by the end of the iteration, worst still they would attempt to deliver “something working that has business value”, but yet they never actually defined what this was.
The problem with summations like “something working that has business value” is that they have no value without a solid definition and the act of defining “something” in the context of an iteration. This is so cumbersome that the effort required to define it erodes any value it could bring.
We can move past this problem by understanding the duration of an iteration is merely a cadence, it’s when we look up and ask “Are we there yet?”. Think of iteration duration as a sampling rate. If things are moving fast and you need to know where you are heading and sample more frequently. Increasing the sample rate does not make things move faster, it just conditions a weak team to make some change to the status by the end of the iteration, or retards a strong team by asking them to say “no change, no progress”.
With that out of the way, we can focus on what matters:
- Information Cycle Time, the elapsed time between receiving feedback and then materialising that feedback.
- Unit Cycle Time (feature/enhancement), the elapsed time between commencing a unit of work and completing that unit of work.
- Materialisation Cycle Time, the elapsed time from verification/validation of a benefit until it’s materialised in the product.
- Realisation Cycle Time, the elapsed time from benefit materialisation verification until the first instance of verified benefit realisation.
Start small with the Information Cycle Time. Aim to optimise the time from the receiving of feedback to the presentation of the output. There are heaps of practical steps we shall share later. For now, here are a few tips:
- Determine the how long your feedback provider can wait before their enthusiasm fades.
- Remember cycles don’t have to be back to back, you can intersperse them with different activities.
- Idle resources are not a bad thing.
- Having work products idle is a bad thing.
Learned something? Click the 👏 to say “thanks!” and help others find this article.
Hold down the clap button if you liked the content! It helps us gain exposure.
Clap 100 times!
If you have any questions, contact us at firstname.lastname@example.org.
Like what you read? Follow us to stay in the loop. Lots more to come!
Recommended next read: What’s in it for us? — A consumer’s silent battle between a product’s value and price.