Discover before deliver…

One of the over used terms, and may be rightly so in a professional sense, is “end-to-end”. Think end-to-end, understand how to deliver an end-to-end experience, work towards meeting end-to-end expectations and so on…While skills in actually delivering a work package/think package (when one works on a delivering a plan) are paramount, what is more important is perhaps to understand what is the problem being solved – 1. As it is stated/heard or 2. As it exists and as per who? As long as 1 and 2 match, one is in a relatively safe zone of landing the work package in a way that it meets with expectations, but more often than not, it is seldom the case. And if one does not put an explicit effort to understand if 1 and 2 match (even when they do, there is a lost opportunity in gaining experience of discovery).

And what if 1 and 2 do not match, as it is most commonly the case with most problems?

While there are frameworks in place and are constantly evolving to ensure that the gap between the stated obvious and the real problem is kept to a minimum(by sharing context, collaborative development, rapid feedback loops raising questions on “is this what we really wanted?”), it is not easy to apply this in the multitude of decisions that get taken during the course of day to day activities and gently introduce gaps along the way.

Unless, it is made as a practice in the way one approaches ones “response” to an external stimuli (fundamentally speaking). Let’s take a look at the picture below that describes a very simplistic use case of a requestor, requesting a report. Now, note that this requestor himself/herself is raising this question outside the zone of context (or in plain words, is not clear on why this request is being made!).

What if the request is responded with “a report” as asked by the requestor where 1 and 2 don’t match! A healthy disaster ensues much to the irritation of the responder.

While it is not always as simple as this, but most times, all it takes is asking (applause! applause!) a set of questions that will gently push the requestor back into the zone of context.

Discovering the background/context before a work/think package is delivered goes a long way not just in meeting expectations but also in gaining more trust with the requestor.

And sometimes, the journey in discovering context to a situation is not adjacent to be pulled out with a few fishhooks of questions, but takes deeper and more persistent efforts.

Categories: Storeez

Tags: ,

3 replies

  1. Agree! Will Agile be able to deliver this ?


  2. Reading your blog I was reminded of quote by Albert Einstein “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”


  3. A lot of people hesitate to ask questions… They equate asking questions with questioning someone, perhaps? Also, more often than not, true context is not shared despite questions being asked, with “you don’t have clearance for this kind of info” being the reason… Which doesn’t work well in the long run. Persistent efforts probably pay off though! Good post, Phani!

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: