Agility in denial

In spite of all the PDA (Public Displays of Agility) among the agile hippies (“make love, not specs”), some teams/divisions/companies still cling to the old waterfall-like processes. All well and good… even the most fanatical agile hippies admit that agile is not for everyone. But often enough, a team finds itself needing to be more dynamic and responsive to change, while afraid of the big bad buzzword “Agile”. These teams are what I call “agile in denial” (AID).

Signs of an “agile in denial” team:

• They write big or multiple functional specs, but keep changing them until the feature ships
• They have upfront scopes for each release, but end up dropping or modifying large chunks of the said scope as the iteration progresses.
• They designate “feature freeze” dates, each of which is preceded by a mad rush to implement as many features as possible, however shoddily, and put off quality control and/or bug fixing until after the feature freeze.

The detriments of the use of megaspecs to try to cement fluid requirements have been explored well enough – mostly teams end up losing valuable time and resources making (and committing to) plans they will end up not following. But when a team tries to maintain feature freeze dates while succumbing to variability of requirements and scoping, all hell breaks loose.

Let’s do a word problem together: Pretend you’ve entered a very expensive gourmet all-you-can-eat restaurant. Every delicacy you have ever dreamed of is spread out on the buffet line before you. Just a couple of snags: First, an hour from now the restaurant will close and you’ll have to end your meal. And second, ten minutes from now the buffet line will close, so you have only ten minutes to fill your table with all the food you plan to eat during the meal. Question: what percentage of the food brought to the table during the first ten minutes will be consumed by the end of the meal?

A delicious, if unnecessary parable. Feature freeze dates are great if the requirements are firm and the scoping is realistic. But when the scope is prone to change as the work progresses, a hungry PM will almost inevitably succumb to temptation to fill his table with many delicious features from the buffet line prior to the feature freeze, without thought as to whether the team will have time to eat and digest (debug and QA) the selection thoroughly before the release date.

And so we reach the fourth and most tragic sign of an agile team in denial:

• Their releases advertise many new features, but are full of bugs in aspects new and old. Releases often cannot be used to satisfaction until a patch or two has been provided.

REST hippies have taken over Facebook

See here. The addition of user names is the big story, but burried inside is the change of the URL format. Every user profile will now have a true RESTful URL.

Somewhere, the ghost of Roy Fielding is rejoicing. Most likely inside Roy Fielding’s body.

(Non-)Testing Overlays

It seems obvious enough: if you’re going to post content into a platform that will overlay its own graphical elements over yours, you might want to test how it looks with the overlays. I saw this gem of an ad on my Facebook sidebar. Glad I’m not employed by TNT:

Alien Territory

This is post is a bit winded, so I’ll slap the moral up here first. It’s a reflection on one user’s struggle against an unfortunate (lack of) usability design. Here’s the gist:

• Before adding a feature to a UI’s startup state, make sure it is essential. Otherwise, tuck it away until needed.
• Group features by their necessity first, and by their function second.

Read the rest if you want the touch-feely stuff:

I spend a lot of my free time (and disposable income) on making music at home – writing, recording, producing – all of it on a computer. I often think of the first time I tried digital music creation: I had to make a 64-bar backing track to a piece of a Russian pop song for performance by a sketch comedy group. I had some college instruction in musical theory, composition, and orchestration, but had never arranged a pop song, especially on a computer. I had procured some software I’d heard of, geared specifically for home users. It looked something like this (click thumbnail to expand):

Meet Cakewalk Home Studio 2002. Never before or since had I felt so vulnerable in undertaking a creative effort. I was a new kid coming into a big man’s world of electronic music, and everyone who got in before me seemed to find his way around just fine. Each minute spent working on that track seemed like a concerted attack on my confidence. Did I bite off more than I could chew? Could I get something done even if I didn’t understand every button and slider? It seemed as if an understanding of the problem domain, music, was not enough… The application demanded its own understanding.

So why do I discuss it here? If you wanted to get into digital music today with the same product family, this is what you would see:

This little gem, Cakewalk Music Creator 5, will ship this Tuesday and costs $40 on Amazon. How many differences can you spot?

Curvaciousness aside, for a program geared toward novices, everything comes down to one big question: “How essential is this?”. All those extra sliders on each track, all those textboxes and toolbars – all can be done without. They’re simply hidden until needed. If you feel you need something that’s missing, you can click around or look in a help file to find it. But you don’t have to feel intimidated by what you don’t need.

The reduction of the starting UI to the mere essentials is what makes all the difference. But if you think this is common sense that goes without saying, consider the Office 2007 ribbon.

The ribbon was intended to help newbies. The intermediates and the experts were doing just fine with the menus, thanks. The intention was to provide quick immersion into as much functionality as possible, to expose features that novices would otherwise not find. But when you do that, are you not also exposing functionality that they might not need? What percentage of Microsoft Word users use bold face at some point? Do you think nearly as many people use box borders? Or sorting? For the life of me, I have never used the text sorting function in a Word document. So why are all of these features equally visible at startup? Do you think an average user is more likely to use sorting than clipart? I don’t. And yet sorting is available on the Home tab and clipart insertion is not.

So when designing for new users, don’t rush to divide features by their function. Rather, divide them first by their necessity. Keep the essentials upfront and tuck away the rest until needed. That’s how you properly welcome the new guy.

NFJS now has a magazine

It’s amazing how the same bunch of cronies can keep blabbering about the same old stories and keep getting new revenues. Having gotten bored with blogs and anthologies, the speakers and organizers of the No Fluff Just Stuff tour now have a magazine. The articles comprising the inaugural issue are:

• Intro to Functional Languages
• Message Driven POJOs: messages made easy
• So You Want to be Agile?
• A Case for Continuous Integration

While you’re at it, how about some other breaking stories like “A Case For Avoiding Computer Viruses” or “Turning on Your Computer – a field guide” or “Hello, World in Three Lines or Less!”?