Build One before Building Many: Learning from Agile Feedback

These days, when you fly somewhere, you expect to choose your seat online in advance. Gone are the days when you queued up at the airport to check in for the flight and the nice person behind the counter asked, "Window or aisle?"

The ability to choose a seat has become a big attraction for online check-in, and often a money generator for airlines, too. But of course, someone, somewhere has to build this functionality—a piece of work one airline IT team called BOSS, for “bums on selected seats.”

A few years back I was advising an airline and its solution provider. In one planning meeting, the product owners presented the first of many seating user stories. The stories were still evolving because the airline had yet to decide if it would charge for seat selection or offer it as a feature over other airlines, but initially the user story was:

As a passenger, I want to see a seat map of the aircraft so I can decide where to sit.

Immediately the problems started to arise. The airline had several different types of aircraft; even when the aircraft were the same, the seat layout could be different; what if people selected a seat and then there was a last-minute aircraft change; what if ...?

The technical team quickly decided they needed to build a flexible system that could cope with the different types of aircraft and different seat layouts. They started working out what they needed to do, and more and more twists and turns complicated the discussion.

It got bigger and bigger. I think someone even uttered the words "domain-specific language." Even though we were using extra-long three-week sprints, it became clear this project was not going to fit in a single sprint. Naturally, the product owners went into shock, asking, "How can it take that long?"

At this point I intervened: "Why don't you build one seat map for one airplane?"

Techies and product owners alike looked at me, aghast. I had just proved how ignorant I was. What use was that?

"When you know what it takes to get one seat map working, you will be in a much better position to decide what needs doing,” I said. “Right now you are speculating about how to get this working. If you build one map, you will better understand the problem and solution. Plus, if you have one model working, you can do some usability and other tests early."

To my mind, everything that had been said so far was just conjecture—things that might get done, uninformed by what was actually needed. The other people in the meeting started to understand.

"But," replied an architect, "it will take longer because we'll have to do it twice. We'll have one airplane that is different and will need to rework the map."

"Maybe," I accepted, "although I think it will take less time because you will be more focused. You will learn and then be able to eliminate some options. You will also reduce the risk. This way you will get more insight into what you are doing, you will be able to perform early testing, you might get an early release, you will create a better solution in the end, and you will be more predictable. Surely it’s worth paying for a little rework when it generates such benefits?"

After a little more debate, the team accepted to do one seat map and revisit the story when they knew what to do. The user story on the table became:

As a passenger flying on a standard-configuration Boeing 777-200, I want to see the seat map of the aircraft so I can decide where to sit.

The story became smaller, more specific, and more deliverable. Sure, it had a lot less business value than the original, but it contained a lot less risk and had a high chance of being completed in one sprint.

Some of you might see this anecdote as a spike—a piece of work undertaken not to deliver working software directly, but to understand what building real working software entails. But this was not a spike. Spikes get thrown away. The deliverable from a spike is not working software, but knowledge; the knowledge might get codified as stories, tasks, or a write up, or, more likely, simply reside in someone's head.

This single seat map would get delivered and released. That is important because it kept the customers—in this case, the product owners—interested and involved. It also meant a small piece of end-user testing.

When the next planning meeting rolled around, the technical team had learned a lot from creating the one seat map. Their take on the problem was quite different from what they had speculated about three weeks before.

However, the customers had moved on. As important as selecting seats was, something else had jumped to the front of the queue. One day they would complete the seat maps, but not in any sprint soon.

Had the team started to build a multi-sprint generic seat map, the product owners would have had a hard decision. They either would have had to walk away from the work with little or nothing to demonstrate, or they would have had to push back on the changed priorities. Psychologically, responding to changed priorities is much easier when sunk cost is lower and the potential loss is less.

The moral of this tale is to think small. Whenever you are presented with a big request, resist the urge to treat it as a single piece of work. Find a small piece of work within the big.

For years one of my personal laws has been "Inside every big project is a small project struggling to get out." Build something small that works, learn from it, and grow it.