Ontic Oren

Enough virtual, it’s time for something real by Oren Teich.

Archive for October, 2008

Freedom by unrealistic expectations

October 08th, 2008 | Category: Replicate, SW process

We’re at that stage right now where the whole team is clicking.  Every 24 hours I’m seeing improvements that blow my mind away.  The more we get done, the fewer items left for us to do, the more I’m looking back and realize how TOTALLY INSANE my expectations were when we started.

When I first joined Replicate, our founders had already spent a bunch of time on the core databae and inference engine that drives everything we do.  Their up-front investment is what has enabled us to get to where we are today.  The rest beyond the core engine was good, but not what I was hoping for.  After a month of getting to know what’s going on, we emabarked on a massive push to completly overhaul our UI, the workflows, and everything about the product experience.

User experience is incredibly important to me, and I wasn’t happy with our state.  I confidently laid a plan for ripping the entire thing up, changing everything to the very core.  I committed to my boss that we could get this, “no problem”.  I signed up for all sorts of improvements, from new visualizations, new interface paradigms, new toolkits, and more.   Now, as we’re just two weeks away from release, I know I was totally nuts.  Not because we didn’t deliver everything I hoped we would - we did/have/are!  No, I was nuts because looking back, if each and every little thing hadn’t gone just right, we would never have made it here.  If we hadn’t hired an AWESOME UI engineer.  If our lead engineer wasn’t a rock star.  If we hadn’t managed to get an automation engineer and harness to remove the friction.  If the entire team wasn’t flexible enough to deal with massive change daily.  But we did, he is, we did and they are.  And so now, on time and on schedule,  we’re two weeks away from launching a product that I’m really excited about.

We’re a startup.  Odds say, we’re going to fail.  It’s only by having unrealistic expectations in the first place that any of us even can get into this job.  If we don’t keep having unrealistic expectations every day, we’ll get trapped by what we can’t do, and deliver just another piece of software.  IF we can keep being unrealistic, signing up for insane deliveribles every day, then I think we just might make it.

Sphere: Related Content

Comments

Living the ultimate online agile workflow

October 06th, 2008 | Category: Replicate, SW process

Over at my job, we’re just two weeks away from our first release!  I thought this would be a great time to look back a little at our tools and process.

Process

From the day I joined, we’ve been developing via a scrum process.  For those not familiar, the highlights are:

  • Everything you want to do goes onto a prioritized list called the backlog.
  • Write requirements in the form of user stories.  (As a <USER> I can <FUNCTION> so that <REASON>)
  • Anyone can add, only product owner can prioritize.
  • Team agrees on what backlog items they are going to work on during a planning meeting.
  • Create todo list from user stories.
  • Track progress through iteration.
  • Repeat!
We started out with 4 week iterations, with some serious pros and cons.  This gave us plenty of time to get large features in, but we were also finding that EVERYTHING was getting checked in on the last day. Despite the claims to mimize dependencies, I’ve found that there are ALWAYS going to be some there.  We didn’t do a great job identifying and planning for these, so often we had a huge crush at the end as everything was unblocked.  Everyone was busy the entire time, but we were losing sight of the iteration goal and occasionally coding to the todo list, vs the actual goal of the user story.
As part of our sprint review, we talked about some fixes, and identified a T-2 meeting.  Basically, we decided to meet halfway through the iteration, discuss how things are going, and plan out the rest of the iteration.  Make sure dependencies are met, etc.  These were taking 4 hours, almost as long as the sprint planning meeting.  That’s when Steve Ross had the brilliant idea - we’re basically just doing 2 week iterations at that point.
2 week iterations have worked well for us so far.  It’s way more focused.  Our review and planning sessions are shorter, and easier to handle.  Our velocity is still increasing, and no one has started making weird sounds and muttering in a corner… yet.

Tools

Say what you want about pen and paper, but I’m a geek, and love the toys. We use a bunch of tools here:

User stories are input into Jira, either directly or through the Greenhopper plugin.  Once a week, I go through and prioritize the user stories in the backlog with the great drag-and-drop interface Greenhopper provides.  As needed, we have planning sessions in which we break up large user stories into smaller ones, and play planning poker to assign story points.  We use paper cards for planning poker still. :)  Results are all put into greenhopper.
As we go out and talk to customers, we create a confluence wiki page for each customer visit.  We then go through the notes, and link to relevant user stories with a simple user macro (GALAXY-562@jira) that expands out to the full URL of jira.  Trackbacks are turned on, so when an engineer wants to know more about a user story, they can find the notes easily directly linked from the Jira issue.
We do NOT bother creating a Confluence page for each iteration.  Haven’t seen the need so far.
As part of our planning process, each user story is decomposed into it’s tasks.  During planning, we walk around with big post-it paper in a conference room, writing down all the tasks, then marking the hours and time each of us is going to spend. At the end of the planning, one person then types it all into Jira/Greenhopper.  Yes, this is tedious, but it only takes ~1 hour.  We’ve tried having people type their own items in, distributing the problem, but nothing shows up.  We’ve tried skipping the paper, but for brainstorming, nothing beats paper.
As we start development, users drag-and-drop their tasks in the task board view of Greenhopper.  Once a day, they indicate how much time they’ve spent and how much remaining.  Usually takes <5 min per day.  For each user story, we create a branch in subversion.  All development is done in the branch, until the user story is complete.  This does sometimes cause some trunk merging issues, but it’s not that bad, and the benefit of keeping this all separate is well worth it!.
Our product is UI driven.  When we need to figure out what to display to the user, we use this AWESOME Confluence plugin called Balsamiq.  It’s plain and simple the best way to do mockups that I’ve seen yet. All done through a web browser, you drag and drop super quick.  It’s perfect for conveying the thought, without getting bogged down in the stupid details that don’t matter anyway.
Our build is a little strange.  We’re creating an appliance, made up of postgres SQL, python and ruby code. Technically, there’s nothing to build, just pull together.  We created a customer shell script that pulls all this stuff together into a nice tar.gz file automatically.  We have bamboo call this script once a night for trunk, and poll the subversion server every 10 min for each user story.  The build script has a test-harness call out available, for long and short testing.  Our trunk builds get the long testing, user stories the short.  The short test just does a quick selenium test to make sure that everything loads as expected, and there is no crasher bugs.  The long test actually goes through and exercises all the UI components, timing how long everything takes.  All testing outputs junit XML, which bamboo then slurps up automatically.
At the end of the iteration, we delete the user story build plans from bamboo, label the build we’re keeping, and create a branch for our iteration release, just in case.
Overall, this set of tools has been fantastic.  We’ve spent right around $5,000 for all the software.  That’s a significant chunk for a small company like us, especially when there are such great free tools all around, and I’d spend it again in a heartbeat.  The quality of these products is just outstanding.  The support is great from everyone, and Atlassian in particular needs to called out.  I’ve had 4 issues worth submitting as tickets, 3 of which they handled in < 2 hours, and 1 was my fault.
Sphere: Related Content

Comments