New graph tool from Google Labs: Books N-grams Viewer

A fascinating tool launched recently by Google Labs: N-grams.

It graphs the frequency of occurrence of the terms (words, sentences)  you input from the more than 5 million books (starting from 1500?) that Google scanned.
The tool is working best in English but other languages as Chinese, French, German, Russian, and Spanish (unfortunately not Italian) are available.

You could play with it for hours …

ReadWriteWeb has some nice examples.

N-grams for religions
Major religions of the world.

 

 

From zero to agile – iterations

I wrote in the past several posts around the agile software development and project management. Now I would like to dig deeper in it,  presenting which ones are the core agile principles and best practices, with examples from several models as scrum, Kanban or Lean.

The idea is to show how a hypothetical company could transition to an agile model from zero (either no process in place or a traditional / waterfall one).
The transition should be gradual (a big bang introduction of a new methodology is never a good idea), therefore introducing a new principle every week (the time frame can vary, it’s just an example).

The situation

You are a software house existing for several years and with some projects already executed and a couple of products on the market. Now you want to create a new product (or a new generation of an existing product) that will use a new technology (which you don’t know entirely) and the scope is also not completely defined (you have a network of partners which are supposed to use the product – a sort of platform, and everyone has slightly different business needs).

You have done a first analysis, you have an initial scope and a clear target (let’s say you used the methods described in the series PM).
You know that will take more or less one year for your development team and normally you’ve previously done your projects in a waterfall mode: first design and clarify all requirements, write the specifications, then develop the modules, test every module when completed and at the end integrate everything and perform a final system test.

Because there are risks in the project (scope and technology) you decide to use an agile approach that allows you to involve the partners in the development process and provide feedback to steer the project.

The iterations

Let’s start with probably the most important improvement from a traditional/waterfall approach: making the development iterative, which benefits I described previously.

Therefore you prepare a rough roadmap which will contain all the topics (high level requirements) that you want to develop in this year; remember that you should be able to adapt the path during the development, so you don’t describe them into every detail immediately (no big up front design).
The goal is to have a list of high level requirements, everyone with its priority (this is very important because you want always to know what is the next topic to work on) and a draft estimation, which are then laid on a roadmap which says when more or less the requirements will come (this is always requested / very much appreciated by top management 🙂

The roadmap / list of requirements should be divided into pieces (the iterations). Deciding on the iteration length is an art on itself: you can start with one length and adapt it when you proceed if you realize it’s too long or too short but you should try to keep the length fixed to allow the team to reach a rhythm.

Let’s say we start with monthly iterations, i.e. our year-long development will have 12 iterations.

[Link] A book will be a website with an API

An intriguing article by Hugh McGuire: The line between book and Internet will disappear.

I can’t agree more:

what is a book, but a website that happens to be written on paper and not connected to the web?
[…] the next obvious — but frightening — step: let books live properly within the Internet, along with websites, databases, blogs, Twitter, map systems, and applications.