Andy's Mind

It is always with amazement that I find looking at my statistics, that the set of key words that brings most of random visitors to this humble blog is “Dilbert Scrum”. This is so ever since I’ve commented on an episode of Dilbert in which agile is mentioned. Based on it I’ve moved on to discuss Scrum – and probably no one else did exactly that, because if you type “Dilbert Scrum” into Google that post of mine is now number 1. I suspect this post will strengthen that effect.

Interestingly, I’m not sure Dilbert ever referred to Scrum directly but even so people think he must have – so they look for it. Also, this shows that people want to find an image, not a text. Texts are boring, you have to concentrate (which is hard) and think sometimes (which is even harder). Images are much much easier. Which is, probably, why Dilbert brings so many visitors to my page who come for only one thing: the link to the comic strip (BTW: It was wrong, I just fixed it).

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.

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.

Some folks started an inter-blog discussion about why enterprise software is mostly bloated crap. The theories put forward range from a meaningless observation that enterprise software “is not sexy“, through really funny stuff like George Ou lamenting that they are typically not done with “lightweight” languages like C++ but instead with “programming shortcuts like Java” to gloomy statements that it has to be that way since it’s enterprise software – so what else could we expect? Nicholas Carr posits that solution might be in doing enterprise software as web applications (exactly what we offer), which sets him apart from the others. But even that voice included some key elements are missing from the corporate IT experts prospective: who produces enterprise software – and how.

I think you can’t understand why enterprise software mostly sucks by not taking into account that it is the area where most projects are done with ineffective waterfall methods under heavy bureaucracy of traditional project management methods inside corporations. SAP implementation, for example, is mostly expensive consultants doing all kinds of paperwork and producing tons of specifications before any programmer does anything.

All that further amplifies the already bad effects of developers working in a corporate environment (like at SAP or Microsoft), usually not very dynamic, with limited upward mobility and very limited influence a single employee can have on a product. Adding long release times, extensive paperwork and removing any link between developers and clients has to kill any excitement and emotion developers have for their work. Without it what they produce must be crap.

Not that clients or producers of these overpriced beasts care. Clients got educated through their lifetime that enterprise software has to be hard to use, buggy and expensive. Producers are more than happy to earn huge profits from cheaply made products. Until the clients won’t start to ask for more not much will change here.

During the Agile Development Practices conference last week Mary Poppendieck announced that agile is now mainstream. Well, apparently it is not mainstream enough yet for the IT experts I mentioned above – or for the enterprise systems buyers. But I believe we’ll get there eventually.