I’m assuming from the amount of hype out there that if a development team isn’t using “Agile” right now, they probably feel like the one kid on the block who didn’t have a Nintendo (with the Duck Hunt option, of course).
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?
Agile impressions, 5 iterations in…
I’m assuming from the amount of hype out there that if a development team isn’t using “Agile” right now, they probably feel like the one kid on the block who didn’t have a Nintendo (with the Duck Hunt option, of course).
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:
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.