Feature Crew Value and Composition Date:   Wednesday , April 04, 2012 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. How Feature Crew helped us better was it drastically improved the way in which we communicated with our clients. The primary value we noticed was the collaboration between these three important people playing important roles of developer, tester and programme manager. Hence, everyone in the Feature Crew works within the same timeframe. As the code gets developed, it gets tested in which the lag time is minimized between the feature development and the validation of its quality. This development happens in feature branches which provide the code isolation needed for the feature crew. The Feature Crew provides a sense of empowerment and a spirit of collaboration by working on a well-defined goal. It enables code sharing without risking the destabilization of the MAIN branch. The developer would also observe improvements due to the focused and collaborative environment in which the teams worked. This model also works great if the teams are split across geographies. We had a product done across three different time zones. Today, most of the business divisions with in Microsoft are using the feature. The adoption of the feature crew model within Microsoft’s teams is informed by valuable lessons from past shipping experiences in regards to: * 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. * 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. Scaling back on scope was further exacerbated by the fact that newly developed features had introduced other dependencies around them that were hard to back out. Additionally many of those features had already been shown to customers via product demos and there were certain expectations set about them shipping in the official release. * Inefficiencies due to the significantly long time between when the feature was developed and when it was fully tested. The lessons learned from the prior shipping experiences shaped the key guiding principles behind the feature crew model which are: * Driving quality upstream – ensuring efficiency by requiring teams to meet certain quality gates and to stabilize their code before their feature can be merged back into MAIN. * Preventing deferred work – ensuring work up front to facilitate early bug detection and resolution, rather than deferring it until later in the development phase * Keeping the MAIN branch customer-ready which allows for more frequent milestone deliveries to customers without the risk of shipping unstable or incomplete feature code, as well as reducing the time required to prepare the final release. * Enforcing a common definition of what completion means across various teams via a common, consistent definition of quality gates with meaningful metrics on project progress. (As told to Vishwas Nair)