This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Tuesday, October 24, 2006

Another interesting Agile Finland Seminar

Yesterday another
Agile Finland seminar was held in Helsinki. There were 3 speakers and the guest star of the day was Tom Gilb.

Tom has been working in this field for many years and pitches himself as a precursor of the agile movement. He mentions "iterations" as something that he popularized in one of his books.

Tom stated that current agile methods lack quantification and that's why his own proposed XE (as in eXtreme Engineering) is better. In his method he adds a few things on top of a normal iterative process like scrum (weekly iterations, weekly one-page, status reports) but most importantly he adds the requirement for "quantitative" requirements. He basically said: "if you cannot quantify your requirements you cannot know if you are achieving them". He pitched quantification as the key aspect of the XE method.

In the Agile community we have not discussed quantification and scientific analysis very much, in my opinion this is something that will become more and more important in the near feature.

Macs taking over the world?

It was also nice to notice that a lot more Macs were visible in the auditorium, previously we had seen only PC laptops but now I only saw Macs everywhere (with one exception), could this mean that Macs are becoming the tool of choice for IT professionals? Certainly there are more and more reasons to do it. With most of the tools we use daily moving to the web or a hosted version you become tied only to your browser, not your OS. As a side note it is also worth to note that of the 3 presenters 2 had Macs!

All in all a very nice seminar that was followed by a lively discussion in a close by restaurant that was certainly happy to get the extra business from the agile crowd! :)

at 10:45
RSS link

Bookmark and Share

3 Comments:

  • Vasco, can you explain a bit about what Tom Gilb means by "quantification?" What is it that he thinks is "missing" from agile in that regard?

    At our company more and more people are choosing Macs. I've been using a 12" PowerBook G4 for about a year now, and it's great for presentations on the road because it's so small. Also, the power supply is already enabled to handle foreign power sources. All you need is a set of adapters and you can plug in anywhere with no problem. Recently I got one of the Intel-based Macs, thinking that Parallels or Basecamp would enable me to get rid of my last remaining Windows box, but unfortunately there are still some functional limitations in those products. Too bad they can't make an Intel Mac as small as that 12" PowerBook.

    By Anonymous Dave Nicolette, at October 27, 2006 4:48 PM  

  • "Quantification"

    Tom Gilb stated in his presentation at the Agile Finland Seminar that Agile methods lack quantification and that's what's wrong with them.

    Of course that's not really true. Agile methods do not prevent anyone from quantifying their requirements, and Scrum in particular does not even state how you should collect and evaluate requirements. Quantification of requirements is something that is needed and should be used also in agile projects.

    With Quantification Tom meant actual quantification of the requirements, even non-functional ones. Example: "Better usability". What does usability mean? You decompose it into metrics you can measure like for example: "how many people can save a file in word in less than 10 seconds after writing a phrase?"
    After you define what usability means and how it can be measured you go and measure it to verify that the requirement was achieved.

    By Blogger Vasco Duarte, at November 03, 2006 9:49 AM  

  • Thanks for the explanation. IMO it makes good sense to quantify requirements. I agree with Tom about that, but I agree with you that there's nothing about agile methods that prevents us from quantifying requirements.

    By Anonymous Dave Nicolette, at November 14, 2006 2:26 PM  

Post a Comment

Links to this post:

Create a Link

<< Home


 
(c) All rights reserved