Do you remember in school when you used to have the word problems in math? You had to read a paragraph and then pick it apart for certain key words. You might look for "of*" or "times" to indicate multiplication or "more than" for addition. I remembering doing fairly well at these *word problems (not that I enjoyed them), but I didn't really understand how much these were going to apply to me in the future.
It turns out that in the technical field (and probably others) I am constantly dealing with word problems. There are 2 ways that I see them represented:
- in general email sent each day (applies to non-technical as well)
- in specification, requirement or similar documents
*#1* General Email
With the amount of email that is sent each day, do you think some of the meaning behind what is in the email is lost? Maybe. Or maybe people are looking for certain key words ("of*", "times", "sum*") and those vary from person to person.
What if we kept email short with only a few key thoughts? Probably less chance of confusion or something being missed. We could also treat the email as a time-boxed (or word/character-boxed) event that could provide a very narrow result. I am not saying that there aren't cases where something needs a longer explanation or we need to document something. We should really focus on shortening the email thus decreasing the error is translation. This isn't a new idea as it came up in the top 5 for a search on "effective email". Instead looking at it from the perspective of potentially writing a long word problem for your intended reader(s), this reaffirms this concept.
*#2* Requirements, Specs, User Stories, etc
We gather ideas, features and requirements and put them into documents. This document is then read and a word problem result is formulated by another reader of the document. This is similar to what is done with word problems, but unlike word problems, there isn't an as well defined correlation like when translating to a mathematical formula. We have tried mathematical methods for defining how to create a software application, but these haven't taken off in practice (although some of the lightweight methods looked interesting).
Following the *#1, what if these were broken down into smaller *word problems for small units of work? Maybe like user stories captured on 3x5 cards. Of course, a user story could get excessively long, but keeping it focused would be ideal. Agile concepts address the run long or unclear process, but with most problems it is how it is implemented.
Conclusion
It is fascinating the number of ways agile can be applied even starting from the concept of a word problem. Whether applying it to email or breaking a project into smaller pieces, we should focus on the word problem we are asking someone to read or answer.
