• 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!

Well, we here at OPOWER loved our Duck Hunt, so we’ve been attempting to use “Agile” for the last 5 months or so. Agile means a lot of things to a lot of people, so I’ll spell out what it means for us and then reflect on some of the pros, cons, and room-for-improvement in our practice.

• <cringe>Embrace change</cringe> (duh)…but especially in this startup environment, we need to remember to do no more than is necessary, because any “extra mile” functionality is likely to be totally unused as priorities and direction changes.
• Be scientific about development…measure, measure measure.  We track velocities, average-open-days-per-bug-by-severity, etc.
• “Individuals and interactions over processes and tools”…we self-organize, aren’t afraid to try new combinations of responsibilities and assignments, provide regular feedback to each other and we don’t dictate a development environment or technology stack.

The best thing about the technical side of this company is that the entire development team and project management team is on-board with the idea of rapid iterations, continuous improvement and a focus on technical excellent and “maximizing the amount of work not done.”

This manifests itself in several practices that I’d chalk up in the “pro” column:

• Light weight documentation…use wikis and person-to-person contact (recorded on bug tickets for posterity) to flush out designs and requirement.
• Continuous integration and continuous improvement (we just installed Sonar last week…we’ll blog about its effectiveness later)
• Regular code reviews, 360 reviews, and “how did we collectively perform this iteration” meetings
• Few formal meetings, many informal, impromptu “drive bys”

But the best thing about our Agile environment right now is that it is a work-in-progress “process framework” that repeats quickly enough for us to remember what to improve.

What do I mean by that?

It’s my impression that on the longer, more drawn-out software engagements (say…6 or 12 months), you can make a series of mistakes in the design phase, the build phase, the qa phase, etc. and then by the time you’re on the next project you repeat all those mistakes again because it’s been 6 or 12 months since you last learned your lesson.  Instead of concrete lessons, you develop a career full of “gut instincts.”

We’re still honing in on the right amount of measurement and process for OPOWER, but because we’re all on board with the idea of quick-hit iterations with a continuous focus on improvement, I have high hopes for our ability to become (stay?) a top-notch software engineering organization.

There’s lots of room for improvement, that I think I’ll save for another post on another day.  We could definitely stand to “communicate out” more– with the product team and with our operations team.  We need to do a better job of making sure our iterations are lining up with the corporate strategy.  We could improve on the whole “customer collaboration over contract negotiation” part of the manifesto.  But you can only squeeze that trigger so fast, right?