Back from the Italian Agile Day 2008

It’s been a nice and hard day. I had two presentations to lead, and I wasn’t in great shape. But I think the overall result was not that bad. I just finished uploading the slides on slideshare (but they’ll be available also on the Italian Agile community web site). Here are the links.

Agile: il Piano B

Agile vs SOA deathmatch

Anyway, many ideas emerged on the related discussions... I guess I’ll blog about them for a while.

Italian Agile Day

Date for the Italian Agile Day 2008 has finally been defined! Needless to say, I am happy this will be again in Bologna. :-)
See you there!

Java IDE Day

Just a quick info post to inform about the Java IDE Day, which will be free, in Genova - March 10th 2008 and Rome - March 12th 2008 jointly organized by Genova Java Users Group and Rome Java Users Group. For more information, please follow this link. I can't say if I'll join or not, yet, but the panel seems pretty interesting anyway.

Tags: events, Java, Italy

Doing Agile In Italy: Paperworks

In the last Agile Day in Bologna we had quite a few demonstrations of how to make Lo-Fi tools (such as Post-it, StoryCards, etc.) work, to master an Agile development process. Fascinated by Tim McKinnon's presentation, I then went to a local office supply shop to find some tools to play with. Unfortunately, when I started describing Tim's nylon attachable pocket board, the girl at the shop started looking at me quite …oddly (ok… if I describe it this way, nobody could understand, except the few that attended Tim's speech, but I assure you I did my best. I also looked for pictures of "the thing" in the 'net but I couldn't find one – …maybe because I don't know the name).

Anyway, I went to the shop. And what I asked for seemed odd. There was something similar, like cork boards – in this case you need some pins to attach story cards to the wall – or something else that could contain, buy not show the story cards. I then shifted on Post-It papers. Which are cool as long as you have the right board to stick them on. They also have some drawbacks: since they're sticky, you do not write anything in the B-side (while you do that in story cards or CRC cards). I also bought some Super-Sticky post it. They stick everywhere. But there's a smaller choice of colors so it feels like you're in Coldplay's "Yellow". I felt a bit frustrated but also eager to try to squeeze the best from what I had.

In a couple of days I had a chance to play with my Post-Its. My task was to define a development process that was suitable for a SOA environment, agile enough to be productive, formal enough to be used in a Banking Institute. We started playing with our Post-It and … worked. We were able to spot contradictions and missing pieces in a very short time. Writing the document will be the long and tedious stuff, but I guess in this case it's unavoidable: agility still has to cope with the suit-and-tie mismatch.

Tags: Agile, SOA, Italy, Development Process

A prophecy come true

While working for the Italian Ministry of Internal Affairs, on a social registry data exchange application, we faced the topic of validation rules applied to birth names according to the Italian law. I challenged the application submitting "boundary values" for names, while studying the law. So I discovered that Obi Wan Kenobi is a legal name while 2Kool, D3PO or C1P8 are not. Chewbacca is fine. Giulia and Julia are both allowed, while Juli@ is not. As always, anyway, the Italian law is open to different interpretations, cause it states that you can't give ridiculous or shameful names to your babies, but avoids to define what is exactly ridiculous or shameful.

Colleagues looked at me in strange ways (it often happens), but today I've got the proof that my concerns were right, somebody in China tried to call the son the name '@'… Read the Article (in Italian).

Tags: software development, Italy, humour

Doing Agile in Italy – part II

To my surprise, the previous post about the influences of job market regulations on agile development in Italy has been cited in an InfoQ article, and had a couple of interesting comments. This glamorous parenthesis happened while I was on holiday, and my Inbox was dangerously inflating. So, after getting back to work and diligently processed all of the issues waiting for me, here's the second part of my post.

The "too much process" rebound

Be it for our latin nature, be it the average size of projects and companies, I've never faced a situation in which "too much process" or "too much paper" was an issue. There can be a correlation with the Italian job market issues presented in my previous post, in the sense that structured processes definition were meant also as a way of protecting the project from turnover, by making everyone a "replaceable part" of the process. Agile practices lowered the process burden, and put the emphasis on individuals implicitly stating that the best way to handle turnover is to have no turnover at all, thus putting some effort in transforming the team in a nice place to work in.

The average company, has instead sort of a "raw" development process instead, and spoken words prevail on written ones. Given this scenario, I feel like I am a sort of "fake agilist", because many times my job is not to strive for a thinner process definition, but just set up a process, whatever it might be. I also think that one needs to start from something structured, to acquire degrees of freedom later: as an example, even if I fancy the "user story" concept a lot, I seldom use it in undisciplined contexts, and favor a more traditional use case approach. Once you master use cases and are able to distinguish the key parts of the specifications, you can benefit from a less structured and more distilled way to express them. Doing otherwise will probably result in a "blank paper syndrome".

Letting the kids play

Apart from careful people selection and the job market issues discussed here, the single most effective team motivator is probably the introduction of a new "cool" technology in the project. This approach is particularly effective in situations where the technology scenario is particularly flat. Once, I've found myself pushing for a technology change, and the only real reason for it was to have something new to "let the kids play", and to have a motivated team. Of course, there is a limit to the number of new concurrent technologies that a team can master simultaneously, but a "technically boring" project breeds low motivation, and turnover (so you have learning costs anyway) and productivity tends to flatten in the long term.

Tags: agile, software development, Italy

Doing Agile in Italy

During the latest JAOO conference, Alistair Cockburn deliberately provoked the audience stating that "we can't do agile in Europe" and this was due to EU regulations for contracts, which have to be filled with the requirements of the software to be developed by a contractor. This was a serious issue also, because in this case the law (unconsciously, I suppose, unless there is a powerful waterfall lobby in Brussels) poses a serious constraint on the development process. A contractor has to face the fact that requirement discovery in an agile fashion might drive the development team out of the officially signed project goal, some might go for a more ambiguous contract (but the customer has to agree on that, and this is not a piece of cake, especially with new customers), some others might require more paper to change the project scope (but this doesn't agile), the latest option is to take the risk and be "paperless" for a while.

Setting up an Italian development team

In Italy we have also some peculiarities related to the job market, which have some interesting effects on the way software is developed. I remember an old yet interesting article by Steve McConnell, dwelling on the notion of "problem programmers" meaning programmers with a negative impact on productivity. In other words programmers which are normally unable to finish assigned tasks, who need external help to finish the tasks, whose tasks needs extra cleanup work afterwards or which are sucking time an productivity to other members of the team. Put in this way this sounds somewhat scary, but it's not infrequent to meet such a beast. McConnell has only one solution to the problem: get rid of the problem programmer as soon as you can, which goes to a small set of options:

1. Resolve the causes for him/her being problematic
   
2. Move him/her to another team (hoping that this is a variation on option 1)
   
3. Fire him/her before the damage is too big
   

In Italy we can't fire. Job market regulations make firing an employee a very long nasty and complicated process, and 99% of the cases a non-viable option. I mean, in some places, you can't fire somebody even if you found him stealing (which puts the problem programmer in a much better light). The average Italian solution to the problem (there is always an Italian solution) is to go for temporary recruitment, hiring programmers from body rental companies, the third millennium version of mercenaries. Unfortunately this option has some drawbacks.

1. In many cases you have less control on who you are hiring. Even if I've seen pretty bad recruitment strategies in many places, being the one to choose who you are going to work with it's still a recommendable option.
   
2. You'll have less control on turnover issues: people might leave the company which hired them (and your project) for reasons which have nothing to do with you.
   
3. You have less control on motivation, you can't do much to improve it (at least on the salary side, you can do a lot, and probably more effectively on other aspects), you can do a lot to destroy it (with bureaucracy, holidays management, etc.).
   
4. Being hired by a third party is often a treat to motivation per se. One might ask "why doesn't this company want to actually hire me?" and feel they are just a replaceable part of the process, which helps them feel less guilty the day they'll decide to leave.
5. Last, but not least, the control chain sucks money. So the sub-employee is also usually sub-paid compared to the official counterparts.
   

So you generally end up with external teams with potentially lower motivation, or internal teams with people which tend to "seat" on a safe job, without being challenged for a while, and that need "something to do". I don't really want to end up arguing on the ongoing political debate which is going on in Italy these days on the topic, and please don't derive conclusions on my political orientation from this article. If you have to achieve high productivity from a software development team the best way is hire the best people, and get rid of the problematic ones. In Italy is hard to do both, so the net result is that you have to squeeze the best out of the existing team, which is sometimes …challenging.

Tags: agile, software development, Italy