competing with free products

TestObsessed just Tweeted about how to compete with free products: http://www.businessinsider.com/how-to-compete-with-free-products-2009-9

Short version: beat free with ad-sponsored.

focus on the customer

Thanks to Poppendieck's book Implementing Lean Software Development, from Concept to Cash, I read about google philosophy:

Focus on the user and all else will follow.

Lean demands that we identify what our customer needs, then we deliver just that. She talks about how the Quicken team entered a mature market of complex accounting software, simplified it, and delivered value to their customers. She mentions Google, Dell, Zara--all companies that have risen to success because they have the right focus.

set-based engineering

Since research/design is often very risky, the Toyota Product Development system integrates several processes to manage the risk. They use strict time-boxing, with multiple parallel research tracks trying to succeed, and at the end of the time box they can choose from all successful options. Their lead engineers are responsible for not only technical success, but business success, and their engineers stay on the same team for a long time, and are expected to excel in their craft. The teams, and individuals, are given objectives but are not micromanaged.

Why isn't it waste to design things we won't use? It's because waste has to be regarded in context of the whole system--and failing to deliver an acceptable design is a much bigger waste than optimizing the whole.

Agile 2009 Gordon Pask Awardees

This year's Gordon Pask Award winners were Gus Power, Simon Baker, and David Hussman. Ultimately we'll read more about it at http://www.agilealliance.org/show/1656

genchi-genbutsu

According to Mary & Tom Poppendieck's Implementing Lean Software Development, genchi-genbutsu means "go, see and confirm". I think it's a very powerful image for software development--when we have first-hand experience of what our customer values, we're more likely to understand its essence and to successfully make a minimalist implementation. It also sets up the relationship for us to ask customers directly about design tradeoffs. So, go, see what your customers are really doing, and find a way to make that go more smoothly--but ask them first about your ideas, to make sure you've understood the process.

Poppendieck's version of Shigeo Shingo's seven wastes

The lean community has categorized the following as the seven wastes of software development:

1. Partially Done Work (it delays feedback, thus increasing the risk we didn't catch mistakes; our investment cannot turn a profit if it's undone; we risk falling out-of-synch with other people that continue to work on the previous version)
   
2. Extra Features (this is overproduction and the worst form of waste because it's at the top of the food chain, i.e., it inevitably included all the other forms of waste somewhere in the process of creating the feature)
   
3. Relearning (if we already paid for one developer to discover something, why pay another developer to do the same thing? still, it's very difficult to have a usable system of documentation that explains why we chose what, when)
   
4. Handoffs (tacit knowledge--that which can't easily be explained verbally or on paper--forces the recipient of a handoff to re-do part of what we've done)
   
5. Task Switching (task switching increases the time-to-completion of the most important task on our plate, or causes waste in terms of unfinished work or relearning)
   
6. Delays (when developers have to wait for a customer's opinion, they may guess or pause. Either way, it's waste.)
   
7. Defects (in my opinion, defects may be on par or worse than Extra Features as waste... we've gone through all the work of making a feature, and then have to revisit it, re-test, and re-deploy.)