ZPlanner!

I've been using variants of Scrum for a number of years now. Now, the topic of what does or doesn't qualify as Scrum is worthy of a blog itself (and it'll get one, trust me), but this blog is about something else, namely toolsets.

I've tried the notecard things a few times, but I always end up coming back to software solutions to manage stories and tasks. And in most cases the companies I've worked for have not been willing to put up the coin to buy an 'enterprise' solution, such as VersionOne or ScrumWorks. Those look like nice, though in the case of VersionOne overly complex, products. Mostly I've just used XPlanner XPlanner as it's free, open source, and relatively easy to set up and use.

But XPlanner seems to be dead at this point. There doesn't seem to be an active development and the last release was almost two years ago. I honestly think it's works fairly well, but I do think it has a number of shortcomings

• A story can't be turned into a task and a task can't be turned into a story. It's often the case that you initially defined something as a task, but you realize it's actually a story (or vice versa). You have to delete the original item and recreate it as the other type, you can't just *move* it.
• Moving tasks amongst stories and stories amongst iterations uses a huge dropdown of all items within your product
• There is no backlog. You can get around this by creating a fake iteration, but it's kind of kludgy
• The way in which estimates/burndowns are tracked over time is confusing

There are a number of other things I dislike, but primiarly they all stem around the klutzy interface. Something that mimics more closely the ease with which one can move around notecards would be great.

A few months back my company was going through a re-org. I found out that there no long was a position for me and being a bit nervous about my future, decided I better start brushing up on my programming skills. After all I've been a manager now for a few years and after trying ot think of something useful to motivate me to start doing a bit of programming again, I decided I'd try writing my own version of XPlanner, fixing all the things I thought wrong in the original.

Since it was mainly started as a project to refresh my programming skills, I decided to try a few new technologies just to get familiar. At the same time I didn't want to just use a technology for the sake of using it. In the end, the stack I ended up with was:

• Stripes
• DisplayTag
• JQuery/Ajax
• Maven2
• Hibernate Annotations
• Mercurial
• Cobertura
• HSQL (for unit tests)

My goal at all times was to keep the code as simple as possible. To this end I did most of my work using TDD, even "breaking" sacred rules of coding if it seemed like the simplest solution. For example, both Stripe Actions and Hibernate domain objects use annotations. Since in my first case the action and the Hibernate object has the same field, why not have a single file with BOTH sets of annotations? My Stripes action and Hibernate file the same code? What?!? You can't do that!

Well, I did.

When my design started to get kludgy, only then did I split them out. Similarly, I didn't abstract much of anything to start with. I didn't think out my class design in the beginning. I just coded the simplest possible thing I could.

Using this appraoch, I actually had a working application in which I could enter stories and tasks (even with ramping up on 5-6 new technologies) in about 40 hours. Of course, I've subsequently spent quite a bit of time refactoring, rewriting tests, adding more functionality, and most of all futzing around rather hopelessly in Ajax (I suck at front-end development).

Still, I've probably put in a total of 150-200 hours of work and have learned quite a bit. And I actually have a "kind of" working application. It still needs a ton of work, but it's getting there.

Screen shot of app and Ajax-based drag-n-drop inteface:

See how few files there are. Very few config files either:

Cool dependency graph courtesy of Maven2 and Eclipse plugin:


Cobertura test coverage report:

The Unicorn King and his Magic Pot of Gold

I started this blog about two years ago with a brief mission statement. I then wrote a single entry and didn't make another entry for two years. So, it's worthwhile to again touch on what this blog is about and how I *hope* it differs from a lot of other blogs in the blogosphere.

Excuse me for a sec, I need to go wash my mouth out. Using the word 'blogosphere' just made me throw up in my mouth a little.

I love reading blogs like Joel on Software and Coding Horror. I've learned so much from those guys. The problem is, though, that 99% of the time I can't help coming away from those blogs wondering 'What the hell world do these guys inhabit and if I visit will they introduce me to the Unicorn King and his magic pot of gold?'

It's kinda the same feeling I get when I start talking to a hardline proponent of Scrum (I'm a certified CSM if you really care, so I do *like* Scrum). It's just so divorced from the reality I inhabit it's laughable. Mind you, I'm not saying it's *not* reality. It's just not the reality *I* inhabit.

In their reality, every company hires the top 10% of talent (Where the other 90% go, I don't know? I'm pretty sure I've worked with a bunch of them though).

In their reality, you tell people about Scrum and they get *it* right away. They don't argue with you endlessly, implement in a half-assed way, then butcher it as new client demands come in.

In their reality, every programmer on your team is great and there isn't any dead weight. And if there is dead weight, well you just get rid of those folks with a snap of your finger! Poof! Gone!

In their reality, when a project is not possible in a given time frame, you just explain how it's not possible and tell people "I can implement *something* in that amount of time, but there will be trade-offs"...and everyone's okay with that.

You certainly don't end up having to manage team that turns out to be 100% comprised of contractors with barely adequate coding skills. You don't find yourself in endless meetings about stealing resources from other teams because you don't have the right people on your team. And you don't get put on a project that should take a year and told to make it happen in three months.

Of course, if you said this to Jeff Atwood and Joel Spolsky I suspect they'd tell you one of two things. That you just have to stick to your principles and affect change or that you leave wherever it is you're at and find a company that supports your principals.

I don't disagree with that. But reality is far more nuanced. At least with many blogs, it's made to sound so easy. You rarely get ones about how things failed utterly or completely. This blog is for all the people who've *tried* to change things, but see little progress. The people who like me, don't want to just *leave* because, hey, I get paid pretty well and I like my shiny new M3.

Sure, you can chalk that up to me being a crappy agent of change or risk-averse, because I refuse to leave. I suppose I'm complicity in my own misery. But then I have to think there are bunch of people in the same position as me. People who read joelonsoftware and come away going "Okay, that's great. But what the hell does that have to do with what *I* experience"

This is the blog for them.

Now, that's not to say I might not say some of the same things. But I hope the difference is, I won't gloss over the reality. I'll give a bit of an insight into the total soul crushing inertia and the learned helplessness that I think most of us live with. I'll share my own Sisyphusian attempts to change things and hopefully occassionally I'll be able to tell you about something that really worked. But more often than not I suspect I'll be telling you about my failures.

You don't go back and rack your brain over and over after winning. You move on. "What is won too easiliy is esteemed too lightly." as the quote goes. We learn more from failure than we ever do from winning.

And this is a blog about failure.