How do we iterate user value?
How can we follow the "more smaller steps" approach and still deliver a positive experience for the user? Today let’s look at some ways to approach this problem.
It’s important for me to remind you that, for me and many others, working for equity in the world is far more important than geekery. I regard this as a side-story.
Stay safe, stay strong, stay kind, stay angry, please, because black lives matter, and we will move this rock.
The problem. We want our work to come in stories of about one team-day and a half, but that’s not much time, and we need to provide a steady flow of value to our users.
The truth is, most of us have been trained away from even trying to do this. It’s no wonder it’s not obvious how to do it now.
I want to throw out some avenues for your consideration. Some of these you’ll already know about, or we’ve already talked about, others, not so much.
First, two strategies that are outside the scope of this conversation, but are critical to getting the ball rolling: 1) fat-trimming in the first place, and 2) resisting the RAT (rework avoidance theory).
Fat-trimming means getting rid of the luxurious excess in your conception. It’s a pretty well-understood concept, associated with ideas like minimum viable product. Do that: Start there, and you’ll shrink your work a lot, but it still won’t get to 1.5 team days. Do it anyway. 🙂
Resisting the RAT means approaching the work, whatever it is, in the full and complete faith that we will be changing things we’ve already changed before, sometimes even a day before. It’s about refusing false economies of scale, in coding, for sure, but also in producting.
These two strategies inter-operate to really get us to what I want to talk about today, which isn’t so much strategic as practical tactics.
The idea: when we can resist the RAT successfully, we’re not thinking of any given shipment of the program as final, and this lets us dramatically lower and loosen the definition of "fat". That, tied to modern change-enabling geekery practices, brings us down to the 1.5-day mark.
In each of the possible avenues I’ll offer, we go in a series of stories, gradually refining the delivered value. We can refine that value according to our original vision, or we can refine it in direct response to the reaction of our user base, a win large stories never deliver.
Let’s take one of these and work it out in a little detail, then we’ll breeze past the others. Nearly all of them start from either "nothing" or "very damned little" and progress from there in a few story steps.
1. Go from manual to tedious to easy to automatic.
A classic example of this would be a password reset. Let’s look at the four variant forms.
Manual: the bottom line is the user has to contact us. When that happens, one of us goes and force-resets their data in the database.
Ick!
But hang on. You’re fielding to a hundred and then a thousand users. Password-resetting has to happen, but it doesn’t have to happen often.
Tedious: Now we have an inbox just for password-resets, a button for the user, a human on our end with an ugly screen that reads that inbox and walks us through the reset.
Also ick. Also better.
Easy: Almost the same as tedious, but now we got two inboxes. One that auto-sends a confirmation. One that receives the confirmation links. We still got a human on our side, but now she gets whole screens of confirmations.
Automatic: Ditch that human on our end, it’s the standard "reset password" and "click confirmation" and the actual reset, no human involved except the user.
Now, two things to notice. First, notice that it’s possible to reset one’s password from beginning to end. Second, notice that each round is pretty simple, even tho it requires altering things we’ve already done. These stories fit, and my 6 day story is now 4 1.5 day ones.
All it took for us to break this out was to decide that breaking it into tiny stories was important. Not all cases are that clear, but once you start to look for them, they’re much more common than one expects in the beginning.
There are other routes we could take with a case that lays out as nicely as this one does. That’s fine. Take any route that sizes the story correctly. The key is to remember how much benefit we get from that size.
Okay, so let’s one-liner a few others of the possible routes. With these, I’m going for a napkin sketches, and thinking of them not as polished answers but as legitimate routes. You’ll have to do the hard part for me. 🙂
2. Go from one, to many-same, to many-different.
Most "list-with-detail" split displays can be done this way, everything from credit cards to invoice line-items to course descriptions.
3. Go from show to edit-add-delete to manipulate.
There are lots of cases where even seeing something is a win for a user. Gradually pile on manipulations and drill-downs. They don’t have to ship day one to have value.
4. Go from 50% to 75% to 90% to 100% of the cases you want to handle.
Start by identifying & presenting the cases before letting the user act, then present only the actions that are permitted for the given case. Gradually expand which actions can be applied to which cases.
5. Go from ugly to okay to branded to lovely.
Nobody adores a web page from the early ’90s, but if it does the function you want, you’ll take the value and run. IMPORTANT: I am not dissing good UX, I’m proposing a route to it that has stories of the right size.
6. Go from two flow-paths to gradual elaboration of a complete flow graph.
Different structure in this one, but it’s relevant to flow-based systems. Implement one flow all the way through, with an opt-out to require human intervention on every page. Gradually add choices.
There are lots of these variations, many more than will fit, but these capture most of the high-level abstractions. Further elaboration will just drive us into very specific domains.
Notice how little rocket science is involved here. Pair product-specialist makers with code-specialist makers, they can do this readily. The underlying issue here is really that they aren’t looking for a way to do this. It’s not that there isn’t a way or it can’t be seen.
Some keys to making this kind of thing work might help.
First, you want a "keep it running" attitude. We never want to take our motorcycle apart and spread it all over the living room floor on oily newspapers. Each step has to leave us with something shippable.
Second, you want to keep your eyes on what we’re going to do today, not what we’re going to do next week. The RAT creeps in from all sorts of angles, and it nearly always pushes us towards taking larger step-sizes than are efficient.
Third, learn your brownfield technique, including TDD, refactoring, incremental switchover, and so on. The page is rarely blank, so greenfield approaches just aren’t enough.
Fourth, don’t go dark, and don’t go backwards. Modest steady change is immensely encouraging to your users, and it’s a real part of building their loyalty. Focus above all on "not worse", even if it means not every shipment pleases every user.
The bottom line? You can iterate user value. I swear it. Put product specialists with programming specialists, throw the RAT out the door, and just look for it. You’ll find it, you’ll deliver it, and you’ll win.
Supporting The PawCast
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. Support GeePaw Here.