The other day I talked to an incre­di­bly nice person. She is a teacher for child­ren with special needs and was telling me about how her univer­sity educa­tion was appli­ca­ble to lots of diffe­rent target groups. That remin­ded me of the blog article I was about to write — about how the focus of the inter­ven­tion work of agile coaches should be on the what to do and not too much on what exactly the problem is. I tried to summa­rize how some­ti­mes it’s not important to under­stand the problem deeply in order to solve it. I danced around it endlessly as to why and like in an attempt to free me, she said: „Yes, it’s being solu­tion-orien­ted.“

Silence. I comple­tely agreed. And to make this more compli­ca­ted again: it is about not being problem-orien­ted, but solu­tion-orien­ted, which, on a more human level, would trans­late to under­stan­ding the needs more than the problem itself. And, in turn, detect solu­ti­ons that can start fulfil­ling that need. On the exam­ple of a child with special needs: I am sure the child would appre­ciate start­ing to work on small solu­ti­ons instead of digging into where it is limi­ted and why over and over again (which it most likely has for quite a bit of its life­time).

Why does this prin­ci­ple of under­stan­ding the need over the problem apply in an extra­or­di­nary way in an orga­niza­tio­nal envi­ron­ment aka the busi­ness world?

Well, in an orga­niza­tion, by defi­ni­tion, there will be a myriad of perspec­ti­ves. Asking a ques­tion about a certain issue to multi­ple people will most likely present you with as many perspec­ti­ves as people you asked. As agile coaches and consul­tants, we try to remain as neutral as possi­ble, which would mean not taking a side, and also not buying into one vs. the other perspective.

If we now ask about a problem, in order to under­stand how we could inter­vene, we’re faced with this multi­tude of perspec­ti­ves and aspects of the issue at hand. While that may open the door to under­stan­ding, it will not directly open the door to action. Asking about what is needed howe­ver might be a first enablem­ent, if to nothing else, then at least towards going this road towards the what without us the next time around.

Why should we not dig into the problem endlessly?

Reason A) Once we have gotten hold of the problem to solve, it might have persis­ted for quite a while alre­ady. Frus­tra­tion might be high. And while hearing frus­tra­tion can help reli­eve it, it is not news and will not lead us toward the future. We cannot change what has come before us. What we should ther­e­fore focus on, is obviously the future. Which is need fulfill­ment for as many stake­hol­ders of said problem as possi­ble.

Reason B) Well, problems change. Like partic­les, the minute we start obser­ving them, they are most likely moving. Because most of the time, asking ques­ti­ons and thus initia­ting a thought process, most humans will by them­sel­ves begin small beha­vi­oral chan­ges. If we do not factor beha­vi­oral chan­ges into our inter­ven­tion plans, people that are alre­ady doing some­thing might feel unhe­ard, unseen, and most likely unapp­re­cia­ted for making an effort. Which is not in our or anybody’s interest.

And Reason C) Addi­tio­nally, let’s keep follo­wing the agile prin­ci­ple of working product over docu­men­ta­tion. Of course, it is lovely to have fully docu­men­ted (with addi­tio­nal drawings) what the problem is, it might be more helpful though to have a working solu­tion or even the start of it.

And how do we get there?

My perso­nal opinion is that behind every problem state­ment, there is a need. The same way, in Design Thin­king, we formu­late a chall­enge in order to then turn to the user and dig into what their needs might be — and out of those needs, move towards a brain­stor­ming, and finally, proto­ty­pi­cal solution.

Asking non-violent commu­ni­ca­tion, there is a very limi­ted list of basic needs. As a first step, this list might be consul­ted as a helping hand and iden­ti­fier, in order to then specify e.g. the need for connec­tion as to connec­tion with who, in what form and frequency, and to what extent.

The magic of agile coaches is hearing or crystal­li­zing those needs and then confir­ming them with the parties invol­ved in order to deve­lop formats that can condense needs into aligned action.

So, to end with a quota­ble answer: all we need to know about problems is the unful­fil­led need they have emer­ged to give a voice to.