One of the good sides to being a notorious blogger is that publishers send you books for free in the hope that you will mention them on your blog. This month's lucky author is Seth Godin, who has a new one out - All Marketers are Liars!

So what has this got to do with the nine dollar loaf? Everything! And Agile Management? It's all about value. It's not about cost or effort or raw materials on inputs or investment. It's all about value. To focus on value, focus on the lie! That's the message. Now here is the example.

Back in spring 2002, I moved into Seattle's Ballard neighborhood. Ballard is a trendy little neighborhood at the Western end of the North bank of the Union Canal. It has a farmers' market every Sunday which attracts Ballard's trendy yuppie types, its intellectuals, its artists, its academics and its civil servants. The Ballard market takes all types but they have something in common - they value fresh produce grown locally. Ballard, amongst its restaurants, cafes and bars, also sports a few trendy bakeries including probably the best organic bakery in Seattle which supplies many restaurants - The Tall Grass Bakery. A loaf from Tall Grass will set you back $3.75 today. 3 years ago that was $3.25.

Meanwhile, Peggy's Bakery Organica (see below) took a stall at the market (back in 2002) and offered their loaves for $4. Being the daring Anderson's that we are, we thought we'd give them a try - even though it was expensive at $4. It tasted dry and uninviting. We thought it might be an anomaly, so we tried again the next week with a different style of loaf. Same result! So we gave up and went back to buying tasty bread from the Tall Grass Bakery. They also have a stall at the market but additionally the shop is only two blocks away and open the other 6 days of the week.

Over the intervening years, Peggy's price has gradually gone up. The next year it was $5, then $6 dollars in 2004. This year after opening in the spring at $7, they have steady increased the price to $9 per loaf - meanwhile, they removed the pricing signage from their stall.

My wife asked me how it was possible for them to keep increasing the price and for the price to get so high. I explained to her that Peggy was selling less bread each year and was pushing the price up to compensate, meanwhile segmenting the market in to those who were prepared to pay and those who weren't. What I didn't realize was that Peggy had a story. A story which was persuasive enough to segment that market and deliver the value for the small customer base prepared to pay the price. That is, I didn't have the language to explain this marketing phenomenon until I read Seth's new book, and I didn't have the understanding, until we invited a friend and neighbor over for dinner. Our friend works as a graphic designer with an architecture firm. She makes about a third of my salary which is barely enough to afford the cost of living in Seattle. Just enough to survive in a rented apartment and continue to afford her habit for the latest top of the line equipment from Apple, e.g. that essential must have for all graphos, the Mac G5. During dinner, she revealed to us that she is a regular customer at Peggy's. Well she is a health and fitness nut, in a, hit me I'm a black belt at some unpronounceable martial art, kind of way. She actually liked the taste of Peggy's bread - or had persuaded herself that she did. She was prepared to fork out the $9 for a loaf of bread on a Sunday. Self-indulgence? You betcha!

As Seth explains in his book, all good marketers are masters at story telling. And in their own way, these stories are lies. But they are authentic lies. So here is Peggy's story - her authentic lie. I picked up her leaflet (which cunningly contains the prices) at this Sunday's market.

"Peggy, Russell and Ryan would like to welcome you...."

"The Northwest's scenic alpine highway 20 is the home of our bakery Peggy's Bakery Organica....."

"WHEAT FREE HERITAGE GRAIN BREAD, Emmer $9, WA grown grains, mesquite meal, Skagit Valley honey, non-additive sea salt, Red Star yeast, organic gluten, ex-virgin organic cold pressed Olive oil."

And it goes on and on. Yep, if your smart enough to buy into the artisan crafted loaf story then you too will pay $9 for a loaf of bread where a similar substitute product, also made in Washington by Washingtonians, can be purchased metres away for the princely sum of $3.75!

Congratulations Peggy! You're a fantastic liar!

What's your story? How are you extracting that extra profit margin from your customers and defending your market share against your competitors? [Update: The term "liar" in this post is used in the context defined by Seth in the book - not in its accepted English dictionary meaning. If you want to understand this better - read the book, or Seth's website]

I've decided to publish some Feature Driven Development benchmark metrics. This are indicative based on my experience with real projects over the last 6 years. I have the real data to back up these numbers.

Benchmark sustainable performance for a substantial project which may grow to over 500,000 lines of Java would be up to 5 Features per developer per week, with a quality of around 3 escaped defects per 100 Features. As Features in The Coad Method/FDD can be readily compared to Function Points, it is easy to take these numbers and benchmark them against industry data. A Feature is at least 1 Function Point but probably averages out at about 1.5 FPs. In FDD you don't get credit for plumbing code but in FP counting you do. This is where the difference lies.

I think good average performance, and the numbers I would use for estimation with a new team, would be 2.5 Features per developer per week and a quality ratio of about 60 escaped defects per 100 Features. In both cases, "escaped defects" means escaped from "promote to build" into system testing, i.e. coming out of development. Numbers for escaped into user testing or field trials would be a lot lower. Velocity numbers are for the entire iteration and include time spent bug fixing - which isn't a lot ;-) [Teams with poor quality and long stabilization periods should have a low velocity.]

To achieve these numbers an FDD team must be reasonably competent at modeling, must provide 100% design and code review coverage and 100% unit test coverage. Though unit tests are at the Feature level - not at the method level as is typical in TDD/TFD. 100% coverage at the method level would naturally help, providing that the labor in creating the extra tests, does not impact the velocity. With very high quality FDD teams, I believe that they get beyond the point where 100% method level coverage is economically viable without automated tooling.

The standard deviation on Feature velocity can be quite small as low as +/-5% with a good team. The variance in Feature count, the "dark matter" ratio, can be as low as 15% per iteration. I believe that to get it any lower would be verging into "big design up front" territory. With an immature team and a new domain area, the dark matter ratio can be as high as 100% or greater - so plan for it.

Some immature teams don't execute on the Coad Method analysis very well. This leads to under counting of Features. I've seen this be off by a factor of 2. Hence, a team that thought they were doing 250 Features were really doing 500 Features. This can make velocity numbers look low. However, validating the numbers is pretty simple - someone skilled in the analysis method can simply examine the supposed Features against the object model and make an assessment. If each Feature in the business logic isn't leading to a single sequence diagram then the granularity isn't small enough.

The fastest speed I've seen over an iteration was 6.5 Features per developer per week with equivalent quality in the 3 defects per 100 range but it wasn't sustainable for a whole project. In teams of 1 or two developers faster speeds are possible because the project is small, complexity is low and communication bandwidth optimized. Speeds can be up to 20 Features per developer per week and sustainable around 10 Features per developer per week.

These numbers compare favorably with results for CMM/CMMI teams at Level 5 for quality whilst the velocity means that teams at American cost levels can currently compete favorably with costs in Bangalore. However, cost may be comparable but lead time and quality are both better. [Note: the industry, led by the SEI, does not generally collect velocity data though some is available - for telecom grade projects 25 Function Points per developer per month is the very top end of the scale.]

So the next time someone tells you how successful they are with agile development, ask them for their production rate or velocity and its variation, escaped defects to system test and its variation, and the dark matter ratio and its variation, metrics. Ask for the data to be normalized in Function Points (or Lines of Code - use a 100 lines of Java per FP as a typical conversion metric) and compare with my results for FDD. My data is from telecom grade projects done in Fortune 100 companies. It's non-trivial stuff and it was professionally tested by qualified QA departments. In one case, the test coverage was greater than 2 system tests per Feature. My team at Sprint can even recall a project which deployed into the Sprint network with zero defects found in user acceptance testing! It was a fine day when I received that "Thankyou!" email.

For me agility isn't about being a member of a club or simply having fun at work. It is about delivering better economic value. I've done that with FDD until last year and the results have been outstanding. Now its time to move on to MSF for CMMI Process Improvement and try to repeat those results with Visual Studio Team System in a .Net environment. It'll be fun to see what happens.

Before I get back to Ray Immelman's tribal ideas, I want to post just one final thought from my trip to Japan - Small Batch Sizes.

In Japan everything is sold in small batches - even bread is sold in one third and one half loaf sizes. Cereal is sold in 175g boxes. That's barely enough for 3 adult servings! Equally, milk in small cartons and so forth. The Japanese are used to the idea of making frequent small grocery transactions. The transaction cost is minimized by the fact that they are probably walking past the store on the way home from the train station. To buy in larger batches is inconceivable. The store couldn't afford to be any bigger because property is expensive. The buyer would need a car to carry larger amounts or to arrange for home delivery. She'd need but couldn't afford a bigger house with a large kitchen to store everything. Property is expensive. Japanese fridges are dinky little models design for small batches of food to fit in small kitchens.

Now compare this to America, where I know people who drive long distances to Costco to buy large batches of milk at bulk prices - to save a few cents, which pays for the gas they burned in the SUV to drive to the store ;-) The large batch of milk will disappear into the vastness of the fridge and if there isn't enough room then there is a bigger one in the basement or garage (normally stocked with beer) for the overflow. American culture is all about big batches and infrequent transactions, minimizing the transaction cost. Stack'em high! Sell'em cheap! For the home owner this can be great. I love being able to go to stores with large inventories and find exactly what I want, when I want it. But it is not necessarily good business sense. I think the size of America, its relatively low population density and its recent farming heritage make it prone to the concept of big batches. After all when you had to drive the horse and wagon 20 miles to the nearest store on a dirt track road, you didn't want to do it too often. Many people I've worked with over the last 5 years are either the children or the grand children of farmers with homesteads out on the great plains. Out there, big batches make sense. Big batches are embedded in the culture.

As I've gotten older I've become acutely aware of how my own upbringing and culture affect me and my thinking. It's not all good. Protestant work ethic is all very well but there is a dark side to Scotland's Calvinist culture that I have trouble controlling at times.

I wonder therefore how much American culture shaped traditional software engineering advice. Are small batches of requirements done in short iterations antithetical to American culture? Or is it just plain economics and our human ability to seek efficiency and optimize the transaction cost by reducing the number of transactions that encourages us naturally to want to make product releases too large, to want to do too much planning and too much analysis? Or is it something else, for example, my intellectual efficiency idea? Comments, please...