My First Agile Project Part 9: Choosing A New Tool - VersionOne

October 27, 2008 by mattgrommes

In my previous post, I talked about my team's experience using ScrumWorks as our Scrum backlog management for the first year or so of our project. After our vendor's license for ScrumWorks ran out, we thought we were close to the end of our project so we stopped using any tool for tracking tasks beyond our bug repository. As I'll talk about in this post, a combination of factors led us to start looking for a new backlog / taskboard tool and the one we've settled on is VersionOne. Read on for more details about why we chose VersionOne and how we plan on using it, even once we've moved on our first agile project.

First, a word about Part 8 of this series, where I outlined the things my team and I didn't like about ScrumWorks. I didn't intend that article to be a review of ScrumWorks at all but more of a look at how we used it and why we didn't like it at the time. It expanded and was seen by some as too harsh on ScrumWorks, especially since I was talking about an older version. It appears that ScrumWorks has done some good updates and fixed a lot of the issues we didn't like about it. But some of the problems are philosophical and I'll get to those in a bit. But if you're looking for a Scrum tool, make sure you do your own evaluation and don't take my word for it. Every team is different.

Also, just so there's no misunderstanding; neither I or Agilesoftwaredevelopment.com have any connection to any tool I mention here beyond using them.

Time To Find A New Tool

Our license for ScrumWorks running out happened about the same time we thought we were nearing the end of the project and we refocussing to work strictly on bugs that came up during testing. We all had bugs related to things we'd worked on so we didn't see a big need to track things and do sprints like we had been doing. There's more on this phase of our project in Part X of this series. But overall we liked the Scrum process and had been laying the groundwork for making sure we kept doing it even after we moved off of this project, the one that had introduced Scrum and Agile to our company. To do that, we knew we'd need a tool so we looked around a little for one while continuing work on the existing project. A few months later I went to the Agile2008 conference in Toronto and found a couple of good alternatives to ScrumWorks.

Picture courtesy of VersionOne

At the conference I saw a couple of products but was most impressed by VersionOne, by far. Everything was done in the web browser, which I was specifically looking for after disliking ScrumWorks' use of a web browser and desktop app for different tasks. The UI looked easy to use and didn't get in your way. It looked very easy to add different projects to keep the various tasks we had in our company tracked together. Part of my search for a new tool was one that was easy enough to use that it wouldn't take too much maintenance or setup. I was trying to get our department and company to accept wider use of Scrum and Agile methods and a tool that would add a bunch of work would just be an impediment. Another very cool feature was their open API that allowed people to write integrations and tools on top of VersionOne. We use Jira at work for bug tracking and VersionOne has a synchronization tool for Jira that looks like it'll fit our workflows very well.

When I returned from the conference, I setup a trial with VersionOne that allowed us to use the tool for a month to really get a feel for it. I used it to run a small sprint we were doing on a bigger integration piece we needed to get done quickly and it handled that very well. I also imported all of our Jiras as a different project as a test and although the importing process had some problems it worked well (there's an XML importer but no example XML I could find and the CSV importer didn't appear to allow importing notes from Jira which we use extensively). I didn't setup the automated Jira synchronization due to a lack of time. If you're looking at Scrum tools, I'd encourage you to get in touch with VersionOne and try their demo, it's very enlightening to actually get your hands dirty on a tool and it's easy to setup with them.

Picture courtesy of VersionOne and me

Working with VersionOne, the biggest thing that stands out is how it doesn't try to force you onto a specific path. ScrumWorks tries to keep you on the strict Scrum path, which according to the product manager who kindly responded to last week's post, is their intention. That's fine but just didn't work for us. I'm not a big fan of strict processes and like the ability to go the way that suits us best without having to work around things we don't need. We want a way to keep track of tasks, make sprints, etc. We don't care about a lot of the stuff other teams might want or need and VersionOne doesn't force us to. I think the only required field by default on backlog items and tasks is the title. Other than that it's up to you.

Transitioning from one agile project to many

As I mentioned, I've been working on convincing our department (and by neccessity, our customers in the rest of our company) to move to a more Agile process. Before starting on this big Scrum project, our process was pretty much non-existant. We didn't even really do waterfall, we just came in every day and worked on bugs and issues from Jira. Luckily for me, I was only with the company a few months before we started using Scrum on this project.

What I'm hoping to do, and I'm pretty sure I've convinced my manager and director that this is the way we should be going, is to do Scrum on a multi-project basis. Instead of almost all of us being on this one big project, we'll make 2 week sprints out of issues from the various projects in Jira. VersionOne's Jira integration will allow us to keep having people enter tasks in Jira like they always have, then we'll pull them over into backlog items and defects and enter them in sprints to work on. Priorities will be set by our manager, in a modified Product Owner roll, and we'll be removed from the management back-and-forth of those decisions in a way we weren't in the previous process (we hope anyway, we'll see how that works in practice :)). This will let us work as a team on multiple projects at once, without having to multitask and switch projects based on which department manager is at our desk that day. Or we can put all of our resources on a big project for awhile to get big chunks of work done. It's a very flexible system and I think will work out well for us once we can get everybody on board.

But the reality of the situation is that I'm just a programmer with ideas, a big mouth, and a genetic inability to keep quiet about things. My management tends to listen to me but we'll see how these plans work out when they hit the corporate reality. I plan to write more about how this transition is going in real-time once it gets closer and I finish out this My First Agile Project series.

As I say every time, thanks for reading. If you have any comments on any of this, please use the comments form below.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks