This blog is moving

After several years using the Blogger platform I've decided to freeze this blog and move my writing efforts elsewhere. In the last few days I've tested several options, mainly looking at Wordpress running on Openshift. But I have found Wordpress a bit overkill for a simple personal blog, so I discovered Octopress.

Octopress is a framework designed by Brandon Mathis for Jekyll, the blog aware static site generator powering Github Pages. To start blogging with Jekyll, you have to write your own HTML templates, CSS, Javascripts and set up your configuration. But with Octopress All of that is already taken care of. Simply clone or fork Octopress, install dependencies and the theme, and you're set.

The main reasons for this move are:

1. Blogger has become slow and heavy: the preview takes forever and sometimes it doesn't show up at all
2. Octopress serves static files and can be quickly tested locally
3. I can use Git for pushing all my changes and I can rollback easily
4. I want to be in total control of the typography and html
5. My main domain and blog pages are all hosted on Github

Here it is: www.maurizioturatti.com

So, goodbye Blogger.com and thank you for all the blogging fish. Welcome Jekyll and Octopress!

The Brodzinski's estimation scale for a task

Pawel Brodzinski, lean and agile coach, suggests a good estimation scale for a task:

• 1: 1
• TFB: Too Fucking Big
• NFC: No Fucking Clue

Despite the fact this could initially looks like a joke, it's actually a serious way to handle too large user stories and, from my point of view, it's very close to what has been suggested by other agile coaches like Neil Killick (My Slicing Heuristic Concept Explained), especially popular within #NoEstimates practioners.

The idea, at least at high level, is very simple: slice down your tasks until they are all more or less of the same size (1 story point), then your final estimation is just a matter of summing the total number of stories. Of course, it's easier said than done: too many misunderstand the NoEstimate practice, dismissing it as just a way to avoid the "hard work", but in reality the slicing activity forces a very accurate analysis of requirements, to be able to slim them down to a common size. The easy part is the final sum, but that's not the point.

In my opinion this method suggests that, when somebody says a user story is 5, 8 or 13 points in size, this implies a good amount of delusion, because in reality going beyond a 1, 2 or 3 size is so close to pure guessing that it is usually a waste of time. Using only a single size (one) it's even more effective, because forces a serious decomposition of tasks: if you can't achieve this level of decomposition then you should acknowledge that your requirements are not clear enough yet: drastic, but effective.

A practical approach to this kind of user stories slicing could be Gojko Adzic's hamburger method, when adding the constraint that each task composing the hamburger must be of size 1.

Many years ago I did something vaguely similar in a project: I decided that every user story had to fit into a week and every Friday was release / demo day. Not exactly continuous delivery, but I think it was even before the term "agile" was invented...

Extremely Bad Advice for Remote Workers

As I have a long-term experience as a remote worker, also dealing with and managing remote teams in different timezones, I am always interested in experiences on this subject. Today I stumbled upon an article on TheNextWeb: 3 radical habits of highly successful remote teams. Despite the article seems to be nice with remote workers, it actually contains what I think are some of the worst possibile anti-patterns for remote work. In summary:

1. Total transparency about yourself with your remote team
2. Leave your webcam on all day
3. Replace physical space with software — lots of it

Let's rephrase the meaning:

1. I don't care about your privacy at all, so I want to know even when you are sleeping or pooping ("For example, every Buffer employee receives a Jawbone UP wristband that tracks how you’re sleeping and shares that with the team.")
2. I don't trust you at all, so I want to check that you are always staring at a computer screen, all day long ("This provides a persistent, passive view of your colleagues that makes you feel like you’re in the same room, working together at the same table."). So you are even required to broadcast you scratching your nose or your privates: I can only imagine the level of anxiety!
3. Additionally, I also want to mess up with your work by asking you to install, learn an manage a lot of different software doing, more or less, the same thing ("lots of it"). So that I can annoy you from even more different angles!

I, instead, suggest the following:

1. Hire people you trust and let them organize their daily routine and priorities
2. Adopt few, useful, simple software like Skype, Google Hangout and Slack for communication, Google Docs and/or Confluence for shared documentation.
3. If you want a social life go to the gym or to the pub, switching off your mobile email notifications. Get a life outside your work.

Managing a remote team like being into a modern edition of Orwell 1984? No, thanks. A remote, distributed team is not an assembly line: I suggest to move toward measuring people by the actual value they generate instead of the time they sit in front a PC.

A team made of knowledge workers must generate tangible value: if you can do that while playing tennis or having a shower, I don't really care.