agile# Balancing Innovation with Maintenance Through Collaboration (1/41)
A manufacturing marketplace SME running FDD with a team of six to fifteen people has a balance problem. The company operates a B2B platform connecting small manufacturers with raw material suppliers. The platform handles supplier discovery, request for quotation, order management, logistics coordination, and payment processing. The company has been around for five years and has forty one employees. Nine of them are in product development. (2/41)
The team is stuck. Seventy percent of every iteration goes to maintenance. Bug fixes, server patches, database optimizations, dependency updates, security patches. The work is necessary. It is not optional. But it leaves only thirty percent for innovation. New features, new capabilities, new experiments. Thirty percent is not enough. (3/41)
The roadmap has twelve features planned. At the current rate, they will take eight months. The market is moving fast. Two competitors launched similar platforms in the last six months. They are adding features faster. They are attracting the company's customers. Last quarter, three manufacturers left the platform, citing lack of new features as the reason.
The team must find a balance. (4/41)
Masaru Ibuka built Sony on innovation through collaboration. His model was straightforward. He did not separate the innovators from the maintainers. There was no research and development team that invented things and an operations team that kept things running. There was one team that did both. (5/41)
The collaboration was structured around a rotation. Every engineer spent six months on innovation, then six months on maintenance, then six months on innovation again. The rotation was mandatory. It forced every engineer to understand both sides. The engineer who spent six months on maintenance understood the pain of maintaining a system without innovation. The engineer who spent six months on innovation understood the pain of building new features on a fragile system. (6/41)
Ibuka applied the same thinking to product development. When Sony developed the Walkman, the team that designed the hardware also wrote the firmware. The team that wrote the firmware also tested the manufacturing process. The team that tested the manufacturing process also designed the packaging. The collaboration eliminated silos, which eliminated handoffs, which eliminated delays. The Walkman was developed in eighteen months, half the industry average. (8/41)
For a manufacturing marketplace SME, the balance problem is the same. The team spends too much time on maintenance and does not have enough time for innovation. Ibuka's approach says: rotate the team between innovation and maintenance. The rotation creates empathy. The empathy creates collaboration. The collaboration creates balance.
## The Core Principle (9/41)
Ibuka's innovation through collaboration was built on a simple insight. The best way to balance innovation with maintenance is to rotate every engineer between both disciplines. The person who builds the feature also maintains it. The person who fixes the bug also understands why the feature was built that way. (10/41)
Ibuka did not separate Sony's hardware designers from its firmware writers. He made them collaborate. The collaboration produced the Walkman in eighteen months. For a manufacturing marketplace SME, the balance problem is the same. The team is stuck in maintenance mode. The answer is to rotate the team. The rotation creates empathy, the empathy creates collaboration, and the collaboration creates balance.
## Four Steps to Apply Innovation Through Collaboration (11/41)
1. Audit the Current Iteration to Quantify the Innovation Maintenance Split
Ibuka audited Sony's development process in 1953. The audit revealed that sixty percent of engineering time went to manufacturing support. That was maintenance. The remaining forty percent was for innovation. The audit quantified the split, created a baseline, and set a target to increase innovation time to fifty percent. (12/41)
Your team should do the same. For a manufacturing marketplace SME, the audit might look like this. The product manager leads a one hour session with all nine team members. The session reviews the last four iterations using tracking data. The data shows hours spent on each type of work: bug fixes, server patches, database optimizations, dependency updates, security patches, new feature development, user experience improvements, and performance optimizations for new features. (13/41)
The audit reveals the split. Iteration one: 112 maintenance hours, 48 innovation hours. That is seventy percent maintenance, thirty percent innovation. Iteration two: 105 maintenance hours, 55 innovation hours. Sixty six percent to thirty four percent. Iteration three: 118 maintenance hours, 42 innovation hours. Seventy four percent to twenty six percent. Iteration four: 98 maintenance hours, 62 innovation hours. Sixty one percent to thirty nine percent. (14/41)
The average split is sixty eight percent maintenance and thirty two percent innovation. The target is fifty percent. The gap is eighteen percent. That eighteen percent must be reclaimed from maintenance and redirected to innovation.
For an FDD team of six to fifteen, the audit should happen in one session of no more than one hour. It should review at least four iterations. For FDD, the audit should be part of the overall model review as a review input. (15/41)
2. Create a Six Month Rotation Schedule That Moves Every Engineer Between Innovation and Maintenance
Ibuka created a six month rotation schedule for Sony's engineers. It was published, visible, and mandatory. Every engineer knew when they would rotate. The rotation forced every engineer to experience both disciplines. The experience created empathy, the empathy created collaboration, and the collaboration created balance. (16/41)
You should create the same kind of schedule. For a manufacturing marketplace SME, it might look like this. The product manager creates a twelve month schedule with two phases. The nine engineers are divided into two groups. Group A has five engineers. Group B has four. (17/41)
During phase one, months one through six, Group A works on innovation. Their work includes a supplier recommendation engine, automated request for quotation, and real time logistics tracking. Group B works on maintenance: bug fixes, server patches, database optimizations, dependency updates, and security patches. (18/41)
During phase two, months seven through twelve, the groups rotate. Group A moves to maintenance. Group B moves to innovation. The rotation happens at the start of month seven. It is mandatory. (19/41)
The rotation creates empathy. Group A spent six months building the supplier recommendation engine. They know its architecture, its edge cases, and its failure modes. When they rotate to maintenance, they fix bugs in that engine faster. Last month, Group A fixed a bug that caused the engine to recommend suppliers with low quality ratings. The fix took two hours. Under the old process, it would have taken eight hours because the engineer would have needed to understand the engine first (20/41)
. The rotation created that understanding upfront.
The understanding reduces maintenance time. The reduced maintenance time creates capacity. That capacity is redirected to innovation.
For an FDD team of six to fifteen, the rotation schedule should cover twelve months with two six month phases. For FDD, the schedule should be part of the feature planning process as a planning input.
3. Pair an Innovator with a Maintainer on Every Feature to Build Shared Ownership (21/41)
Ibuka paired Sony's hardware designers with firmware writers on every product. The pairing was mandatory. It forced collaboration, produced shared ownership, eliminated silos, eliminated handoffs, and eliminated delays. (22/41)
You should pair an innovator with a maintainer on every feature. For a manufacturing marketplace SME, the pairing might look like this. The product manager creates a pairing matrix that matches every innovation engineer with a maintenance engineer based on complementary skills. (23/41)
Pair one: Priya, an innovation backend developer who built the supplier recommendation engine, is paired with Tom, a maintenance backend developer who fixed the low quality rating bug. They work together on the next feature, automated request for quotation. Priya designs the feature. Tom reviews it. Tom asks what happens if a supplier does not respond within twenty four hours. Priya says the system sends a reminder. Tom asks what happens after three reminders (24/41)
. Priya says the system escalates to the manufacturer. Tom asks what happens if the escalation fails. Priya says the system logs the failure and notifies the account manager. Tom's questions improve the design and reduce future maintenance. (25/41)
Pair two: Lena, an innovation frontend developer who built the real time logistics tracking dashboard, is paired with Sam, a maintenance frontend developer who fixed the dashboard's memory leak. They work together on a mobile app for manufacturers. Sam asks what happens if a manufacturer loses internet connectivity while placing an order. Lena says the app queues the order and sends it when connectivity is restored (26/41)
. Sam asks what happens if connectivity is not restored within twenty four hours. Lena says the app notifies the manufacturer and offers to send the order via SMS. Again, the questions improve the design and reduce future maintenance.
Every innovation engineer is paired with a maintenance engineer. The pairing builds shared ownership, reduces future maintenance, and creates capacity for innovation. (27/41)
For an FDD team of six to fifteen, every feature should have a pair consisting of one innovation engineer and one maintenance engineer. The pairing should be mandatory and part of the feature design process.
4. Run a Monthly Feedback Loop Where Maintainers Tell Innovators What Is Hard to Maintain (28/41)