Geeks With Blogs
Robert's Blog ideas about design and development

Neat is often wasteful, and we don't like wasteful do we?

A real world example of this is the McDonald's Drive-Thru order preview screen. If they did any feasibility studies on this, that guy was asleep. How many times have you seen your whole order come up on the screen before you are told to pull up? How many times do you still hear, "I'll have your total at the window." Guess what, by the laws of the universe, that drive through conductor has figured out that you are just another train at the station, and they need to get you through. They have figured out that you watching that painfully slow to update screen is actually slowing them down. And how do they judge the performance of these people? You guessed it, number of cars through the drive through in n minutes. All those LCDs must have been expensive, not to mention the software to run the display. Hope it was worth it.

If you are wondering how this applies to software development, let me help you out. Marketeers (and unfortunately members of the customer team too) come up with wiz-bang stuff that "is really going to make people want to use this thing." It is your job to cut through the cruft and get to the heart of the matter. In other words, providing real business value to the end user iteratively and rapidly.

Don't let the customer team, management or marketing foist implemenation on you

At some point, some joker may come up to you and say we need a message box that displays x and it really should be done with the blink tag and pink font. Slow down there Tonto. Did you actually spend the time talking to the end user or a proxy to figure out if they really want to see your pink flickering menace? Let common sense and user feedback drive the application, not some amateur's kindergarten level artistic sense.

As a Developer, I want to help decompose epic stories into their necessary items so that I don't wind up working on fluff stuff before its time.

It is your role to help guide the customer team in writing stories. Part of that duty entails getting to the meat of the subject. This is done through conversation about stories. This conversation helps discover what someone's previously help implicit requirements for an epic story were. Let's say that a business analyst has only ever experience web sites that send you a confimation email after you've created an account. So their implicit requirement for a story that deals with account creation is that the new user gets sent a welcome email. Being the pragmatist that you are, you think, "Hey, to let them know their account was successfully created, we'll just automagically log them in after account creation." Both are viable feedback mechanisms, but maybe your team doesn't have any experience with SMTP stuff. Uh-oh. So lets say the end of the release comes up six months later, and this business analyst is the one guy you can't get to show up to meetings or use the system, and this email sending business is his one requirement for the system. Now you've got problems.

By not having a conversation with this guy, you've effectively shot yourself in the foot and the rest of the team as well.

Ideally, what should have happened is that you convinced the guy that while an email may be neat, it is not really necessary. You do this by saying, "OK, you want that email, but we are going to estimate that at 20 story points or we are going to have to do a 10 story point spike to figure out how to send an email. We can split the story in two: account creation and confirmation email, and we can give you the account creation in 2 story points now." Having alot of other things that need being done, the business analyst agrees. Later on, he realizes that the email wasn't ever really necessary in the first place and actually winds up liking your way better.

The morale of the story is, members of the customer team and the user base are often going to think neat things are necessary, it is your job to convince them otherwise.

Posted on Wednesday, June 18, 2008 6:57 AM Agile , Design | Back to top

Comments on this post: The Difference Between Neat and Necessary

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Robery Stackhouse | Powered by: