Ontic Oren

Over at my day job, we’re conducting a quick little survey to help us get a better handle on the configuration problems that people are running into setting up and managing a virtualized datacenter.  We are looking for feedback on the challenges that frustrate administrators in a virtualized world, and then some specifics on areas that may be of particular pain such as IP management, network configuration, etc.

The survey should take < 5 minutes, so if you’re reasonably technical, have played with or administered virtualization (citrix, vmware, microsoft, KVM, whatever), please help us out and take the survey.  Feel free to pass the link to anyone else. 

I’ll be posting the full results of the survey (barring personal information) next month, no filtering or editing.  If I get more than 50 useful results, I promise to even post the raw XLS for anyone else (competition or otherwise) to use as well.

Survey: http://bit.ly/4vhktO

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.

Ah, the corporate overview.  The staple of every web site, and the key piece of many presentations.

We’re in the proess of putting such collateral together here at Replicate.  Not wanting to reinvent the wheel, I consulted the oracle for any keen insight or best practices.  After 45 minutes of searching, I’m surprised to find nothing on what makes a good/bad overview, or thoughts in general.  I did find some amazingly, painfully, searingly bad examples (I’ll be kind, and not link, but a quick google search for “corporate overview” will send you crying for some good clean smut).

Obviously, the goal is to convey answers to the standard 6 questions as applicable - Who, what, when, where, how, why.  I think we’ve all been trained a bit too well on these in that order.  Is who really the most important part of any pitch?  Unless it’s to your mom, I don’t think so.  Keeping in mind who we’re trying to convey this information too, most people who haven’t heard of us don’t want to know about the company, the want to know why they should even care in the first place.  To steal from Jerry Weissman, WIIFY (what’s in it for you)?  The WIIFY will vary depending on your target audience.  In our case, we have a few, all rather obvious:

• The customer: “If you buy our product, you’ll solve a ton of problems and get to go home and spend time with your family”.
• The partner: “If you work with us, you will keep and gain many happy customers”
• The investor: “If you invest in our company, you’ll get a great return on your money”

In all these cases, talking about our company seems like the last step, not the first.  Identify their problem, talk about solution, then explain why you’re the one to solve it.  I’d take those favorite six questions and reorder them:

• Why: What’s the market problem
• When: I’m gonna care about this when?
• What: What is the solution?
• How: How will you help solve it?
• Where: where can I find the solution?
• Who: And who are you to actually do it?

Any other thoughts on outlines or best practices?  What’s key in a good corporate overview doc or presentation?

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.

photo credit: David Reece

If you follow me on twitter, you may have noticed that I slipped in my resignation from Sun. Today, March 14th, is my last day.

I’m embarking on the riskiest of all options - a tiny new startup. We’re looking at how we can address some issues that arise with the use of virtualization and network management. I’ll be doing product mangement, plus whatever it takes (markeing, cooking, cleaning) to make sure we’re a huge success, and maximize the reward side.  [If I've 10x my risk, but also 10x the potential reward, I guess my risk/reward ratio remains constant? I guess I've probably 10x the risk for <10x the reward.]

So why jump now?  For the first time in my career, I’m not running away from an old job. The Sun xVM team, and especially my boss, are doing an amazing job. They are building a great team and a great product. I’ve even managed to recruit two new people to the team in the past week, in spite of my departure! I have no doubt that I’ll be talking with the Sun xVM team shortly on how we can work together.

Proving just how random our lives truly are, I found this job through one of those serendipitous moments. A colleague of my wife asked if she knew anyone for a certain position at this other small company, just in passing, and a month later I’m resigning!  The team, the opportunity, and frankly, the risk, were all to good to pass up.  I’m excited to be scared sh-tless and I’m excited to make something from nothing.

Rich, Rich, and Ken - I can’t wait to join you and the rest of the team on this adventure.