Agile Development
Agile Development
Sometime last year, our engineering and product teams embraced the Agile Software Development framework. Without going into too much detail (here’s the Wikipedia entry for those who want it), the concept of Agile Development is to run software development in small pieces with a focus on more communication between product and development teams resulting in collaborative requirements development. This leads to a “release early and often” environment where there are continual improvements. For us, we group development projects now into a “release” that consists of a series of usually six, two-week “iterations.”
The release planning and iteration planning meetings are reasonably long meetings that involve the major stakeholders, product management and engineering. The process also includes a very short, 10-minute Daily Stand-Up meeting with everyone on the team to review progress and identify roadblocks to completing the two-week iteration. Requirements are not heavily documented and discussed more or less on the spot during the iteration meetings. Because there’s a major pull-up every two weeks and a minor one every day, it’s easy to be light on requirements and for product management to constantly be in the loop with engineering to see progress, test functionality, and make mid-course corrections.
This methodology isn’t for everyone, but it’s particularly well suited to the kind of work we do at Return Path — small team, multiple internal and external stakeholders, very dynamic market, and web services as opposed to packaged software.
Our efforts have been bolstered by some limited consulting and more important, a fantastic web-based workflow management tool geared towards Agile Development run by a company called Rally Development in Boulder. Think of it as Salesforce.com for your engineering and product team.
We’ve had great success with this methodology to date. Engineering productivity is way up, product management visibility and input into development is way up, the level of friction/noise between product management and engineering is way down, and we have a much tighter grip on our development milestones than we ever have in the past.
Agile and Rally have worked so well for us, in fact, that we’re starting to extend the concept to other parts of our business, which I’ll write about separately.