Monday 8 November 2010

Build to the end and decide when to Release....

Attended the iDilute meeting last weekend, a meeting with some 6-7 odd highly energetic and intellignet brainstormers... One of the topic of discussion was around the success of various startups and products in todays competitive markets. While brainstorming products , methodologies , product management and development teams.. we discussed the best approaches that work for each of them. One of them i couldnt just stop myself from wiring over here... A topic that gets you in the war zones... How to decide your release dates...

Release dates Huh?, I believe a very instrumental element in the success of Product Management and ofcourse development teams.. So how do most of the products or companies define what they are releasing and when? Simple... They analyse the market, they find the feature that their customers like / need / want , They define the spec, they estimate , they plan a release date, they create a WBS , they scope and descope the features and wants and must haves, they start working on it and on the scheduled release date they release it[Most times this is a changed date]. In the middle a lot of things change... sometimes requirements, some times markets, sometimes products and sometimes visionaries... most of the time its time that changes, its customers demands that changes... a major killer in this approach is that the expectation changes... I realise when we started working in August '09 on the product we launched this year.. the expectation was to have a JUST new UI, when it reached towards its mid-phase the expectation changed to a MOST POWERFUL UI, when the delivery date neared the expectation was we are building THE MIRACLE PRODUCT. In the end satisfaction when compared with expectations is always 1: 1 milion , and you know which way it goes.... So then how do companies like Facebook work? How do they keep up to the expectations of their customers? How do they bring great features consistently and effectively... This meeting enlightened me of a smarter way they work... One of the attendees who also happens to be an ex-employee of #FB explained the approach of "Build to the end and release" i.e. Work on your product/module till it has neared the completion and then decide when to release it.

Smart, isnt it? pull a roadmap, punch an estimate for every feature [As a project] start working with the plan, be as much agile as you can, define requirements , evolve and once it is ready.. go ahead and say it is going to be ready in XXX days... then let the product team plan the communication and the release date.. Well so much of headache's it avoids for strong , disciplined agile teams...where features are built by what they are meant to do and not by how much we can fit in to the neck of development time available... The quorum debated over this, almost half of the attendees been the traditional managers for whom the only way to complete the thing was to plan it to th end... yet.. I found some real good points in this approach...

1. We all know that our poject costs overshoot the budgets - If you tell me you have always managed within budgets, I have to say you are lying.
2. We all know requirements change - Even if your spec writer is your own customer who wants what he writes.
3. We all know that we like to change and tweak , sometime reform what we built - Even if we say that there exists a CR procedure
4. We all know that we change scope, time or cost to achieve what we planned - Even if we say we did it right.
5. We all know that there are a bunch of angry , unhappy customers sitting there - Even if we write testimonials on our websites.
6. We all know we are atleast 10 years late - Even if we claim we are the first to reach there

When we know we do all of this...then isnt build until you done and then fix expectations a better approach? I remember how much i cursed this approach when one of the Product contact we use was not telling us the release date for the third party viewer software we were using for the Version 20 of their release... I wondered how they managed millions of users and hundreds of big clients... only to learn this year, that if you have to give out quality, you have to accept facts of development attitudes.

Now.. back to reality? Will this approach be adapted by smaller companies? By companies who has a shouting customer who will not renew their contract if X thing is not delivered by Y date? Well the decision is not on can this be done... the decision is Do we want quality....

I wish to trigger this some day, maybe not today... tomorrow definitely.

Thanks to the iDilute forum.

0 comments:

Post a Comment