This blog has moved. Go to for the latest posts.

Monday, December 15, 2008

(Don't) be evil!

It seems that Google has lost the "don't" from their slogan.

Incredible, it takes only a mild recession for Google to lose all of their ethics!

Google has asked the Internet providers for preferential treatment! Shame on you Google.

PS: I've backed up the blog! ;)

Labels: , , ,

at 08:57 | 0 comments
RSS link

Bookmark and Share

Sunday, December 14, 2008

The Law of Disproportional Consequences

Why this title? I wanted to describe this idea that in software it is far harder to develop the right things. Yet the impact of developing the right product is disproportionally higher than incremental improvements in the way you develop an existing product.

If you look at the history of software companies this is quite clear. Google, Microsoft, Apple and other giants in the software world today were created by a pair of kids in a garage (literally). This is the positive Black Swan that Nassim talks about in his books and a clear indication that in software it is "what" you develop that matters, not "how" you develop it!

The consequence of understanding and taking advantage of this law is that software companies should be spending a lot more money creating products that "fail" than they do now. Just think about it. If Google did not have it's "labs" would they be as successful as they are now? Almost all of their cool/hot products came from the labs.

How about Apple? If they did not have a crazy guy like Jobs at the helm would they have invested in such complete departures from their original business like iTunes or the iPod?

For a company like the one where I work now, this means that we should be creating ideas about new products at least at the same rate that we create incrementally new products. If we get a 10% success rate with this approach we can be 10/100 times better than what we are now!

In Software there is a law of disproportional consequences, period. The question for us is can we take advantage of it?

Labels: , , ,

at 23:41 | 0 comments
RSS link

Bookmark and Share

Estimation is needed but useless. Do it and throw away the numbers!

I've discussed this idea a few times with some friends, but I'll concede that the ultimate argument for stopping to estimate altogether is still to come...

In the meanwhile here is more food for thought.
Rob Bowley argues why estimations are bad in software development.

My favorite part of his presentation:
[In a study discussed in Peopleware by Lister and De Marco, it was found that "the highest [software development] average productivity was on those projects that didn’t estimate at all."

Labels: , , , ,

at 23:35 | 1 comments
RSS link

Bookmark and Share

The reason why top managers should questioned and challenged by us, the Lego edition

For many people that have read about the Toyota Production System (TPS) the image of Toyota has been improved and their willingness to buy a Toyota car has been positively affected (heck, I _want_ to buy a Toyota, I just can't justify buying a car).

But how about reasons not to buy a product from a certain company? What if I told you that management is so incompetent that they outsourced the manufacturing of their core product to a company that had ZERO experience in building that product?

What if I added that this company planned to fire 900 of it's best employees just because they happen to leave near the company's headquarters which is a more expensive location for labor?

I'm guessing that by now you would be saying: "Maybe I should not buy any products from this company anymore..." And you would be on to something there...

But things get worse. The management of this company invested themselves in this outsourcing process with the help of the clueless McKinsey, only to back down and remove all ideas of continuing with the plan. Do you think that management's bonuses were affected? or even that management got fired? Naaah, that would be too logical...

As you guessed, the company is LEGO, and the devastating account of this blatant management incompetence is at
Evolving Excellence blog.

Labels: , , , ,

at 23:07 | 2 comments
RSS link

Bookmark and Share

The Toyota Way in the clothing industry, examples to pay attention

If you have been following this blog, it is no news for you that I'm a big fan of what is known as
Toyota Production System and it's ideas as described by Jeffrey Liker in the famous "Toyota Way".

What you don't know is that I'm a big fan of many other companies that exhibit some of the same characteristics. How about this one: this is a clothing manufacturing and sales company that pays it's employees above minimum wage, is located in one of the most expensive states in the US (California), and has grown 40% last year, and still takes environmental sustainability pretty seriously!

The key here is that clothing manufacturing is an industry that has been heavily de-localized to India, Mexico, China, etc. And here is a company that competes with this cheap labor competitors and still manages to turn a handsome profit!

The company I'm writing about is American Apparel and Kevin Meyer from Evolving Excellence has an excellent description of a recent visit he made to American Apparel. Check it out!

Labels: , , , , , , ,

at 22:51 | 0 comments
RSS link

Bookmark and Share

Saturday, December 13, 2008

The "it's not my bug" anti-pattern

Talking to a friend we were discussing the organization of feature teams in a local company.

They were previously organized in component teams, which led to a lot of inefficiencies and disconnected work. This happened because one team would only work on one component, and when one feature required work in many components, that feature may not have been finalized at the end of the sprint, as one of the teams may have been busy with other work.

This highlights one of the problems that is common with component teams, they do not allow for an efficient allocation of work, as the dependencies increase between independent teams. You may still want to organize around component teams, but not if your goal is "efficiency".

But the anti-pattern that we talked about is actually when you have feature teams. If you have feature teams you will be able to assign one backlog item completely to one team, thereby reducing the dependencies between teams and potentially increasing the throughput of your program/group/unit/company.

However, there's a catch (there always is). You need to be explicitly clear about who fixes the bugs when nobody else wants them. The problem is this: when a bug is discovered during one iteration, it is likely that many teams may have touched the component that is the reason for the bug (assuming you can trace it). So, who takes it?

The anti-pattern tells us that the teams will *all* say that it is another team's code that is causing the problem, and nothing gets investigated which leads to many bugs crossing the iteration line and that should never happen.

How to solve this problem: you should state explicitly which team takes *all* the bugs under investigation. That way if the teams cannot agree on who takes the ball (in a Scrum of Scrums, say) there will be a clear owner for the investigation and potentially the fix.

Normally this would be the team that is assigned to "maintenance work" during that sprint, but you can decide otherwise if the maintenance team is too busy.

Labels: , , , , , , ,

at 09:32 | 0 comments
RSS link

Bookmark and Share

Tuesday, December 09, 2008

Nokia goes agile. Will the rest follow?

Ari Jaaksi from is blogging about Scrum in Nokia's Linux/Open source projects.
Also, Juha-Markus Aalto (of Object development fame) presented what I would call the "Nokia Agile Requirements Model" (and what Dean Leffingwell calls "Lean, Scalable Requirements Model") at the Object days in Tampere. See the slides here(PDF alert).

With all of this I can only say that Nokia is an exciting place to work at if you are interested in the improvement of our industry!

Now, if only the other Finnish software organization would start following the lead... Yes, you know I mean also the Banks, the Post office, the Tax office and the agonizing slow adopters that are the big consulting firms.

If others start to follow, Finland can become the most exciting place for a software person to work, even better than Silicon Valley!

Labels: , , , , , ,

at 00:40 | 2 comments
RSS link

Bookmark and Share

(c) All rights reserved