Courage in Profiles

(For those under 100, the source of this title.)

At least half of the student teams I coach in agile software product development have creating a user profile interface as their first or second user story. They're so used to seeing them in Facebook and elsewhere, that they assume they must have them.

Profiles are friction, pure and simple. There is no user payoff in creating a profile. How silly would an app be if all you could do with it was create a profile? Well-known sites can get away with profiles because users already know they want the services those sites provide and are willing to put up with some friction. Your fledgling app is unknown and probably not all that good yet. Users have no incentive to put up with any friction with your app.

Nor is there any value gained in early testing of a profile creating interface. No risk is reduced, because such pages are not hard to build, and no business value proposition is validated.

"Maybe so," the teams reply, "but our app has to have user profiles."

I've yet to see that actually be the case with any team.

The first argument for user profiles is usually "we need to know who the user is so that we can attach data to them." For example, if someone joins a scavenger hunt game, we have to know who they are so we can keep track of what items they have found.

This argument confuses identity with a user profile. To give someone an identity, all you need to do is give them a unique URL that they can bookmark and/or save on their home screen. Writeboard (recently retired) from Basecamp worked this way. When doing early product development, it's a way to get test users started with no friction or commitment on their part, and total control over the identity on your part.

The second argument for user profiles is so that users can specify preferences, e.g., what name they want to appear under, how and how often they want to be sent messages from the app, and so on.

This argument assumes that the only way to collect preferences is to interrupt the user's experience. How many apps have you used, from Google, Facebook, and elsewhere, where you wanted to change one thing, e.g., whether to get email reminders, and you had to go a preferences page with dozens of options to search through? Now consider the alternative: you get a reminder you don't want. It includes a link that says "don't send reminders in the future." One click. Done. Or your favorite restaurant searcher shows the places too far away, so you click adjust the radius of search and say yes when it asks if you want this radius to become the new default. Two clicks. Done.

Not only do these alternatives have way less friction, the friction is connected to immediate payoff, not some potential future benefit.

So does this mean you should never implement a user profile and preferences page? Not at all. Such pages are a great way for users to review and adjust their current settings. But such pages are just nice to have's. They aren't and should never be critical to your app or your early development process.

Have courage! Put user profiles where they belong, on the backburner, off the main line of development.

My Rubric Rant

I'm a calm guy, really. Normal blood pressure, definitely not Type A.

Unless someone gets me started on rubrics for courses. In that case, get a fresh drink, reserve at least an hour, and don't expect to get a word in edgewise.

To save my voice and your time, here's my rant on rubrics in easy to digest PDF form.

EBD: the right way to sell Agile

For quite some time, I've been summarizing agile development as "early and frequent delivery of value." But it has struck me that skeptics have a good reason to be unswayed by such a claim. Of course "early and frequent delivery of value" would be nice. Ditto "easy," "seamless," "fun to use," and all those other claims every product and methodology has promised since the beginning of marketing. It's quite right to treat such promises as so much hot air. What matters is what you deliver.

So instead, let's ask a few easy questions.

What's better for making decision, more evidence or less? 

Can I assume we all agree here? Next question.

What kinds of evidence are better:

• user surveys or user observations
• historical data or last week's results
• expert opinion or actual measurements

Still with me?

Which kinds of evidence can you get from:

• requirements
• high-level design
• implementation
• testing
• deployment

Final question.

How does the above flow of evidence compare to the evidence gained from weekly user tests on working code?

And this is how you explain agile to skeptics: It's EBD -- Evidence-Based Development.

The Easter Egg Hunt: An Lean Startup Coaching Story (Really)

"Hey, Bobby! Guess what? The Easter Bunny left a whole bunch of Easter eggs outside! Wanna go find them? Follow me!

"Here's your basket. Start hunting!

"Whoops! Not in the house, Bobby. You gotta get out of the building.

"WHOA! Not in the street! Back up! Here, little guy, let me point you. That's right, look in the yard.

"Honey, don't give up already. You're not finding anything, because you're just standing there, looking around. The Easter Bunny hid those eggs. You gotta move around. You gotta look behind things. You gotta pick things up.

"That's better.

"Yay! You got one!

"Whoa! Where are you going, skipper? You're not done yet. There's a lot more out there. Don't stop with just one egg. Keep looking, guy.

"Yay! Another egg! And another! You're doing great now, Bobby. Keep going!

"Um, Bobby? Bobby? Your basket is getting awful full!  Watch what you're doing. Some of the eggs you found are falling out of your basket.

"What, you gotta go to the bathroom? Oh, OK, come on in, then. But be careful! Whoa! Slow down! Don't run or you're going to tr...

"Oooooh, Bobby..."

The Scenario Canvas

After several years of trying, I surrender. I will never get my students to put goals into their user stories ("As a ... I can ... in order to ...").

So, following up on my earlier post about scenario backlogs, and triggered by Roman Pichler's Product Canvas, I'm now experimenting with having my teams plan and report progress to me with Scenario Canvases. A Scenario Canvas is nothing more than a short context scenario plus the exact set of user stories need to support that scenario. No more, no less.



Note that there are no goals in the user stories. The goals, constraints, affordances, and so on, come from the scenario. The scenario establishes a need in a situation. The user stories satisfy that need.

To develop, pick the scenario that is most critical for your business case, e.g., for testing or demoing. You identify the user stories and write them down. Then start with the user story that is the payoff point in the scenario, the point where the user need is met. Typically this is one of the later stories. Hardwire or fake the other stories if necessary. You need to see if the idea really does pay off, or if it needs more. As you go, mark the stories that are done. Some may be already done from a previous scenario.

I expect I will still have plenty to critique in what they send me, e.g.,

• Scenario bits clearly added just to demo a feature. "Sally wondered how many things she had loaned out, so she opened MyStuff and clicked Loaned count."
• User stories that align poorly with the scenario need. "Fred was  hungry and stuck downtown. Where could he get something vegan? He open FeedMe, started clicking nearby restaurants and opening their menus."

[Edit: Related is Goodwin's Designing by Scenarios (e.g., slide 55), but I'm not trying to create a design tool. I'm looking for a more focused tool than backlogs  for client/developer communication.]

The Number One Myth about Teams

Some of the simplest ideas are the hardest to teach because of interference from an equally simple wrong idea. The number one misconception about teams that afflicts managers and team members alike is this:

The purpose of teams is to split up the work.

Follow this and you get silos, low value bus factors, miscommunications, bottlenecks, etc.

Here's the alternative.

The purpose of teams is to gang up on the work.

Follow this and you get pairing, swarming, bonding, low work-in-progress, continuous improvement, etc.

Riesbeck's Rules for Flinching

Agile thinking is fine, but agile feeling is even better. If you want to do things right, it helps to react negatively and viscerally to doing them wrong. These days, I can't help flinching as soon as I hear someone say that they

• are working on anything the client / end user can't use
• are waiting for someone else to do something
• are making something complete
• are too busy to write tests
• haven't shown the client anything new this week

Wait a minute! Writing tests is writing something end users can't use. You're being inconsistent!

Only if you think the goal is to never flinch. Software development is a tightrope walk over Niagara Falls.   You have to expect to flinch a lot. The goal is to flinch less often and less hard.

Or, alternatively, turn these rules into a drinking game. Take a drink every time you hear one of the above things. The worse things get, the less you'll care.

Me and my liver will stick with flinching.