Posts from "October 2009"

Opower Labs

Moving Day

  • By Tom Vaughan
  • October 30, 2009

We officially out-grew our Rosslyn space today and moved in to a new space right next to the Court House metro stop.

movingday_kitchen We’ve got a new kitchen area that’s big enough to hold the company for a stand-up meeting…we haven’t had that capability for what seems like forever. There’s a pantry off to the left of the image (not shown) stocked with drinks, chips, pens and pads.

movingday_lobbyWe’ve got a nice lobby area too…through the windows in the background one can see the National Cathedral, Georgetown and most of Northwest DC. One of the things we’re all looking forward to most about the new space is the number of break away areas and conference rooms.

movingday_sasquatchOur working space is, as you can see, very open.  In the old office, that was occasionally annoying because sound echoed off the relatively confined space and amplified the drone of office sounds.  This space is well carpeted and more “open” so it seems quite a bit quieter.
The guy in the middle of this picture actually does the “Messin’ with Sasquatch” series of commercials for Jack Links Beef Jerkey.  He got the part because he needed less time in costume than the other actors.

The new location means a whole new suite of lunch places to try out.  That’s a relief because the Chop’t -> Chipotle -> Chop’t cycle was wearing pretty thin back in Rosslyn.

Read More
Opower Labs

Slides on Improving Your Agile Development Process

  • By Dave Copeland
  • October 29, 2009

Dead last, after the headline act, and after Joel Spolsky told everyone to go home, I did a lightning talk at DC’s recent DevDays (A StackOverflow production) on how we have used process metrics from our bug tracker to improve our process.

Read More
Opower Labs

Tweaking the Agile Calendar

  • By Tom Vaughan
  • October 15, 2009

For the first five iterations, the dev team had been following this schedule:

  • Iteration N, Week 1 = Design for iteration N and 2nd week of QA for iteration N-1
  • Iteration N, Week 2 = Development
  • Iteration N, Week 3 = Development
  • Iteration N, Week 4 = 1st week of QA for iteration N
  • Iteration N, Week 5 / Iteration N +1, Week 1 = 2nd week of QA for iteration N, design for iteration N + 1

We started to notice a couple things that have caused us to try out a new schedule in our upcoming 6th iteration.

First, we realized that we left very little time for fit to hit the shan.  If we had a tough QA cycle, we didn’t design enough.  If we didn’t design enough, we underestimated how much development would be needed (i.e. too many story points).  If we had too many story points, we’d go in to QA late.  And the cycle repeats.

Note that many of you Agile purists out there will cringe at the above description, especially this sentence: “If we had too many story points, we’d go in to QA late.”

I know.  We cringed too.

We’re committing to a couple new explicit practices going in to our next iterations:

  1. More formal velocity check-ins.  If less than 50% of our story points are closed by COB of the first Friday, we should have a come-to-jeebus meeting on Monday morning.
  2. We absolutely need to respect the impact that dedicated design time has on the effectiveness of everything down-stream.  It’s too easy to say “Agile” as a synonym for “code by the seat of your pants,” but that’s not what it’s about and we know that.  We just need to get better at dedicating time to it.

So with those ideas in mind, we’re moving to something like the following:


It’s a five-week iteration, with 2 solid weeks built in for QA and 1 dedicated week of design.

I think if we can get to a point where our regression and automation testing is good enough (and we develop enough confidence our automated tests), that we may be able to get back to a 4 week cycle.  In the mean time, we’re going to see if we can actually go faster by slowing down.

Stay tuned!

Read More
Older Posts