Wednesday, March 29, 2006
Next
Now you've got them stories written down, and made really nice and simple to understand. They seem like simple stories, but somehow you feel like they're a little too concise. You feel this compusion to get into detail and get into the technical aspects of things. It feels like you can't stop at telling more about the story, that you find many different ways of putting in more detail than necessary in the tiny index cards you have been given.
This is a common problem encountered especially by customers who want to tell the technical personnel what to do. It's like the time when you have your mechanic looking at your car, and you then telling him what should be done -- instead of telling him what the problem is. This is a symptom of orderitis or a showing of a primal need to order someone around.
This thought process basically impedes the thinking process of most software developers -- telling someone how to do his job leads to the "why don't you do it yourself?" response. And you don't want your software developers telling you that. Or at most, you don't want them not doing their job, which is basically creating software to fulfill the needs.
What do you do then when you have a compulsion to give more than necessary details regarding a story? It's really pretty simple. Just tell your developer(s) about it.
Yes, don't write it down on the index cards, don't write it down in your emails, or print them out on paper. You may print them out on paper, but shredding them afterwads would be great (but wasteful).
It's that simple? Yes. You don't need to bombard your developers with painstaking details to let them do their jobs -- unless you're the lead developer/architect (but even so, it's not healthy). Even if you do know what you're saying, stick to words not written down on paper. That way, it's easy to say them, and it's easy to forget them. The last thing you want is your developer telling you that the way you do things is so much more complex that the reason they're behind schedule is because you wrote down/emailed them to do it a certain way.
Sometimes, the best people who can decide how to solve a problem is the ones facing it. You can give advice, you can lead them somewhere, or you can give them books -- but it's essentially their job to solve the problem. Supporting them in the problem solving process is so much better than telling them what to do.
So the next time you feel the need to direct developers (when you're not a developer yourself, or if you're a developer but not assigned to the project), then just tell them about what you think. Don't tell them what to do but do tell them about the details that may be helpful to their problem solving endeavor.
Learning is not a matter of hearing it, reading it, or seeing it. It's about experience, exercise, and retention. You don't learn if you don't make mistakes. Making mistakes involves doing something.
This is a common problem encountered especially by customers who want to tell the technical personnel what to do. It's like the time when you have your mechanic looking at your car, and you then telling him what should be done -- instead of telling him what the problem is. This is a symptom of orderitis or a showing of a primal need to order someone around.
This thought process basically impedes the thinking process of most software developers -- telling someone how to do his job leads to the "why don't you do it yourself?" response. And you don't want your software developers telling you that. Or at most, you don't want them not doing their job, which is basically creating software to fulfill the needs.
What do you do then when you have a compulsion to give more than necessary details regarding a story? It's really pretty simple. Just tell your developer(s) about it.
Yes, don't write it down on the index cards, don't write it down in your emails, or print them out on paper. You may print them out on paper, but shredding them afterwads would be great (but wasteful).
It's that simple? Yes. You don't need to bombard your developers with painstaking details to let them do their jobs -- unless you're the lead developer/architect (but even so, it's not healthy). Even if you do know what you're saying, stick to words not written down on paper. That way, it's easy to say them, and it's easy to forget them. The last thing you want is your developer telling you that the way you do things is so much more complex that the reason they're behind schedule is because you wrote down/emailed them to do it a certain way.
Sometimes, the best people who can decide how to solve a problem is the ones facing it. You can give advice, you can lead them somewhere, or you can give them books -- but it's essentially their job to solve the problem. Supporting them in the problem solving process is so much better than telling them what to do.
So the next time you feel the need to direct developers (when you're not a developer yourself, or if you're a developer but not assigned to the project), then just tell them about what you think. Don't tell them what to do but do tell them about the details that may be helpful to their problem solving endeavor.
Learning is not a matter of hearing it, reading it, or seeing it. It's about experience, exercise, and retention. You don't learn if you don't make mistakes. Making mistakes involves doing something.
