Scrumy

So I've been playing around with Scrumy lately. From the name I'm sure you've figured out that it's some sort of tool that helps you manage Scrum-based projects. It actually works for any sort of agile-ish project, so you don't have to give up whichever agile cult with which you may already be affiliated.

Scrumy lets you play around for free, although with the free version you'll be in one endless sprint until the end of time. That gets tiresome after a while, so I finally opened up my wallet, blew the dust off my credit card, and parted with a whole $7 (USD) for the privilege of using Scrumy Pro for a whole month. By the way, I'm positive that contrary to what the developers say about the name in their slick intro video, they affectionately refer to their product as "screw me" when we're not listening. But I digress.

My $7 obviously entitles me to deliver my demands to the developers and readily expect to have them fulfilled within two weeks. Anything can be done in two weeks, right? So obviously this budget tool has a few shortcomings, and who better than me to point them out? Ready? Here we go...

Can't see "to do" items in the backlog. There's a backlog (great). You can add stories to it (great). If your story has to do items that greatly enrich your understanding of the story, you're unable to see them when it comes time to assign the story to a particular sprint (utterly maddening).

There's no search. I can't possibly be expected to remember where I put things, that's why I'm spending all this time painstakingly typing stuff into someone else's web app. If there's no search, I can't find stuff without digging through everything and clicking around like mad.

Would be great if edits were pushed out. I'm working on a project with a buddy in Toronto. We often chat about how things are going, and play with the stories and tasks until we agree on the next sprint. It would be fantastically, over-the-top-mega-cool if he could see changes as I was making them. And vice-versa of course, sometimes he has good ideas too.

No obvious way to promote a "to do" to a story. Drag "to do" to story column (nope). Drag "to do" to backlog (nope). Open up "to do" and search for "make story" button (nope). Bang head against screen, open "to do", copy text, select "new story", paste, bang head again.

The Scrumy Scrumy board isn't public. I mean really, how cool would it be to be able to see how the Scrumy guys setup their own project, and what they have coming down the pipe. Read only, of course, except for respected, rational individuals such as myself who should be given full access.

Now don't get me wrong, Scrumy is refreshingly simple and I'm really enjoying working with it. It does just what it sets out to do (replacing sticky notes) admirably well. It doesn't lock you down to particular iteration lengths. It doesn't make you do a bunch of complicated category, project, user setup crap. It embraces the simplicity and flexibility of paper (mostly), while providing the many benefits of taking it online (oh crap, the cat destroyed our project tracking system AGAIN). I wish more products were this fun to use and had such wonderfully ambiguous names.

TDD in Space

I don't know about you, but I find some aspects of test-driven development hard. Too often I'll find myself writing trivial unit tests, typically revolving around persistence or login. I mean, really, should you be spending time writing tests to ensure your application's persistence layer is functioning correctly? That should just be a given!

However, I've been pushing through my initial hurdles, and am really starting to see some solid payback. One of the unexpected benefits is that my API almost immediately becomes more readable. Not convinced? Think about it. In test-driven development, because you're writing the tests in "problem brain-space" instead of "solution brain-space", you're thinking in terms of the problem that needs to be solved, not how you're going to solve it.

While you're in "problem brain-space", you're in the same sort of place that users or maintainers of your code will eventually find themselves in. There are many possible "solution brain-spaces", each with their own set of unique concepts and terms, but typically in the "problem brain-space" you're more likely to be speaking a common language. Which is a good thing.

Thinking in Git

I recently started using Git on a small team project. Why Git, you ask? Well, previously I had used CVS and Subversion (and by such admission I am knowingly submitting myself to being mocked by Linus), and prior to that had used Visual SourceSafe. So I figured it was time to learn something new and dive into distributed version control.

I have to say, it's a bit of a leap. In the same way that I stumbled through learning to trust in CVS to merge my changes, as opposed to locking a file the way SourceSafe did, I'm finding the distributed model takes some getting used to.

It's great that I don't have to have network access to do commits. That's the easy part to appreciate. With Git, you commit to your local repository copy. If you want to bring your changes together with someone else's, either you push to their repository, or they pull from yours, but that is in no way tied to the act of committing your changes. There's no built-in notion of a master repository. Really.

For some reason I'm finding it difficult to grasp that concept. For years I've relied on the notion that all my changes are safely locked away in the master repository. The master repository is the source of all truth. (Ha ha, get it? "Source" of all truth? You don't get it. Fine.)

In our particular team setup, we do have a master copy hosted on GitHub. I'm finding that every single time I do a "git commit", I have this unstoppable compulsion to execute a "git push", and I'm not sure that's the right idea. I'm looking forward to that breakthrough moment when I finally get it. I'll let you know when that happens.