Things I like about Thymer:
- The Interface
Again, I cannot stress enough how much I love using it. It's clean, simple, and very intuitive. They really take pride in their one-page design. If that sounds unique, it should because you literally do everything you need on one page.
The other thing I like is that the interface is designed around one thing: managing tasks. The user's eyes are immediately drawn to the input bar and from there everything just makes sense. I don't remember all my fancy HCI terms, but this just reminds me of everything I learned in design class. The interface seriously makes me happy just using it. I'll shutup about this now.
- The syntax
The simple way to use Thymer is to just type a task in and go. However, you can start pulling in many of its features with the "@" sign. With this and a few key words, you can assign tasks to a particular project, delegate to a person on your team, set a due date, and plenty of other things.
- Time tracking
Being able to track time spent working on a particular task--especially if it's billable--is a cool feature to have. If used correctly, it can help an individual find out how they spend most of their day. It can also help a team manager see where the hours are going on a project. It can also be a useful estimation-training tool. I haven't investigated this feature much, so I can't really say more.
- Other little tricks
I only got my invite to this last night, but I've already been using it quite a bit. The ability to set up multiple projects and arrange views by projects is nice. Being able to drag tasks around to designate priority is also a good feature. It is aware of date as a context and uses color and positioning to visually show you which tasks will be on time or may run late. Those that have already passed the due date show up in red. Assigning tasks to users could be useful for a team.
For the most part, I can see this as being useful on a personal level, but it also have been thinking about how this can be used for project management in the agile methodology. There are lots of discussions going on these days on how to make various things about our Design Studio program go better. We had Ron Jeffries in class today to review what was good and what was bad about our year of agile. The time we spent talking to him yesterday was pretty awesome too, but I digress.
We've been grumbling about VersionOne pretty much all year. There were some things I liked about the application, but I think it was fairly underutilized from what I could see. Some teams really bought into it, and others only used it at a bare minimum to make sure the powers that be were pleased. I can attempt to make a few guesses at why.
- The Interface
VersionOne was cluttered. There was just so much going on in a given screen when all I want to do is grab stories or add tasks to my stories. With time and practice, VersionOne does become very navigable, but it pales in comparison with the ease of use in Thymer.
- Feature Overload
As a team, the things we were concerned with were maintaining a backlog, managing stories, adding tasks to stories, and making estimates. As far as I can tell, that was it. VersionOne had nice things like burn-down chart generation, "how far behind you are" bars, and other reporting tools. We never used many of these things. Moreover, to my knowledge, our client rarely saw any of these things. Where's the value? After a while, all these things become gold plating and one really has to take a hard look and see if you're getting the return on every feature you paid for.
Many software applications maintain physical metaphors and conventions to make usability more intuitive. In VersionOne's case, it was frustrating because you could kind of see where they were trying to do that, but I always felt like I could be just as productive with sticky-notes on a wall or some other simpler process. For all its glitz and glamor, VersionOne could have easily been replaced and I don't think anybody would have missed it. However, another part of the problem is that PMs and faculty can't see progress without VersionOne reports, so the teams are constrained to use a particular tool not because of its effectiveness, but because of policy. I'd take the sticky notes in a second.
- Mapping Policy to Use
This one may not be VersionOne's fault at all, but I can remember how messy things were at the beginning of the year. Generating stories was one thing. Jamming them into a VersionOne backlog was another. Trying to figure out how many tasks to make up or how to break things down "just so" because the faculty might be grading something made it nearly impossible to map the value of a system to requirements for class. The point is this: a tool should mold to the needs of a team, and not the other way around. Too much time was spent trying to bend in unnatural ways to play nicely with VersionOne. Something like Thyme seems flexible enough that a team could adopt it naturally into its own way of doing things.
I didn't really plan this post before starting, so I apologize if it's not well structured. What started as a post about Thyme turned into a rant about VersionOne. However, I hope somebody finds this tool useful, and I hope we can take a good look on how our use of tools in Design Studio can be a natural, pleasant aid to a team instead of an encumbrance.
I grabbed this video from their site. Take a look at it if you want: