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.
Tuesday, July 30, 2013
Saturday, May 18, 2013
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.
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:Still with me?
- user surveys or user observations
- historical data or last week's results
- expert opinion or actual measurements
Which kinds of evidence can you get from:Final question.
- requirements
- high-level design
- implementation
- testing
- deployment
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.
Sunday, February 3, 2013
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..."
"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..."
Tuesday, November 6, 2012
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.,
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."
Thursday, November 1, 2012
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:
Here's the alternative.
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.
Friday, July 20, 2012
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
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.
- 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
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.
Sunday, April 15, 2012
The One-Button App
Since my friend and colleague Todd Warren has made a brief reference to it, I figured I should try to explain one-button apps, and why I push [sic] them.
With a one-button app, you achieve your primary goal with just one button push. No click click click check select check click submit. Just "do it." Todd's favorite personal example is the Flashlight app for the iPhone. Press a button and the light comes on. It's one of the few apps he liked enough to buy the premium version.
Twitter is a one-button app. Type and send.
Angry Birds is a one-button app. Stretch and let fly.
There's a reason Amazon patented and fights to protect 1-click buying.
Most initial student ideas I see for smartphone apps fail to find the one-button essence of their idea. Students design apps that are too general. General is often the enemy of simple.
Take the example of reserving courts (basketball, tennis, squash, etc) on a college campus. The general solution is a classic calendar-based event scheduler, where first you have to select the type of court, to get the calendar of reserved times, then do the usual time selection rigamarole -- and you haven't even contacted the people you want to play with yet.
To get a one-button app, first pick a common use case, like arranging pickup games. Those are always the same people on the same court type. When you start the app, all you see are buttons for today's free times for that type of court. Press one of those buttons reserves the court and notifies the people you play with. They get a "can you play at ..." message with buttons to say "OK" or "Can't make it." If too few OK's are registered within the next hour, you get a message and buttons to "Cancel" or "Keep."
That's it. Just one button push to do what you normally want to do. Only on the first use, do you have to pick a court type, and, when you pick a free time, say who to notify. These choices are remembered for future use. They're easily changed, along with many other options, via a preferences panel.
But the core value of the app is in that one button push.
With a one-button app, you achieve your primary goal with just one button push. No click click click check select check click submit. Just "do it." Todd's favorite personal example is the Flashlight app for the iPhone. Press a button and the light comes on. It's one of the few apps he liked enough to buy the premium version.
Twitter is a one-button app. Type and send.
Angry Birds is a one-button app. Stretch and let fly.
There's a reason Amazon patented and fights to protect 1-click buying.
If your product isn't a one-button app, how can you expect anyone to really get it in a 5 minute pitch? If your first testable release isn't a one-button app, how can you tell what your users really feel about your core value proposition, and not other issues?
Take the example of reserving courts (basketball, tennis, squash, etc) on a college campus. The general solution is a classic calendar-based event scheduler, where first you have to select the type of court, to get the calendar of reserved times, then do the usual time selection rigamarole -- and you haven't even contacted the people you want to play with yet.
To get a one-button app, first pick a common use case, like arranging pickup games. Those are always the same people on the same court type. When you start the app, all you see are buttons for today's free times for that type of court. Press one of those buttons reserves the court and notifies the people you play with. They get a "can you play at ..." message with buttons to say "OK" or "Can't make it." If too few OK's are registered within the next hour, you get a message and buttons to "Cancel" or "Keep."
That's it. Just one button push to do what you normally want to do. Only on the first use, do you have to pick a court type, and, when you pick a free time, say who to notify. These choices are remembered for future use. They're easily changed, along with many other options, via a preferences panel.
But the core value of the app is in that one button push.
Subscribe to:
Posts (Atom)