Ask simpler questions–agile for non-techies III

Posted by Marcus Hammarberg on May 22, 2012
Stats
A couple of years ago I attended a course with David J Andersson, father of Kanban, on Kanban. I learned tons of stuff that I now use everyday but one quote really stood out for me. We were talking about prioritization and how it’s often hard to get business users to put values on a certain item and thus making them hard to prioritize. David said:
If you get a bad answer you have to ask a simpler question
I think it’s brilliant. It’s actually up to us to help them be able to answer the question we want. So we have to help them understand the question better. (In this case you might ask them to draw a graph showing the possible revenue or cost or something).
Since then I’ve been carrying this thought with me; ask simple questions. And then all of a sudden it dawned on me; this is what we’re trying to do all the time with agile. Break down complex and hard questions into small easier questions.
This is the third post in this small series (read part one and two), and again – if you are an agile old-timer this is probably not new to you. Please read along but remember that this is just me trying putting together old thoughts and practice that already exists.
A couple of years ago I attended a course with David J Andersson, father of Kanban, on Kanban. I learned tons of stuff that I now use everyday but one quote really stood out for me. We were talking about prioritization and how it’s often hard to get business users to put values on a certain item and thus making them hard to prioritize. David said:
If you get a bad answer you have to ask a simpler question
I think it’s brilliant. It’s actually up to us to help them be able to answer the question we want. So we have to help them understand the question better. (In this case you might ask them to draw a graph showing the possible revenue or cost or something).
Since then I’ve been carrying this thought with me; ask simple questions. And then all of a sudden it dawned on me; this is what we’re trying to do all the time with agile. Break down complex and hard questions into small easier questions.
This is the third post in this small series (read part one and two), and again – if you are an agile old-timer this is probably not new to you. Please read along but remember that this is just me trying putting together old thoughts and practice that already exists.

The first time I reflected on this was when I laid a jigsaw puzzle with my son, Albert. At first the mere thought of laying all those piece (I think it was 9 pieces) into a complete picture was daunting. And he gave up. But then I made the puzzle a bit easier. I completed part of the puzzle for him, and that was much much easier. And within minutes he had laid the complete picture and was super proud.

This got my senses tingling as I felt the same sensation as when you really get TDD working for you. You know, that feeling that the tests are actually pulling the production code from you. And the you can easily see the next step, based on the one you already took.

I then got that feeling again as I was doing a task for writing the book; I was asked to organize the table of contents. When first faced with the task of writing a book I wondered how I was going to do it; just crack my knuckles and start to write at page 1?
What we was asked to do first was to supply a table of contents. A brilliant idea that made us break the big problem (write a 300 page book) down to smaller pieces (write a half-a-page section). The hard question/task was made much simpler.

Compare that to user story mapping that is the same thing. The hard question; "describe the system to me", is broken down to much easier questions (so how exactly is the login process going to work now again?).

Conclusion

Yeah, yeah - I know. Nothing really new and interesting here, maybe. But I think that there's something worth thinking about here. When we break down problems into smaller pieces they become much easier to handle and understand. If you do this really well (as in the TDD example above) you can even reach a point where the rest of the work is a "fill in the blanks" exercise.

And for me, just trying to turn the tables on a "bad" answer and let it reflect on me is worth thinking about; what can i do to get a better answer.
If you get a bad answer - you probably have asked a too hard question. Try a simpler one 


Published by Marcus Hammarberg on Last updated