Keeping It Small

I recently let myself go down a little rabbit hole. I built most of an entire gesture-recognition engine before I realized I only needed two-fingered-drag.

I'm out of it, now, but it's important to avoid going into another one. It would be easy for me to start doing the fun stuff with my little game - adding more features, making it look better, et cetera - but I need to start doing the important stuff, like networking, right away.

This is the hard part. It's not really that hard to convince people that they should do the minimum amount required to get something out the door. A few charts, a quick chat, maybe a case study or two and you're good to go, there.

The hard part is convincing someone that they should be bored in order to achieve that.

Sometimes, the boring stuff is the most important stuff, though. When it comes to product development, few things are more satisfying than actually shipping something. So maybe the boring stuff is less boring and more an exercise in delayed gratification?

New Barista

The other day, I ran into Starbucks to get something for my wife. She wanted a Brulee Latte.

It was the end of the day and the more seasoned baristas were letting the new guy make what appeared to be his very first drink.

I thought to myself. "Great. Lucky me."

The guy took a long time but I'm glad he did. The reason he took so long was that he was making sure he did everything exactly right.

He double-checked the mixture to make sure he had the right number of shots. He carefully distributed the whipped cream to make sure it was done correctly. He tried shaking the large-grain sprinkles on to three different ways before he found a technique that got the right amount out of the shaker.

By the end of watching him make the beverage, I thought to myself "This guy's going to be alright."

Sure, it took him a long time to make my drink but it would have taken even longer to make it a second time after I sent it back for not being done correctly. He avoided that extra cost immediately but there's an even more important benefit to the way he went about making that drink.

The next time he has to make a latte with sprinkles, he'll use the technique he learned making the one I bought. As a result, he'll be a little faster. He'll carefully apply the whipped cream in the same pattern but he'll be able to do that a little faster, too.

Maybe he'll keep double-checking the number of shots a few more times but, eventually, he won't need to do that, either.

Every time he makes a drink, he'll make it just as accurately as the first time but he'll be able to do it a little more quickly. Eventually, he'll be fast and good.

If he'd focused, instead, on getting some sloppy splash of liquid out the door, he probably would have taken longer in the short run and it's doubtful that he'd get any faster or more accurate in the long-run. Had he made that choice, he would have flunked out of Starbucks.

I doubt Starbucks is this guy's ultimate career path - although it may be. Yet, wherever he goes, I'm sure the kind of decision making he exhibited that night, making that first latte, will serve him well.

Bon chance, barista whose name I didn't think to catch.

Benefits of Focus

Earlier, I mentioned that the done-centric culture of a truly Agile organization is largely about focus.

Focus has a lot of positive benefits and I'm not going to get into all of them.

Here's a short list, that is good enough for this blog entry.

• It highlights impediments by forcing them to be seen as part of the workflow - if you can't switch focus, it's harder to "look away" from a problem.
• It makes large batch sizes more obvious.
• It minimizes knowledge loss in the course of a task.
• It discourages work on less important tasks when more important ones are done.

There's probably an entire series of blog entries about the importance of focus.

Anecdote: Broken Glass and Bare Feet

One of my cats shattered a vase, the other day...and I mean shattered.

Focus Versus Urgency

Many modern software development frameworks emphasize getting to done.

When transitioning to such a process from a traditional project-management structure, a lot of people seem to map this to the old concept of urgency. In other words, they think that "get to done" means "rush".

Done Theater

How done is done?

To me, done means (at the very least) there are no more engineering tasks required for deployment. In other words, as a developer, you can put the software in a customer's hands right this second and the only thing stopping you is some external force.