Andy's Mind

To make my life easier with introducing people to Scrum I did prepare a short presentation. You can view it here.

And, BTW, I’m happy to report here that a new version of our Scrum tool – Banana Scrum – was released last Friday. Development is still going on, even though I can only put people who are not engaged in other projects on that work.

Right now I decide we’ll do a sprint concentrating on “cleanup” – mostly features or development that aims at improving overall usability and compatibility with different browsers. Even though IE 6&7 + Firefox + Safari work flawlessly we had some problems with Opera.

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.