- Background: HP FutureSmart Firmware Case Study
- Cost and Cycle-Time Drivers Prior to HP FutureSmart Firmware
- Value Proposition of Re-Architecting the HP FutureSmart Firmware and Processes
- Establish Development Objectives from the Business Analysis
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Cost and Cycle-Time Drivers Prior to HP FutureSmart Firmware
The first step is to understand how resources are being deployed and what activities are driving development costs. Honestly assess where software development dollars are spent. It is also important to understand the cycle time for a developer to implement a change and then get feedback on if it works.
Throughout this experience, we’ve had around 400 developers worldwide needing to get firmware and test changes integrated into a firmware system consisting of several million lines of code, with very high quality expectations. When we started our transition to agile development, we had created a complex environment and code base over many years that took most of our efforts just to keep it going:
- Ten percent of our staffing was for “build bosses” (someone on each team designated as its full-time code integrator) plus a central integration team to accomplish the one or two builds per day we were doing, with many teams doing integration their own way. This was a very manual process of integrating and reverting code, consuming several highly qualified engineers who, as a result, spent very little time actually coding. In this environment, each project team would have a build boss that would gather all the changes by the team every few days and bundle them into a collection of changes. These changes would then be provided to the integration team that would be taking changes from 15 different build bosses for a nightly build with a smoke test. This nightly build would then be provided for additional testing over time. This approach resulted in a resource sink, but more importantly, it could be up to a week from the time a developer made a change until it got into broader testing on the main code branch to see if it worked.
- Twenty percent of our resources were spent doing detailed planning for future feature commitments that quickly became obsolete or were never delivered. Business and marketing expected a clear “final list of features” one year before product introduction. To provide that commitment, we worked on detailed work breakdowns, schedules, integration plans, and estimates, all of which required constant maintenance and revision, because new discoveries and adjustments are an integral part of any high-tech research and development (R&D) effort.
- Twenty-five percent of our resources were consumed porting the existing codebase and features from one product to another. Because of schedule pressures, we hadn’t spent sufficient time to abstract out the code and encapsulate product differences. We also ended up splitting the organization and creating three distinct branches of the previously common code. This meant more focus for each part of the business, but fewer resources for assuring code maintainability.
- Fifteen percent of our development costs were for manual test execution, which was a significant cost driver. Although we had a very large test suite, most of it needed to be executed by technicians, which was a large chunk of the budget. It also meant very long feedback loops from test to development. It was sometimes weeks or even months between when a firmware change was made and when a test actually found an issue. This made for long find/fix cycles, and it consumed a large chunk of the budget. This also meant that we frequently could not add products to our plans because we did not have the resources for testing them.
- Twenty-five percent of development resources were deployed supporting existing products, either fixing customer change requests or making sure we had a consistent set of features across printers and multifunction products (MFPs). With a focus over many years on getting each product to market, we had created multiple code branches that all had to be maintained for the products in the field.
- This left us with limited capacity to focus on the value proposition and customer differentiation that would actually provide the business value needed for continued success.
So that gives a clear picture of where we were allocating our resources. If you add it all up, the firmware development cost drivers were 95% “get the basic product out” and just 5% adding innovation. That is exactly opposite of where the business needed us to be in order to be competitive in the marketplace. So where did we want to be spending our money? What was the business asking for? The next section describes our value proposition for making such a substantial change.