Andy's Mind

We have released a new version of our on-line hosted Scrum tool last week – the Banana Scrum. The most important addition is, of course, the automatic registration form, but we also improved the way in which the user interface works. We start to get ideas from our users, who generally like the tool but will undoubtedly help us make it better.

Which is good, since I think there is a definite need for a simple, on-line tool to assist agile teams in their work. Which leads me to another topic – resistance to any such tools. When someone asked about a tool for Scrum on the Yahoo Scrum group there was a bunch of answers advising not to use any tools – use a wall with velcro attached index cards or, at the very least, Excel.

Agile community in general and Scrum community in particular seems to be very attached to “good old” physical artifacts, like index cards, hand-drawn burndowns, hand sorted backlogs etc. I can respect that but I’m a completely different person – I’m a “paperless guy”.

The only thing I still prefer on paper is books. Hand drawn brundowns can be nice if everyone sits in the same room from 9 to 5, but we have a much more relaxed atmosphere – everyone has to be in for the Daily Scrum but otherwise people can work from where they want when they want. Whiteboard is great for sketching things or making notes during a meeting but I don’t think it is good to make it a permanent repository for anything. I think if we work with computers and systems and web apps we should use them. How credible we are telling other people our applications can save their business if we stick to index cards and velcro?

So, I don’t like it when some agile gurus look down us, paperless guys, when we confess we use software tools to manage our projects rather than walls, cards and boards. I don’t think it is a good idea to be too dogmatic about tools, I agree with that, but it also applies to the old paraphernalia of the paper age.

On LinkedIn someone asked this question:

How do you deal with the project requesters that are asking you for a project estimate before you get all your questions answered? Would you just ignore them and loose the project or go ahead and earn a client?

This is indeed a problem all of us in the software development business face. The question is indeed what to do in such a situation and it boils down to following three choices a service provider has:

• rip the client off – add all the uncertainties, add the industry standard 25% and produce a bid – then do it as fast and cheap as possible and profit – that’s probably what _most_ companies do,
• risk your money – to win the bid do all the above but not add 25% but rather subtract it, so that you’re cheapest thus winning the bid, then kick the project as fast out of the door as you can compromising on everything your client being ignorant in technology won’t be able to tell – namely quality (do spaghetti code, do it ugly, test only positive paths and forget unit testing etc.),
• tell the truth. That is – the client he won’t get anything solid with what he has, just lies, assumptions etc. However, for whatever amount he can spend he can get the most important features he needs with solid quality. If his site would be a success he can add nice-haves later on. Ask the client to make a list of them, discuss them, tell him that in one short iteration one or two will be up & running. Be honest and cooperative. It’s not a guarantee of success, but well… this is what this option is all about.

Everyone who is approached by such a client makes this choice. The problem is that typically such clients don’t like the third option, so they fall for the people choosing the other two. The results we all known – poorly designed sites, unmaintainable code or – worst – lost time and money.

What we follow is of course the third option.

Another project that we have been working on is now available for preview. This time it is a simple tool for managing the Scrum process called “Banana Scrum”.

You can log in to the preview installation by following this link and using the name “admin” and password “test”. You can play with the application as much as you want – it works on a copy of the test database that is regularly refreshed, so you can move and delete and edit whatever you like.

This project was born out of our frustration with ScrumWorks. It was the application we have used for the most of last year, because it was the only free and decent Scrum software around when I went looking for it in January 2007. However, it had many serious limitations, exorbitant pricing for the “Pro” version which added basically access rights for user (not needed for small teams IMHO) and was done as a Java app – a design decision I couldn’t understand, since there is absolutely nothing in there that could not have been done with an interactive, AJAX web app.

That is exactly what we did – our little Banana is done fully in Ruby on Rails, works great with most browsers and supports interactive features like in-place editing, drag and drop or a nice, interactive burndown chart. As of now it is pretty useful and – as it supports multiple projects – we use it for our own work.

We hope to add more features soon and possibly some day make it available to the world. If you’d be interested in trying it already – drop me a line.

As for the name… well, there was a competition in the team and Tomek Paczkowski won it (and a bag of bananas) with this proposal.

Yesterday we have decided to publicly show “Sprinters Search” – a research project we did at Code Sprinters in the recent month. It is a meta-search engine that attempts to provide the user with a short definition of the search term followed by unaltered results of a regular, traditional web search.

This project is a result of an idea that came to me last year. It occurred to me that today people are frequently using search engines not to find a well-sorted list of pages on something they do know, but rather they want to learn what a word or a name or a phrase they picked up somewhere (in a conversation, on the Internet, on TV etc.) means, what that is. Said well sorted list of pages helps only partially in getting the definition people are after. An attempt to provide a very succinct and correct description as a result immediately would be much better. Such a result could be followed with a traditional page list if the engine’s guess was wrong or the user wants to research further.

I thought that with lots of structured information now available on the Internet building something like that should be quite possible. After all, when current search engines were invented they were designed to parse just general web pages with no structure to them at all. Now we have all kinds of data and content bases that provide good quality information in a structured way. It seemed quite possible, so we gave it a try.

And here it is our fully working attempt at demonstrating that it is indeed possible. The aim was to provide – in most cases – a correct definition of the search term upfront, on the top of the page, possibly with an image, so that the user doesn’t have to scroll down or click through to get the definition he needs. I’d say for an early beta our meta-engine does pretty well – thanks in part to simple yet ingenious algorithms applied by Pawel Stradomski who designed that part of the code.

Of course, it is still just a research project. To make it robust and scalable resources we don’t have are be needed – much more computing power and fast storage + more time to fine-tune the algorithms. So for now we’ll leave it as it is – a good demonstration of our capabilities.