By Aaron Sanders
Earlier this year, I found myself in a familiar situation. I’d once again been wooed by a small start-up company that is growing in size and looking to hire senior expertise because of a major deal inked with a large organization.
The staff of the small startup were both exhilarated and stressed from working so hard to make the effort attractive to major players in the market. A year of doing whatever it took to get product out the door had taken its toll—two of the original developers had already called it quits. I wasn’t sure what I had gotten myself into, but I was excited about the possibilities. One thing I was sure of—their waterfall process was not going to get the job done. Let me take you back there and walk you through the switch we made and the results we achieved.
Rewind
It’s January 2007. I’ve just begun work at my new job. I immediately start pairing with anyone who checks out code. I notice that there is an infrastructure with some automation of builds, data replication and testing, so they definitely are not way off in the weeds. The product is web based and built with fairly robust open source systems.
The recently hired project manager is working with the creative director to come up with a fairly heavy process to accommodate the anticipated growth and to ensure success in the new partnership. They have printed out a graphic representation. The business development director is on a road show with the owner, promoting their wares. When the duo arrives back in the office, they find a note I’ve stuck to the graphic representation of the proposed process. It reads, “traditional waterfall.”
Meanwhile, I sit down with the project manager and ask if he enjoys writing use cases. Throwing down his pen on the desk and pushing back, he spins to me and states, “Heck, no! I can’t get anybody to read them, let alone approve them.” So I ask if he would be interested in hearing about a process where we wouldn’t have to have it all written down by him before we began. He’s interested.
After some education of the terminology of the practices, we invite the owner, business development director, and engineering manager to a discussion over coffee, where we go over what it would mean to introduce the agile methods of Scrum and XP to the organization. We discuss roles, how to generate and estimate the product backlog, length of iteration, and what day to start.
I explain the need to separate authority from responsibility by not placing the role of ScrumMaster with the engineering manager. We decide that this would be a good role for me. We determine that the project manager should be the product owner, as the business development director is gone too often. Since the project manager is also the system architect and has the most domain knowledge besides the owner, he is mentioned as a possibility for customer as well. Because this would stretch him thin, we convince our actual customer (partner organization TradeMe) to engage with us in that role. Already one incredible thing has happened, we’re now thinking more in terms of the product than of projects.
Since the team is already recording tasks and defects in an open source issue-tracking program, it is a simple matter to extend the fields to accommodate story points and hours remaining. Because people tend to be out of the office more often around a weekend, we decide to start sprints on Wednesday and have them run fortnightly.
The product owner and creative director convert all the tasks into user stories, breaking some things down, aggregating tasks together, and rewording them to be customer facing. Once the stories are written, the team gathers to play a game of planning poker. We find a small story that we all agree is worth one point, and then look at a couple of recently finished stories to help calibrate size. We then start to build historical data to help with initial velocity calculations.
Many of the interesting things involved with an estimation meeting start to happen: discussions over items too vague or big to be estimated, the true value of a particular story, breaking dependencies, and how to implement certain pieces. The meeting moves slowly. I try to break off discussion when it no longer seemed beneficial. After a few hours, we’ve only estimated a dozen items and have over a hundred items remaining. Still, the team declares the meeting a total success because they have enough for the first sprint.
Fast-Forward
It’s now mid-March. We have the majority of the backlog estimated and prioritized. Three sprints under are our belt, not counting sprint zero, which we used for preparation and learning (much like playing a hand of cards face-up). All this clarity into the effort involved leads to the director admitting that the contract negotiated with the customer (our partner, TradeMe) is fixed in both scope and deadline. It took six months to come up with the contract, and at this point we have only four more months until we’re supposed to launch the working product at the end of June. Our own estimates put the completion date for the product somewhere between mid-August and the end of October. We’ve got a bit of a problem.
The director and product owner work very hard to keep the product backlog prioritized. They sort things into themed stories well and do a good job of balancing out the work load. However, they want to be much further along and are constantly trying to push more work on the team. I decide to relent. Instead of planning April’s last sprint, we take on everything the contract specifies should be done by us at this point. Our best and last sprint finished fifteen story points; the work remaining is ninety points, seven times more work than has ever been completed in a sprint. Even with the director’s help coding, by the end of the sprint most of it is still incomplete. Neither the estimation date nor the velocity have changed too much.
In May, the suggestion is made that perhaps the stories are estimated incorrectly. How could the team be certain that something was worth five points while something else seemingly completely unrelated would be worth eight? We group user stories that have the same estimated point value to see if they are truly the same size, including finished stories. This comparison does show that some stories should be a different size or be re-categorized. We recalculate the velocity. Our estimated completion date still falls, at best, in September and, at worst, in November. Neither is close to the July deadline promised in the contract.
Fortunately we are now working in constant contact with our partner/customer because they are functioning as the customer for the sprints. They can check out our code and build in their environment. We have them on the phone for sprint reviews. The constant interaction clarifies that this project cannot go according to the contract. What they have seen accomplished to date makes them want different things, and some of these changes require direct input from them. This is a dependency we cannot control.
Eventually we all agree that the contract “nice-to-have” date is indeed more flexible than we thought, with a “drop dead” date beyond the fixed term of the contract. As I look at our sprint estimation, we are now knocking down about twenty points per iteration, with about 170 points yet to go. We are cruising to an October launch.
Play
After a couple more iterations, and well past the original deadline, it is made clear that the software needs to ship soon. Collaboration is high, with some of our developers working at our partner’s site. An incentive deal is reached: if people are willing to work weekends from now to launch, everyone will get a bonus week’s vacation immediately following launch. Perhaps this helps. The software launches on 7 September 2007, well within our original prediction of mid-August and the end of October.
Our agile estimates were proven correct. They helped to interject reality into an unrealistic contract. This agile estimation thing really works.
The Company: Vianet
The universal marketing system for tourism that utilizes the latest mapping technology and real-time booking capabilities to give travelers complete destination information.
The Partner: TradeMe
68 percent of New Zealand's internet traffic is to online auction site TradeMe, CEO Sam Morgan and Development Manager Rowan Simpson told me when I visited their Wellington office. TradeMe is New Zealand's version of eBay, even down to the color scheme. But it's more than just an auction site now. Over the past seven years it has expanded into major verticals such as jobs and motoring. Also it's probably New Zealand's biggest social networking platform (even though it's not strictly speaking an Social Networking System).
Even considering all that, when TradeMe sold for a cool $700 million New Zealand dollars earlier this year to Australian media company Fairfax, the price tag astounded many people in New Zealand and Australia. At the time, that amounted to nearly $500 million US dollars. To put that into perspective, it was a deal worth approximately 15 times more than the much more hyped sale of Flickr to Yahoo the year before.
