OpenSourcery

This week marks two years for me at OpenSourcery. My first day on the job I walked into a cramped little office, lovingly called The Swamp Castle, in Southeast Portland. At that time, the team consisted of 10 of the smartest individuals I'd ever met, and a cat named Bio. As you can see from Thomas's post, our digs have changed considerably over the last two years. And with the addition of our new intern, Dan Mitu, last month and UI developer, Jackie Scherer, next week - our team will be up to 23.

This spring I anticipate that our Ruby on Rails team will be blogging a lot about the evolution of our approach to agile software development. Just as our development and design processes have matured, we've gained considerable knowledge and experience regarding best practices for agile project management and consistent client communication. Below are just a few of the lessons I've learned regarding agile project management in these first two years at OpenSourcery:

• No news = The worst news - We often joke amongst both our developers and our clients that software development does not require the administration of penicillin. We know that our work represents a considerable investment on behalf of our clients. We know that deadlines and budgets are really important. And we honestly believe that our open source work is directly changing the world. But ultimately, no one's going to spontaneously combust if something goes wrong - which is a good thing, because something always goes wrong. It's just part of application development. Consequently, we take a very upbeat — but direct and candid — approach to client communication. We don't sugarcoat our project updates or hours reports. We engage our clients as best we can in our decision-making processes. And we document our design goals and development steps using highly transparent tools.

• Stick to your milestone release schedule - At the start of each agile milestone, we sketch out a target feature set for the milestone release, based on a scoping methodology that generally provides us with consistent results. That being said, as features are developed, the scope and priorities during a milestone inevitably change. When this happens, there's a tendency amongst both clients and development teams to try to adjust release schedules (usually meaning prolonging them) to squeeze in additional features. In our experience, this generally is a mistake. Adjusting milestone scope, rather than milestone duration, requires more project management and client communication. However, sticking to a release schedule ensures more consistent client feedback cycles, more frequent QA, and better management of project budgets.

• Anticipate, but don't borrow trouble from the future - There's a delicate balance in agile software development between long-term project planning needs and focused, iterative development cycles. It's just human nature to be drawn to the shiny allure of waterfall-style software development - the idea that you can think through every user interaction in an application upfront, build a robust spec - and then chain the developers to their consoles, feed them raw meat and just let them rip. It's tempting as well to try to address every design question that comes up in the development process all at once - as there's something unsettling about releasing features you know aren't complete. But time and again, we've seen that that style of design and development doesn't work. You can't have all the answers, or even know all the questions, upfront. Stay focused on the goals of your current development milestone, and you'll end up with a better, as well as more affordable, product.