Tuning Agile to Your Business Objectives
This chapter is from the book
This chapter is from the book
This chapter is from the book
We started with the “why” of agile practices—that is, principles. But there’s a deeper “why” that we need to explore. It’s really the “why” of the principles you choose to follow. Although agile is a powerful concept, becoming agile just because “it’s the thing to do” won’t automatically help a business achieve what it is trying to accomplish. To successfully create the significant breakthroughs in your development effectiveness that are possible with agile, it has to be aligned with why you want to do it in the first place and what you need to achieve from it. You should be agile not just to be agile, but to drive the business results. Start by describing your business situation.
First, sit down and identify your current business realities (where the money and time is going) and strategic objectives (where the money would ideally be spent for your business situation):
Cost and cycle-time drivers
What are the activities that are consuming your resources and limiting your ability to deliver on time?
Value proposition
What are your products or services really trying to achieve for the customer?
The final step in establishing the backdrop for an agile transformation and making sure the efforts are tied to your real business needs is to combine the two lists (where are you investing now; where do you need to invest) for a clear view into the problem areas. Use this analysis to establish clear development objectives for your organization. The biggest cost drivers that aren’t key to the value proposition are targets for improvements. If these cost drivers can be architected out of the system, automated, or engineered away, it can free up resources for innovations critical to the value proposition.
The best way to talk about how we tuned agile to our business objectives is to clearly spell out our business situation before our large-scale agile experience began. So in this chapter, we’ll give you an overview of HP FutureSmart Firmware that we’re using as the case study. We’ll identify our costs and cycle-time drivers prior to our agile transformation, explain the value proposition our business needed, and then list the development objectives that came out of our analysis and would effectively close the gap we faced.
Background: HP FutureSmart Firmware Case Study
HP FutureSmart Firmware is the name the business uses to market the latest embedded code used to control LaserJet hardware and enable solutions resident on the device. A typical laser printer consists of the electromechanical print engine, which is controlled by a formatter. The formatter is made up of both electronics and logic. The logic is referred to as firmware but can be considered a full-on multitasking operating system. In this case of the firmware for enterprise-class printers and copiers (FutureSmart), it is as complex as the operating system and logic running your PC or laptop or smartphone.
Our business challenges started with a predicament of two-year long development cycles for delivering firmware, and of complex embedded software that had been slowly aging over many years and needed to be re-architected. Big-bang integrations were frequent. Before learning about agile, we had some early improvements and got to the point of 8-week development cycles, a daily build or two, and a nightly smoke test. But even with these significant improvements, some significant inefficiencies existed.