Thread by @codemanship

Here's a little exercise for a team to try.

Break into pairs. Each pair thinks of a real-world problem that might be solved with some simple software. Not a *solution* - a problem.

e.g., It's hard to find a parking space

Regroup, read out the problem statements and vote. 1/n

For the problem the team agrees on, imagine a feature - a proverbial "button" - that when you click it, the problem is solved.

e.g., You are directed to the nearest available parking space.

This is your "headline" feature - the feature for which the software exists.
2/n

Now think what other features would be needed to support the headline feature.

e.g., The system would need to know location of parking spaces, would need to know their current status (free/in use), and would need to calculate distances from the user's current location. 3/n

These are the *supporting* features.

Aim for a maximum of 5 supporting features. What's the simplest set of features that would solve the problem?

Write all the features down on index cards, as user stories. 4/n

Starting with the headline feature (we can fake the rest until we make it), brainstorm a set of examples - customer tests - using real-world data.

e.g., go outside and geotag some parking spaces.

Build the simplest software that will pass those tests. 5/n.

When the headline feature is complete, move on to the supporting features. e.g., Build something that calculates distances between locations, build something that locates the user, build something that determines the status of a parking space (e.g., using sensors) etc. 6/n

When your minimum feature set is working, TEST IT IN THE REAL WORLD. Does it solve the problem? What do you learn? Are more features needed? etc.

Then iterate the design again.

Repeat until the problem is solved to everyone's satisfaction. 7/n

The name of this exercise?

"Software Development" ;-)

8/8