Browse by year:
The Smart Techie was renamed Siliconindia India Edition starting Feb 2012 to continue the nearly two decade track record of excellence of our US edition.

April - 2012 - issue > Management

Feature Crew Value and Composition

Vishwas Nair
Wednesday, April 4, 2012
Vishwas Nair
As IT organizations become focused in cutting down costs and increasing the quality of products and services, there is an increasing importance being laid on reducing pilferage on real time processes. At Microsoft, the focus has been on building a deep engineering organization. As a practice, teams across various businesses in Microsoft share best practice innovations & solutions and achieve some level of consistency across divisions with local empowerment and creativity. As a part of every product cycle, there is an analysis of what worked well for the product and what needed improvement. Valuable lessons from previous shipping experiences revealed – inefficiencies due to the significantly long time between when the feature was developed and when it was fully tested; inability to reliably predict the ship date of a product; and inability to reduce the scope of features to hit a release date because it was difficult to scale back on features which, although had been coded, had not been stabilized.This lead to the adoption of the feature crew model; a small interdisciplinary team (comprising of PM, developer, tester, UX) responsible for creating (designing, developing and testing) a feature through spec, design, coding, testing and final validation. The term arose during the planning stages of the office 2003 project.
Rudiger Wenzel, Director – Engineering Excellence India, Microsoft share their perspective on this and how feature crew models enhance better communications across disciplines, prevent deferred work, help drive quality upstream and frequently delivering milestones to customers.

The feature crew model was conceived in the 2003 time frame. We always focus on ways to improve our processes and hence looked up at some of the challenges we faced. We are working on cure water fall model which has distinct phases of development. It provides planning, definition, design and final stabilization. This caused a few inefficiencies because when developers write their codes a lot of time is passed by the time it gets to the testers. And then they had to address the bugs that the testers have found. The time of prediction also was usually questioned because these processes took a lot of time to get the bugs fixed. Hence, we were always asked when the product will actually be done. There was an inability to reliably predict the ship date of a product because, invariably, the stabilization of features was deferred towards the end of the project lifecycle. This made it impossible to predict how long the stabilization would last before the product could be deemed ship-ready. It becomes difficult for us to cut and remove some of the features when they are not stable. Finally we came up with the concept where we molded interdisciplinary teams around individual features. A feature is something that you can present to the customer; it’s a customer experience. But in reality, it’s an independently testable piece of work, because in some cases, when you start breaking things down, you may have a piece of infrastructure that is required by customer-facing features. That piece of infrastructure work itself is large enough that you might develop that as an independent feature. A lot of work goes in to the planning stage, and breaking down what you want to present to the customer, and how to arrange that as a set of features, and what the dependencies between those features are.

Teams worked together starting from the inception of the feature, design, coding and the testing. This also involved virtual teams that reported to their individual managers necessarily. The teams comprise of different disciplines of programme managers, developers, testers, user experience experts who are responsible for stabilizing the feature and integrate it with other features. This provided great benefit and this is how the model was conceived and adopted by the entire organization. By putting the area specifics together around the feature from the beginning, it forces them to collaborate, communicate by removing the boundaries between the disciplines.

In office, one thing we measured from the success of the model is its ability of bringing stability in the product development. Prior to Feature Crew, product development was a lot unstable and we rechecked to verify it by other people and test internally. After we moved to Feature Crew model, the stability of the product increased significantly.

For example we used the model while working on visual studio. The whole process involves tremendous interaction between the developers and the programme managers. It involves developers who do coding of the feature, binding of the feature and what the feature should look like and the overall architecture of the product. The second comes the software design engineers in test who are responsible for the quality of the product. They do manual testing, automation testing and make sure the customers are getting the right quality from the product. The third role is of the programme managers in which they decide what the feature should actually look like. They will decide what the customer wants and what the feature should do and specify its functions. Testers are there to deliver the right module of the product under development. All these put together constitute the feature crew.

Share on Twitter
Share on LinkedIn
Share on facebook