Product Sashimi

Yesterday, I had a chance to go to my first Agile P2P meeting. The talk was on Product Sashimi, and how to "slice a thin product" by J.B. Rainsberger. The main point Rainsberger was making was that there are benefits to be had by breaking up a large project into several smaller projects.

He started by defining 3 values of software. The first is features. This is what most business people refer to when they talk about business value. The second value of software is design. If a piece of software is poorly designed, the cost to add features to the system increases very quickly. Eventually, the cost of adding new features surpasses the cost to simply rewrite the software from scratch! Rainsberger affectionately refers to this as "Product heat death". I lol'd. The third, and main value Rainsberger talked about was how long before a customer can say "not what I wanted".

The sooner we get to that point, the sooner we know that the project is off track. He also mentioned the 80/20 rule for software features. Essentially, 80% of users will only use 20% of the features. The version that he stated was that only 20% of your features will be used often. The other 80% will be used rarely. 

Rainsberger says that if you "slice" thin products, you are more likely to get to the "not what I wanted" stage sooner. If you get to the "not what I want" stage sooner, you can catch those 80% less useful features earlier, and redirect your developers to the other 20%. Now this isn't to say that those 80% aren't important, but it does mean that you shouldn't put as much priority and emphasis on them.

He went over a few interesting techniques for breaking a product up into independent project regions. He also talked about how important it is to skin use-cases/examples into the simplest versions possible. Usually this involves reasonable (and sometimes unreasonable) sacrifices in usability. These simplifications let you skin stories into their simplest versions. The extra usability features can be added in later, once they're prioritized by the software users. They key is to get a full, working piece of software out to the users so they can tell you that you did it wrong. Although the software might be short on features, it covers the full breadth of the project. I thought this was one of the most useful things I learned that night. I definitely think we could have applied these techniques to j3wao, but I'm sure we will in the future.

In general, it was a great first Agile P2P. I'll be sure to be involved in more of these sorts of events in the future. In particular, uxWaterloo sounds quite interesting. I am really glad I discovered these community events. :)

Also, 528