Why Apple deserves to sell many iPods/iTouch (or Why MUST features will kill your project...)

So lately I've been trying to convince some friends that they don't want to have "MUST" features in their project, rather they should opt for a force-ranked prioritization of all features that they want to deliver.

First off, I must explain this idea. You do still have a minimum marketable content for your product. If you are delivering a text editor that might include being able to write text, saving in UTF-8 or localization into Finnish (if you happen to want to sell your product there). There's nothing wrong with wanting a minimal set of functionality before you release your baby to the cruel world out there.

Having said that, there's a huge different between defining a minimal releasable content and having MUST features.

For starters the "MUST" state of mind normally leads to having MUST features that are not at the top of the list of things to do. You will say to yourself that you have to do this architectural change here, or improve the UI for another feature over there. But you will release that super-duper MUST feature even if it is like 40th on the list of 80 things, of which you can complete about 20 before the competition outruns you... Stop kidding yourself!

If it is a MUST, then it is the first on the list, no exceptions. At any point in one project there's only one and only one MUST feature -- the one you are working on! And even that can be scoped-down to suit your market-driven deadline. This is so that if your market changes, you can respond quickly and release a new product ASAP.

You will have certain features (maybe 1 or 2) that you will not be able to release without, others can be greatly de-scoped to make you release faster.

A good example was Windows XP. The first layer of the UI was great (compared to Win98/2K), but when you started digging around you saw that the second and subsequent layers were just the same as in Win2K. XP was supposed to come out faster, so they did not polish every single nob, they went for what made sense: faster OS and better looking first impressions.

Another example was Nokia's Ovi. They started with an empty website! Later they added Share.ovi.com and eventually went on to build the entire portofolio -- they understood time was not on their side!

Some people would argue that, you still need MUST features even if they make you delay a product release, that those MUST features are worth it because (aledgedly) they are so important that we could not sell the product without those. To those people I say: really? Did you know that 64% of all features in software products are "rarely or never used"? When was the last time that you used voice recognition on your windows box? Or when was the last time you tweaked all the settings available in Windows?

The fact is that we need to be "Editors" of our software products. There are very few things that make people buy our software/hardware products (Rio vs iPod anyone?), and those are the only things that make sense to build in the first place.

Now, you will hear from many companies the idea that "no, we need to build feature X before we release!". That's just dumb! While you spend precious time building those features your competitors will be laughing all the way to the bank!

For those of you that may not believe me here's an example: Windows Mobile has had most of the features that the iPod/iPhone has today and much more that iPod and iPhone don't have. However the iPod/iPhone are selling at a much faster pace that Windows Mobile, why is that?

After all Apple did come from behind and for the iPod Touch started from scratch (compared to WinMobile which is quite developed and stable platform and was already when Apple started to work on the iPhone/iPod Touch), and Apple had to develop their own Hardware! How come they provide a better product that WinMobile?

The reason is simple: Apple did not cram the iPod Touch with features, they went for the 20% that satisfy 80% of the customers and used their delivery system to deliver new features later. They did not wait on their asses until they had a similar feature-set to the WinMobile. Heck they even missed the mobile e-mail boom with the MobileMe debacle!

The reason for Apple's success was simple: release the product at the right time and put money where in pays: in top-quality marketing!

There were a couple of MUST features in the iPod/iPhone that they had to get right before their release, but the most important feature was: release date! If you are as good as Apple at marketing your products, you can even charge your early adopters extra to get basic applications that all other mobile devices already have (iPod Touch update for money to firmware 2.0).

There are many features that you would consider MUST that were never implemented in some products, but those products were successful anyway! (3G on the iPhone 1?) The people designing those products understood that what made their products successfull was not that extra set of features. It was a completely different set of constraints. In the consumer market, things like visibility (placement, marketing, channel) or price have a far larger impact on the success of the product than many (i'd say maybe even 90%) of the features that get added to those products.

When you start a project, decide which are the economic drivers for your product: do you want to hit a market on a set date? Do you want a pre-defined set of features? Do you want to use a certain channel? Ask yourself what is important before deciding to use "MUST" features. Don't shoot yourself in the foot just because you didn't spend 5 minutes thinking about what makes your product successful.

The thing you always wanted...

... Running Quake 3 on your Nokia mobile phone! Your commutes just became fun!

The Skill issue, the industry shame

I was reading Jason's blog when I came across this post. I could not agree more.

Way too many times I bump into problems that can be traced directly to the idea that you can hire just anyone, with any skill level and they will perform to the expected level of professionalism. This is pure bulls#%&!

Some time ago (just before the bubble burst in 1999) a company I was familiar with was hiring QA people just because they knew how to boot Windows. Yeah right! Way to go!

We also see the same with people putting together teams that behave like a set of individuals all pushing in different directions because "anyone" can be a manager! Stop believing in magic. You don't get a high performing team if you don't have a proper leader in the team (the leadership can be shared BTW, no need for a "hero", in fact that's sometimes worse). Start coaching the team and them make them understand how to work together!

If we put these two things together: hiring coders and testers that have no skill, and promoting people to leadership position that have no leadership skills what do you get? You got it: our software industry!

Can you believe it! This type of behavior and belief is rampant in our industry. Small wonder that we will be seeing lots of people being laid off in the near future...

PS: if you are smart and really good at what you do (testing or coding), you are better of these days starting your own consulting company, charging bucket loads of money and getting out of there once you are fed up with the local incompetence!

Beware of the ignorant consultants, beware of LAME

So I was listening to the OnSoftware podcast (which is, by the way, a very bad podcast, so bad I'm not even linking to it!).

In one of the latest episodes (actually 2 episodes) Jean Tabaka was interviewed. Jean now works with Rally Software and apparently (according to her, in that podcast) is facing the change of focus from Agile to Lean when she meets with top management at different companies she consults with.

So far so good, the real problem was when she started to describe what she thinks Lean means. She got it all wrong!!!!

Here's an example. She says that Toyota's Production System was started to be developed in 1950's when Toyota people went to the USA to learn how to produce cars: Wrong! Toyota's production system roots go back to the years when they were still producing looms. They did visit Ford and GM in the 1950's (and other American companies) interested understanding how the Americans were manufacturing and managing the manufacturing process. But that was long after they faced on the the founding moments of Toyota's philosophy: the 1930's near bankruptcy that shaped their commitment and respect for people.

When visiting America Toyota were especially interested in the way that Ford were producing cars and managing their factories. They were led there by Henry Ford's description of his ideas about mass production in the book Today and Tomorrow as well as by the concept of "supermarket" which led to the ideas behind reduced inventory and Kanban.

So, Jean please learn your history before you go and talk to leaders at the companies that hire you (and for a high price I bet!).

But the mistakes did not stop there. Jean correctly traces the start of the Lean production method in Toyota to Taiichi Ohno (he was not alone however!), but calls him a consultant that was sent to the US and then back to Japan to teach Toyota about the production methods from the US: Wrong again!

The actual transformation in Toyota started with the Toyoda family itself! It was Eiji Toyoda that went to the US and upon his return gave an assignment to Taiichi Ohno who was at that time an Assembly Manager (not a Consultant BTW Jean!)

Then Jean makes it worse! She states the changes in Toyota's implementation of the Ford (and American) production model were due to the "waste and bloat" that they saw in Ford's method. The waste and bloat that Jean talks about was there, but not for Ford -- only for Toyota. The fact was the the Japanese market was tiny compared to the American market, Toyota did not have the luxury of producing massive amounts of 1 or 2 models (very few in any case). Toyota's market was much smaller and fractured. They needed to learn to produce many models in the same manufacturing line to allow them to change the production mix at all times (to respond to market needs) and that was what led to their transformation of Ford's ideas. Not the bloat and waste they saw! Indeed the early TPS implementers admired what they learned during their visit to America in the 1930's (i.e. before World War II).

However, some of the techniques that were used in the TPS (Toyota Production System) were older than that. Already Eiji's uncle (Sakichi) was building automated looms with some of the techniques that were later to be a key part of the TPS. An example is Jidoka, Eiji's uncle had invented a method to stop an automated loom if one of the threads broke during operation. This allowed one person to supervise many looms and increased tremendously the productivity of factories with the Toyoda Looms.

Then Jean goes on to talk about the "seven principles of Lean", there are no "seven principles of Lean". Seven was the number of principles that Mary and Tom Poppendieck defined in their book Lean Software Development. What Jean should have said was "seven principles of Lean Software Development", but she would not do that because her idea is to sell "Lean" to upper management and clearly separate it from the "software" word.

In fact "Lean" was the word coined by Womack and Jones in their "The machine that changed the world" to describe the focus on the removal of waste they saw in Japan. Womack and Jones enunciated 5 principles that describe Lean, but in fact the Toyota Production System (TPS) is much more than that. TPS was later exhaustively studied and described by many people, among whom Jeffrey Liker is one of the most well regarded authority at this point in time.

Value and Waste

Jean goes on to talk about Value and Waste, she is very superficial in her definition of Waste, which plays well with the equally superficial view that many top managers have on Lean (and therefore it's terminology).

When talking about Value vs. Waste Jean completely forgets the key distinction between the two: the customer. In Lean Software Development (as in Mary and Tom's work) and TPS the customer is the one that decides what is value (and therefore what is waste = not value).

Mary and Tom Poppendieck have done a very good job of making this clear in their talks and presentations. It is the customer that defines what is value or waste, not the people inside the organization.


Later in the podcast (which has two parts of 6-7 min each) the interviewer asks about how to "sell executives on Agile" with "Flow pull and innovate", and describes those as words from Lean, this is obviously wrong. Flow and Pull are part of Womack and Jones' work, but "innovate" is just another buzzword added by Jean to "shape" the marketing message.

Then Jean goes on to define "lean thinking" with 5 principles is a higher level extraction of Lean. What does that mean? Please stop with the marketing already!

"Lean thinking" is another book by Womack and Jones that tries to describe how to implement a "Lean Enterprise". If you want to know more about Womack and Jones' work you are better off going to the Lean Enterprise Institute than listening to Jean. In fact, when in comes to Lean DON'T listen Jean, she clearly does not know (at least yet) what she is talking about.

A Critique of Womack and Jones' five principls

What Jean (and many others for that matter) don't get is that Womack and Jones' work is eminently practice-focused, as in "how do I implement this?" to the extent that we could even say that it is focused on answering the question "how do I implement this even if I don't understand it (nor do I want to)?"
This was of course, not the intention. But when "The Machine that Changed the World" and later "Lean Thinking" were published that is how it ended up to be.

In this context we have to be critical of the use of the word "principle" together with "Flow and Pull". Flow and Pull are just instances of the expert implementation of TPS (as opposed to "Lean"). Pull is implemented as a combination of Just-in-Time and Kanban practices (and others), and it's goal is to achieve even (sustainable in the Agile terminology) workloads which lead to less variability and hence less rework and overburden which are some of the wastes identified by the TPS creators and also described by Mary and Tom in their Lean Software Development book.

Flow is what is achieved by combining several techniques, including Pull.

The 5 principles

Womack and Jones describe Value Stream, Flow, Pull and Pursue Perfection as principles, but that is considered a narrow view of TPS by many in the Lean Community who look at the work by Jeffrey Liker and others as a much better description of what TPS is. Liker focuses on the "whole" of the TPS, not just it's tools and practices and goes on to describe that the 2 fundamental principles that Toyota themselves apply in their implementation of TPS (especially outside Japan) are "Respect for People" and "Continuous Improvement"

Conclusion

In the Lean Community Mark Graban has done a good job at describing what he has seen in manufacturing as Lean implemented without depth. He calls it LAME: Lean As Misguidedly Executed. What Jean did in that podcast is LAME also: Lean As Misguidedly Explained.

Jean has done some good work in the Agile Community it is down-right scary to see someone that is engaged and understands Agility use Lean as a marketing trick and not even going through the effort of understanding what she is talking about.

It's a shame.

References

• A fairly good article in Wikipedia about TPS.
  
• The Toyota Way, by Jeffrey Liker. Highly recommended to anyone interested in the "real Toyota Production System".
  
• Lean Software Development, by Mary and Tom Poppendieck. Highly recommended for anyone in the software industry. Mary and Tom have real-life experience with Lean. Mary's account of her work at 3M is enlightening and a very good insight into understanding lean
  
• Toyota's web site, full of stories about the TPS
  
• An article by Time Asian about the history of Toyota
  

Agile Finlandissima is organizing another great gathering, don't miss it!

Agile Finland will organize another cool gathering for the community. This time we have Marko Taipale and Jeff Sutherland plus a cool dinner with the most agile people around in the country!

Check out the announcement and registration form

Note to self, use more simulations...

Great simulation description by Elisabeth Hendrickson, and I've got great first-hand feedback from this simulation. I can't wait to see it live!

Check out the post here.

The next step, Agile hungover

So, it is starting to happen. All around us we see people like James Shore or Rob Bowley proclaiming the end of Scrum, that we don't really get it and that many teams do cycles, but forget about the rest.

If you have been following the different waves of software process adoption this should be no news for you.

However, there's a twist. If you have read about the Auto industry and it's woes and have read about Lean (as in manufacturing, not as in software development) you know by now that no process can save you, except one: PDCA (Plan-Do-Check-Act). The learning process.

In the software industry we are starting to see now the same signs that Lean consultants and commentators saw in the 90's in the car industry. A couple of people wrote a few books (like The Machine that Changed the World) and the Auto industry management started blindly copying the practices that were described in the book. They forgot to read and learn from the masters like Deming or Taiichi Ohno, and -- most importantly -- they forgot to use their brains. And then boom! 25 Billion USD bail out plan because the stupid management in the three big ones did not take the trouble to learn!

The same is happening in the software industry if Jim and Rob are to be believed, and there's no reason to doubt them. After all, it is human nature. People want a fast, short and painless way out, so they'll got for the cargo cult every time.

That leaves us, Agilists, with a big responsibility -- develop our practice. Understand how to make people use the most important principle of all: Learning! Practice the PDCA cycle -- the only cycle that really, really, really matters.

I said it before and will say it again: Let's not fall in love with Agile, let's fall in love with improving our industry!