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.

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?

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.

Scenario Backlogs

Here's a problem I've seen a lot in my conjoined MPD 405 / EECS 394 software development course: poorly motivated iteration backlogs.

  Me: Why did you tell your team to build that this week?
  Them: It was the highest priority item.
  Me: Why?
  Them: It's a must-have for our MVP.

That's really no way to run a railroad. It definitely isn't planning like there's no tomorrow, because you could easily end up with 3 top priority items for 3 different user types, and nothing to deliver for anyone. Importance by itself isn't enough to determine coherence.

What I teach now is to create scenario backlogs. A scenario backlog is the set of user stories needed to support a complete user scenario. Until you have complete scenarios working, you have no demo, and not much you can use to get validated learning. An example I used in my fall class on mobile app development was an "exercise buddy" that would let a user create sets of exercise routines. The user could then "run" a workout, and the app would call out the steps for the user to do. There are a number of user scenarios needed for the MVP:

• End user starts the app and selects a workout. App calls out the steps for each subroutine in a workout set, switching automatically, and logging the workout in a diary at the end.
• End user reviews and modifies the workout, including getting new routines from the server.
• Trainers partnered with the app developers create routines on the server for end users to download.

(Don't push me on this. The only exercise I do is hyperventilating if you count that as aerobics.)

If you look at must-haves, there are plenty, from the calling out of workout steps to the server-side entry of  expert-designed routines. If you just pick must-haves for an iteration, you don't get much guidance.

Instead, prioritize scenarios. Which scenario will determine whether this is a viable product? I think the answer is clearly the first scenario. If no one wants to use their phone to direct their workout, don't even bother with the rest.

Make a scenario backlog consisting of all the stories needed to make the first scenario work for real. We don't need to support editing workouts, or entering routines on the server. We make a canned workout routine and get all the text to speech and timing and so on working.

Work on just those stories, over one or more iterations, simplifying when possible. When done, you can start doing some real user testing and find out what else people want, like maybe responding to "pause" or "repeat" verbal commands, or music.

While validated learning is happening, work on the next most important scenario.

The nice thing about a scenario backlog is that a scenario provides coherent comprehensible contexts for writing acceptance tests and for deciding what the simplest thing is that could possibly work.

Plan like there's no tomorrow

A mistake I see a lot when I'm coaching client/managers on developing release and iteration plans is delaying some of the most valuable stories until the 2nd or 3rd iteration. This is in a course project with only 4 iterations to begin with!

I think it arises from being used to creating schedules to fill the time allotted to the project. You know you can't do everything at once, so you take the pile of valuable stuff and spread it out. With enough repetition of the MVP mantra, they get the idea that they need to think small and high value, but that just reduces the size of the pile, not the urge to spread things out.

So I tell them "plan like there's no tomorrow."  Assume the project has been cancelled. This is your last iteration. What do you put in it to get the most value you can in this final turn? If you really take seriously the idea that this is all you get to do, you start creating an iteration plan that takes thin slices of value from those later iterations. Pack in all the goodies that your developers are willing to commit to, just not as complete and fancy as you'd hoped those goodies would be.

The danger of planning for the future is trusting that the future will still be there. So plan like there isn't a future.

Sometimes it's not what you slice, but who

I push slices a lot in my lectures on development. Whether it's for determining a minimum viable product, or breaking things down into testable releases, you can't be too thin. Elephant carpaccio as Cockburn says.

But slicing what you build is not the only place to look. Sometimes, it's important to think about slicing your target users. I was just hearing about a project rollout in crisis in a large enterprise because of the number and variety of users who need to be updated. It's basically your classic updating of the base level enterprise operating systems and all the attendant applications that affects.

Mass rollouts are famous for, if not failure, at least a lot of grief and midnight oil expenditures. If it hurts when you do that, don't do that! Slice the rollout. But just as you have to think about how to slice a product, so that you don't slice out the important part of the product, so too you need to think about how to slice your initial targets. Doing it division by division or region by region is as bad if not worse than a mass rollout. The first division in line gets all the bugs and missteps, often becomes disconnected from the rest of the company, and rightly feels like a lab rat.

Instead, look for the small audience that would be OK with glitches in the change process. What group really really wants this change, or what group is pretty tech-savvy and hence likely to find workarounds give useful reports on what's broken?

Don't stop with one slice. "We had a pilot rollout, now we're going live everywhere." Pilot groups are never representative of the total audience. Even if your initial slice was not a tech-savvy group, they knew they were in an experiment and almost certainly gave you the benefit of the doubt. That's not going to be true of everyone else.

Instead, you need to keep slicing. There are many criteria for the next slice. It might be the next group who most wants the change. It might be the group your first group interacts with the most. It might be the group that's most concerned about the change. Why that last group? Because at this point you can still afford to give them the extra attention and handholding they need at this. Plus you find out what the worst case reactions and snafus are.

Designing CS101: From Causes to Learning Obstacles

Let's recap the process of designing a learning experience for introducing computer science to non-CS students. What mistake is the target audience making that they care about? I chose "many people are missing out on a satisfying career." Why do they make this mistake? There are many causes, especially sociological ones, but I chose "people don't get to see what computer scientists actually do." They may take a programming course, often with "exciting" assignments like printing an amortization table. They may someone in a movie or TV show rapidly typing cryptic text on a computer screen. They may get to take a course programming games or robots. Unfortunately, none of these are accurate depictions of what we spend our days doing in CS, namely coming up with new ideas for old problems, or even better, new problems. For me, the neat part of CS is that I get to come up with ideas that may change the world. I can do it with surprisingly small resources, compared to other transformational disciplines like medical research.

Sp now the question is to identify why a learning experience is needed. You don't need course for walking, ordering food in a restaurant, going to school, playing videogames, etc. You learn these and many other things by watching other people do it, and/or trying to do it yourself and learning from failure. We only need courses when this natural process doesn't work. That might be because there's no one to watch, e.g., a master violinist practicing techniques, or learning from failure is not an option, e.g., brain surgery, or a handful of other reasons.

So why don't people learn what computer scientists really do naturally? I think it's pretty clear that it's because there's no opportunity. Most people don't mix with computer scientists doing their job. TV doesn't show it because there's nothing to watch. An intro programming course doesn't help, because programming, while critically important, is not the career. If you don't get people to understand being a doctor or medical researcher by making them take an anatomy course!

So I'm going to answer the third question with this: "people don't get to see what CS is really like simply because there's no opportunity to be exposed to people doing CS."

Fear of failure

Jonathan Rasmussen in Love it when you're proven wrong argues for the benefits of being proven wrong. As a strong advocate of learning from failure, I can't argue with the benefits.

Furthermore, fear of failure is a big problem in agile teams. It occurred in 17 of 17 organizations surveyed in People over Process (PDF) by Conboy et al. in the July/August 2011 IEEE Software. [One of the best such survey articles I've seen by the way. Seek it out for that and the other 8 challenges they discovered.]

But I don't think seeing the learning benefits addresses the real problem. The big negatives of being wrong are social -- embarrassment, loss of face, loss of future ability to influence decisions, etc. The individual cognitive gains of learning from failure are swamped by the perceived social costs.

That's why to enable learning from failure in my courses, I have most learning occur in private extended homework activities and one-on-one in-depth critiquing exchanges.

Getting team members to embrace individual failure without negative consequences is really hard. If only we could get developer teams to emulate improv groups. In a profile in the Northwestern alumni magazine, Stephen Colbert described the event that clinched for him why he wanted to work in comedy and improv, not serious theater.

I saw someone fail onstage — terribly, massively fail onstage,” Colbert recalls. “And we backstage laughed so hard at this woman’s failure, and our laughter was so joyful and not derisive. I remember turning to a friend of mine, Dave Razowsky, and we threw our arms out wide and hugged each other in laughter and literally fell to the ground in each other’s arms over the joy of that failure.

5 Whys, Harder than it looks, Part 1: What's a Failure?

An exercise I gave my software project management class at Northwestern this year is doing 5 Whys process improvement analysis, as in this video and essay from Eric Ries. I also strongly recommend Tony Ford's experience report and example analysis.

There were three parts to the exercise:

• identifying some key failures
• developing a 5 Whys causal chain for each failure
• proposing process improvements to address each step in each chain

I showed the Ries video, assigned the Ries essay, and then had them do similar analyses on several failures in the project they had just finished. I did these as critiqued exercises, figuring that it would take a few iterations to get right. I was right about the need for iterations, way off on the "few" part. Each part has been quite hard for most of the students.

First up:

What is a 5YA failure?

A project has lots of failures, but only some are appropriate for a 5 Whys analysis. Both Ries and Ford uses examples involving some form of web site failure. Here are some of the things my students submitted and the critiques they got. There were many similar examples of each type of problem.

• Our team had to implement image upload three times

I classify ones like this as as "bad choices led to rework." Clearly something you'd like to avoid in the future, but is it a 5YA (5 Why Appropriate) failure? I say no, because there's no user story failure. A 5YA failure is a user failure, like "the web site crashed" or "the search function returned 'page not found' errors." Without knowing what user stories were impacted and how (broken, missing, slow, ....), you have no idea how to prioritize the importance of the failure and therefore how much effort to expend in trying to avoid it in the future. Furthermore, making things run smoother is much less motivating than avoiding embarrassing public failures.

• Our client changed the design of the website twice

There were a lot of these "requirement changes led to rework." This has three fundamental things wrong with it. The first problem is the same as the previous example. There's no specific user story impact. Second, this is not a developer failure. You can't fix what you can't control. What you need to fix is how your process handles the things you don't control. It's not a 5YA failure if your cloud service dies. It is a 5YA failure if you have no backup. Third, and most important, this may not even be a failure at all. Iterating on designs is a good thing, if driven by actual usage. The whole point of agile is that it's impossible to get it all correct up front. The corollary is that sometimes we'll get it wrong. That's not a failure. That's life.

• XXX was working on a fork of the repository so almost none of his code got integrated

I leave what's wrong here as an exercise for the reader. It's one of the points already made.

• The code XXX submitted for "index" view of the "projects" controller didn't work
• Buggy and totally non-working code was checked in

These are just way too broad and non-specific. "Didn't work" doesn't distinguish "nothing happened" from "wrong results" from "error page appeared." The devil is in the details. Ignore those details and the devil remains. Trying to fix the problem "code is buggy" leads to ineffective measures like "test more!" and expensive ineffective measures like "everyone goes to Java camp this summer!" How the user story actually breaks leads to very different analyses, responses and priorities.

A 5YA failure is a bug report

My final recommendation for my class was that a 5YA failure should be writable as a bug report. That is, it should be put in the form "when a [user-type] does [action], [failure event] occurs." Failure events should distinguish between nothing happening, the wrong things being return, errors being returned, and so on.