The Question

Just reading Kimota94's new agile-related posting and somethings jumped out at me. The first is that I spend too much time writing up blog entries. The second is that I'm glad I don't read very many blogs or I wouldn't sleep at all. The third (and, let's face it, the real reason you've kept reading thus far), is the importance of the question.

Seems like such a simple thing and it is something I know I've even uttered aloud before, but it probably good to write about it here. Especially in the context of Agile development. Kimota94 stated that he has often found that when a question pops into his head, the answer is right there with it. I characterized that as "formulating the correct question". Once the correct question is posed, the answer is obvious. Hard problems are difficult because they haven't been broken down into simple questions. Which is where Agile comes in - it is a means to generate simple questions.

Kimota94 indicated that he discovered a new method of attacking a problem by deciding what the end-state should be and then working from there. I think of that as a "top-down" approach, where his first method is "bottom-up". Which is also why I say to people that I do top-down and bottom-up simultaneously sometimes - I constantly and instantly switch between the two approaches when I hit a roadblock. This leads to a lot of context switching overhead, but I think it leads to a better understanding. What does this have to do with Agile and questions?

Both approaches described here lead to or stem from simple questions. Some people will look at a problem and it will quickly because a question that has a simple answer, a bottom-up approach. Others will struggle because they cannot seem to make any headway at all. By creating groups of people to attack problems, hopefully someone in the group will turn a problem into a series of simple questions. These may be tasks or feature cards, user stories or test cases. Gathering these simple questions together makes it possible to answer more difficult questions like "how long with the problem take to solve?", which a product owner may ask a feature team. The customer may ask the product owners "how long to add this feature?". They use a top-down approach to break the problem into a series of smaller problems, which they send to the feature teams, and so on.

The vision that Kimota94 talks about, the top-down, end-state-first thinking is needed in some situations. That visionary thinking helps to formulate simple questions as well - things like "how should feature X interact with component Y?"

It's funny - the more I think about programming - the actual act of writing software - the more I realize that the "series of simple questions" is how I must go about it. I don't like writing code until I have a certain level of understanding as to what needs to be done. When I reach that, I write a set of simple comments (answers to simple questions, or questions themselves) and then fill in code between the comments. Each comment breaks down into high-level code ideas, which in turn break down (read: recurse) into smaller pieces.

Each player in the Agile organization should be able to conduct most of their work by posing or answering simple questions. Discovering the questions is the hard part - answering them is easy.