image description


Client: A Social Networking Company, which raised 400k of venture funding, had a goal of going live with a regional social network within 6 months with its first release, and a v2 within 12 months.

The Company followed the traditional waterfall method with the first person hired as the product manager who wrote detailed market requirements in the first month. Frequently with such documentation, it was done without taking into account what technologies will be used to implement those requirements. A small development team was hired and a project plan was hastily prepared with half the desired features being development in 6 months and the rest in 12 months. As with many projects, the technology stack was chosen based on the preferences and past experience of the technical lead, not on any analysis of what platform will meet the market needs.

Unfortunately, after a month, the project was behind three months ? yes, that?s not a typo. After several revisions to the project plan by the development team the updated project plan projected a set of features which was supposed to be done in 6 months would take the whole 12 months, and all the desired features would take more than 2 years. Heated debates between the development team and product manager ensued regarding the desired features versus ?must have? features. The product manager insisted that all the features he had documented were in-fact ?must have? for the first two releases and must be released within the first 12 months to meet the market needs.

The work continued on and 3 months later looked even worse. A QA lead had been hired, who reported that the modules deemed to have been completed were in fact full of defects. For the next month, the two developers responsible for those defective modules were so busy trying to fix their code, they had no available time to work on any new development. This led to a revision of the project schedule yet again.

The new plan needed to incorporate time required for testing and bug fixing. As a result, it was projected that all the desired features would take 4 years to build! The CEO who now faced having to bring the bad news to the board fired one of the developers, and the other resigned within a few days.

We were brought in at this stage. We evaluated the requirements, the work that had been completed to date, and put together a new project plan to release a product with the features required. As a result we were able to release a public website within 4 months of being engaged, following STRIDE ? our agile development methodology adapted for globally distributed development - We augmented the existing development/ QA team, not replacing it, in order to capitalize on the existing knowledgebase and completed work. After the initial release, we were able to release updates every month.


  • 1. Learn New Tricks
    1 day training to the team (The developer was begged to come back) on STRIDE ? an agile process inspired by SCRUM
  • 2. Nothing is Leaner than? Free?
    Open source alternatives for software development stack and picked Linux, MySQL and PHP.
  • 3. All Features Are Equal But Some are More Equal Than Others (Note: this refer to the famous quote from ?Animal Farm? a political satire ? sounds odd if you haven?t read the book or heard the phrase). We Convinced the CEO and the Product Manager to change the format of the feature prioritization list as they were currently ranked ?High?, ?Medium?, and ?Low? ? with 60% of the items marked high. Instead, we utilized a strict ranked list of features.
  • 4. Why Build When You Can Reuse?
    We also decided to use open source packages ?Joomla? and ?Zimbra? to implement the functionality.
  • 5. Account for Feasibility
    Given that we were using packaged applications module, many features were really easy to implement just by configuration, rather than development. In light of this, we went through the product backlog (prioritized list of features) and assigned features to releases based on ease of implementation.
  • 6. Iterative Test Driven development with constant customer feedback
    We switched to a model where we released software iteratively to an active website (it was labeled as an ?Alpha? and ran in a different domain name and exposed it to controlled set of users. The iterations were every two weeks in the beginning but we quickly went to weekly releases to this. We also used Test Driven Development methodology where test cases are written ahead of developing a module.