August 2010


I just found a great video about motivation that explains why self-organization works better.

I think this neatly shows why the very term “human resources” which implies treating humans just like any other machine in a company’s inventory is not only unethical and repugnant, but also simply wrong.

A question I frequently see asked on the Internet is whether agile teams should release every iteration (or even more frequently) or not. When asked in relation to Scrum the question is usually if software should be released every sprint. With other methods – like now-popular Kanban – the question is what release frequency would be right, as the method itself doesn’t say anything about it.

I think that many times this question reveals an underlying confusion between keeping software releasable and actually releasing it to the public. I think one construct from Scrum can help clarify things here.

Scrum calls explicitly for a “shippable product increment” to be delivered at the end of each sprint. It means that the end of each&every sprint a new version of the software must be ready that passes the quality criteria (in Scrum expressed as the “definition of done“) and ideally includes all the features the team committed to delivering at the sprint’s outset. However, this new version is called “shippable” not “shipped” for a reason. This reason is that whether to release a new version of software to the users is ultimately a business decision.

This distinction is very important. Just like the shape of the backlog is a result of a whole series of business decisions made by the Product Owner the decision to go with the product to the public is a decision that can be (and quite frequently is) made by stakeholders. As such it is definitely out of the scope of any process/method managing the development itself or the team doing the development.

There are of course numerous benefits from actually releasing each and every “shippable product increment“: greater user satisfaction, faster user feedback, better discipline in the team and less risk (deploying smaller changes is less risky than deploying a big-bang, all-changing release). In fact this is what we have been always practicing, also when working on our Scrum tool.

However it has to be understood that situations (companies, products, etc.) vary and can be very different. Sometimes there are other factors involved – for example domain (in embedded software releasing every sprint may not be even possible), market influence (eg. developing a major feature and not wanting to let on before it is complete) or alignment with other elements (like when software is part of a larger project, where other things have to be in place for the new features to be used or usable).

So, a team can be agile even if what they develop is not released every iteration. They just have to work as if it was in terms of quality and effort spent testing the software to ensure that it could be deployed when needed.

A friend sent me a link to a posting on the official Google blog that says they are effectively killing Wave. The reason given is lack of user adoption.

I think what it shows is rather Google’s failure to properly position the product on the market – or even turn the technology they have developed into a product. What they had was a potential Exchange killer – a system that could have been a real game changer in corporate communications as I wrote when it was unveiled. Instead of trying to get general Internet user community to adopt it Google should have packaged Wave as a corporate messaging/integration/collaboration system and market it bundled with support services to large corporations.

Someone else can still do this if they will indeed release much of the technology behind Wave to the public as open source code. Heck, maybe even Microsoft will adopt some of the concepts (and maybe even protocols) into their next release of Exchange/Outlook pair.

Still, this shows us Google is not immune from the problem of many great tech companies: inability to market great inventions. This has happened before many times – companies developed brilliant technology, but then failed to turn it into a product or market it successfully. Some didn’t survive it (Commodore, DEC), some did, but just failed to grasp a great opportunity (like Xerox for example).

So far Google still has its huge revenue stream from their basic product – pay per click advertising driven by search results – so failure to market Wave won’t hurt them. However, some research suggests ppc ads are declining in value as people learn to mentally avoid them (even if they don’t use the great Ad Block plugin as I do). So, dear Big Brother Google, better think twice next time before you throw away some great product in the making.