Ontic Oren

Although it took some time, I’ve decided on the tools.  As the title says, I’m going with Atlassian’s suite, plus a really nifty plugin I’ve come across called Greenhopper.  Here’s the overview:

• Create user stories in Jira.
• Create wiki page for each release (not iteration, but release).  Link up to Jira dashboard.  Provide details, necessary information, any supporting stuff available.
• Planning poker to estimate user story size.
• Prioritize user stories with drag and drop via Greenhopper.
• Drag user stories into iteration releases via Greenhopper.
• Create sub-tasks for each user story to track hours.
• Drag tasks on planning board for open, in progress and done via Greenhopper.
• Use Greenhopper to generate burn down, velocity, and other fun graphs.

Now, all that said, there are times when paper is just the way to go.  We currently have ~85 user stories, and trying to figure out the ranking really is easier when you can have paper in front of you.  Luckily, it’s easy to do both!  By exporting the issues into excel, and then using mail merge from word, finally printing to Avery postcards, I’ve got a great way to create cards.  You can use my attached user-story-cards word file if you want to create your own.

I’ve concluded the tools analysis that I kicked off a few weeks ago. What initially began as a look into requirements management tools quickly expanded into the entire product development lifecycle. Tools can not make up for broken process, so that’s the place to start. As I looked back at what’s worked and not in the past, I realized that the MOST critical success factor has always been alignment. If engineering, product management, sales and the customer aren’t all aligned on what, when, how, and why, we create massive headaches for ourselves. To ensure alignment, we need one source of truth, one place to track everything that’s going on. If we need to keep two system in sync, we lose. If everyone in the company can’t see everything, we lose. If everyone isn’t bought into the process, we lose.

In order to get everyone on the same page, we need to look at the toughest participant. I’m sure this won’t come as a surprise to anyone, but usually that’s engineering. Not only are they the largest team, they also have the strongest opinions. Starting from that vantage, I realized the plan of record has to be kept in a bug database. It’s the only thing engineering will update. In my past lives I’ve many times tried to keep a separate list, one focused on features, and engineering’s DB focused on bugs. But what happens when you classify a bug as a feature enhancement? It’s such a grey area, do you start replicating and moving data? Duplicating it? Either way, it’s a disaster. I’ve gotten into massive fights over this before, and even if I was “right”, is it worth fighting that over and over?Yes, tools like Rally and Accept can interop with Bugzilla or Jira. But if I need to have the bug DB anyway, is the extra effort and cost worth while? For such a small shop as ours, I’m not sure the answer is yes. I’ve used Accept for a few years, and have loved the tool. For traceability and analysis, it’s the perfect tool. I think I may have let those aspects get in the way of focusing on what the requirements themselves are, and how we get alignment in the groups. Frankly, all the tools I looked at in the previous post just seem like total overkill for any <50 (and maybe even <300) person company.

Now clearly, the bug database by itself isn’t sufficient. You need a place for more unstructured data, for planning, notes, etc. For marketing data, sales plans, and just the rest of the company. Obviously, a wiki is the best place to put this. This leaves us needing a great bug DB, and a great Wiki. In a stroke, I’ve thrown out almost all the tools I was looking at before: Accept, Rally, Feature Plan, VersionOne. They all are… complex. I’m sure for a large company, they’d work great, and have their advantages, but for a startup looking at Scrum and frankly trying to save some money, I just couldn’t see the value. So that leaves us with only four options that I could see out there:

• Fogbugz (with or without external wiki)
• Twiki + Bugzilla
• Trac
• Confluence + Jira

Fogbugz I quickly ruled out. Although it’s got a great UI, and I hear good things about it, it’s also just not the right fit. Some of the additional features were lackluster (the wiki is atrocious, the forum useless compared to phpBB), plus it’s very general (good), and needs to be shoehorned to fit Scrum or other agile processes (bad).

The next three was a much tougher decision. Trac looks great. For an internal focused project, or an open source project, it’s probably the one I’d use. However, we have need for both private and external content, tighter security controls, and some more advanced commercial features that they don’t seem to cover. I REALLY liked Trac, but I didn’t see it fitting into our commercial environment.

Now it’s really hard. I LOVE twiki. Better than Confluence. I like Jira better than Bugzilla. Ultimately, the support & integration that Atlassian is providing, plus the larger suite of products such as Fisheye, Bamboo, etc all pushed me over the edge. Maybe it’s just a dream, but the thought of having a view into CI data, test status, check-ins, all tied and traceable, makes me a tingle.

From a cost perspective, for a small team like ours we’re looking at a $3,600 investment for Jira and Confluence, plus $1,800 for maintenance. We’ll put them in VMs on existing HW, running Fedora. The incremental admin costs for two new machines should be minimal. I’m figuring if we buy into their whole stack, we may wind up spending 10K with them. On the one hand, that ain’t chump change, especially when we could be getting it for “free” with Twiki/Bugzilla or even Trac for internal + Twiki for external wiki needs. I’m counting on the support, the features, and the overall new development will all make this pay off.

I know many other people out there on the internets have gone through similar evaluations. Which way did you go? 6 months or a year later, are you happy about it?

BTW, the photos are from a recent drive I did. They are there just for decoration.

What should I build? And who says so? When do they need it? Will we be able to deliver?I’m working with my team and engineers every day to answer these. Although tools will never make up for a terrible process, a good tool can also make things go much much smoother. For 2 years, I’ve been using Accept 360 for requirement tracking. My wife is leading up an evaluation at her company right now, which sparked some more investigation on my part.To look at all the players out there, you need to break the SW development process down. I’d say there are three phases, irrespective of development methodolgy. Regardless if you’re a Scrumer, a XP developer, or a plain old waterfall, it seems like you always have three tasks:

1. CRM/Customer interface. Collect data from customer, define and justify your requirements with data. This is almost always driven by email, personal interaction, meetings, notes. The tool is here to help the product manager collect their thoughts, organize the data, collaborate with other marketing people, and feed the status back to the field and customer. Very focused on traceability – show me who is asking for what, when and how. Very CRM like.
2. Project Management. Manage the development, what is in what release. Know when and what you’ll have. A very blury line often between product management, engineering, and gobs of other people. Focus on the deliverables, the specifications, and getting releases out. Heavily used during development by all involved.
3. Release management. Bugs on released products, feedback into step 1. Close the loop. Collect the feedback from users, community, post-release QA. Feed back in to Phase 1 and continue ahead. I see this as a combination of bug database and Wiki.

I looked at bunch of tools. All except featureplan I’ve looked at in the past month – featureplan I last looked at over a year ago, so much may have changed.

• Accept 360
  • Phase 1 Focused
  • Web UI, Slowest interaction, though still acceptable
  • Very focused on the requirements gathering phase. Very strong relationship definition.
  • Recreating the CRM – if you use anything else gets frustrating to enter in data duplication.
  • Methodology agnostic. Neither helps nor hurts with Scrum.
  • Weak Phase 2. Not worth using IMO. Too complex, can’t actual inteagrate. Very heavy project management overhead.
  • Seems big-company centric. Doesn’t feel “cool”
  • Doesn’t publish pricing, but it’s >$1000/user/year.
• Rally Software
  • Phase 2 focused. Plugins with others to satisfy phase 1 and 3.
  • Medium-complex UI. Very usable, fast.
  • All about Agile/Scrum. Uses terminology, flows that force you to use agile.
  • Focused on what they can do – doesn’t try to solve it all
  • Best integration – subversion, eclipse, Visual studio, jira, salesforce, etc.
  • Super cool wiki/community integration with end-to-end salesforce tracking as well.
  • $35/user/month or $420/user/year. Salesforce integration extra.
• FogBugz
  • Phase 2 & 3 focus
  • No methodology implied, do whatever you want.
  • Integrated wiki appears weak – separate from reset of product. Would personally use mediawiki instead.
  • Very slick UI, very fast, VERY easy to use.
  • $25/user/month
• VersionOne
  • Waiting to get a demo account still. Demerits to them. Who requires talking on the phone in this day and age to get a demo account?
  • $30/user/month
• Feature Plan
  • Phase 1 only, but crushes it.
  • Deep requirements planning. Integrates with Rally.
  • Development methodology agnostic.
  • Only windows only client (they’ve got a web UI, didn’t exist when I looked last)
  • All about pragmatic marketing (but then, I am too. :)
  • Darn expensive as I recall.
• Trac
  • Phase 2 and 3.
  • The dark horse in this group – open source, PITA to install
  • Scrum plugins to make project management in Scrum very reasonable.
  • Good integrated Wiki features
  • Possibly better as a project tracking than a product – need investigation but initial feeling is this works GREAT for open source projects, but may run into issues with wiki and others for real product release lifecycle (i.e. permissions on documentation).
  • “free”

Rally really impressed me. I used it 18 months ago, and was underwhelmed, now it seems like a great tool. I especially like the integration – Salesforce for your CRM (and bugs even), take continuous integration data, and have it all useful from one tool. It’s probably a high investment strategy, but I could see starting small, just trying it out, and growing to make it a core part of the platform.Alternatively, fogbugz looks like a great choice. It’s less of the uber-tool, and more focused on the development. For Scrum management, I’d suggest using good old paper (burn down, planning, etc).The data geek in me says go for Rally. KISS says Fogbugz and paper.