CamelCase

Pawel Brodzinski, lean and agile coach, suggests a intriguing 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...

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:

»

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Frederick Brooks, The Mythical Man Month.

Less than a year ago Oracle announced the Java EE and GlassFish Server Roadmap Update, which defined the end of commercial support for the Oracle Glassfish Server , which is (was) the fully supported release of the GlassFish Server Open Source Edition. In the last few months there has been plenty of comments about this move, some of the most remarkable are:

• GlassFish reduced to “toy product” as commercial offering axed
• GlassFish Commercial is Dead, WildFly and JBoss EAP to the Rescue
• Oracle removed GlassFish plugin for Eclipse

The motivation around this move are probably about Oracle not being keen on supporting two full app server implementations, Glassfish and Weblogic, which apparently makes sense from a commercial point of view. The problem here is that the two products are very different, and if you liked Glassfish usually hated Weblogic (but has somebody ever genuinely liked Weblogic anyway?). Glassfish is a lightweight, easy to install, fast to start, open source product, with a community around, while Weblogic is IMO one of the most bloated piece of software ever: the two products were addressing two very different Java EE markets, being Weblogic's the most lucrative one.

»

I have just published the below presentation on Slideshare: half it's serious content, half it's just for fun.

Some of my best friends are present or former colleagues, most are developers but many of them are sales or marketing people. I was thinking about describing the often difficult relationship between software developers and sales people since many years now.

I am lucky I had the opportunity to work with very smart people, both on sales or IT, with the exception of some occasional moron, of course.

Hopefully you can recognize some common, funny pattern in the slides below.

»