Scenario: A technology company is creating a consumer electronics solution that involves hardware, software and web components. Three separate teams, located in different parts of the company’s facility, create three platforms. Each platform has its own development team, its own Program Manager and its own Project Manager. There are no clear and distinct processes for integrating these three elements until the final stages of the project.
Almost without exception, we find that technology companies are organized around functions and people have a fierce loyalty to their discipline. People live within their own functional world and only occasionally appear at a cross-functional meeting to discuss product delivery. Technology companies tend to have cultures that place functional allegiance above cross-functional delivery.
For decades companies have heard about the need to break through the stovepipes, and about “flatter” organizations. However, the complexity of today’s multi-platform products has increased the tendency of organizations to divide into stovepipes, and these fiefdoms jealously defend their turf. Companies become preoccupied with internal issues and lose track of customers.
When three separate teams execute projects in parallel, they inevitably run into problems that could have been avoided had they looked at the product they were creating from the customer’s perspective, as an integrated whole rather than as a collection of components. This disconnected, disintegrated approach to product development creates delays, rework, waste and frustration when the teams need to integrate on the back end.
Typically, hardware managers become frustrated since their teams have the longest lead times, as well as milestones that require risk builds. Hardware managers often face negative feedback because their teams are not as adaptive or responsive to change as their software or web colleagues. In short, Hardware teams appear to be less agile than their counterparts in Software.
The brute fact is that customers don’t care about internal structures or internal differences. Teams that want to deliver excellent multi-platform products need to focus on what customers care about the most. The customer-driven approach is for all three teams to contribute to prototypes that resemble the end product that the customer is going to use. The cross-functional product development process should focus on the customer rather than on mirroring the company’s structure.
Multi-platform developers also need a set of tools and a framework that will allow hardware to maximize its adaptability and speed. But first companies are advised to consider three changes that are more cultural than technical.
1. Foster a common culture for product development across platforms.
The Agile Manifesto promoted an attitude as much as a process. It promoted a culture characterized by flexibility, trust, team empowerment, and frequent communication between team members. None of these cultural traits are unique to software and all of them are essential for creating customer-centric, multi-platform products.
In a study we conducted with Silicon Valley executives several years ago, we found that of the highest rated Agile software practices, three were, at root, cultural: daily contact between team members, strong team culture, and customer ownership. Daily standup meetings are a specific Agile software practice that may or may not apply to hardware, but the broader purpose of these meetings – fostering a culture of frequent communication and functional integration – is not software-specific. Each of these Agile practices were aspects of culture that are applicable to any team endeavor.
The following attitudes, cultural traits, and related processes move readily from Agile software to hardware:
- High performance teams
- Self-organized teams
- Senior management trust and team empowerment
- Customer ownership & daily team interaction
- Tolerance around changing requirements
2. Create a mindset shift from a functional focus to a customer focus.
As multi-platform development teams begin to have a common culture and a common language, they begin to emerge from a focus on their internal, functional world. They find that, rather than structuring projects around functions, they create prototypes and interim products that resemble the end product.
This approach depends on frequent integration points and a common timeline that binds together the hardware, software and web teams. It also implies an empowered team that has considerable control over its resources and that learns and continuously improves.
3. Create a bridge between hardware and software techniques
While there are significant differences between software and hardware projects, a customer-centric focus necessitates a bridge between the two, which forms the starting point for a common language between the two groups. This bridge includes creating links between Agile development practices and best practices in hardware development. Once this divide has been bridged, then the separate teams begin to speak a common language, which, in turn, facilitates communication and builds trust.
Unfortunately, there are now more stovepipes than ever. But successful technology companies are finding ways to break through them and to make Hardware teams more agile. They’re doing this by keeping the focus on customers, by communicating early and often, and by producing rapid iterations that are organized around the value a customer would notice.
Wait! Before you go…
Choose how you want the latest innovation content delivered to you:
- Daily — RSS Feed — Email — Twitter — Facebook — Linkedin Today
- Weekly — Email Newsletter — Free Magazine — Linkedin Group
John Carter has been a widely respected adviser to technology firms over his career. John is the author of Innovate Products Faster: Graphical Tools for Accelerating Product Development. As Founder and Principal of TCGen Inc., he has advised some of the most revered technology firms in the world.