agile# Using Everyday Low Price Strategy to Fix Cross-Functional Team Dynamics in Transportation Hardware (1/52)
A transportation hardware SME running SAFe with 16 to 50 people has a cross-functional team dynamics problem. The company makes a fleet management device for trucking companies. It plugs into a vehicle's diagnostic port and tracks location, fuel consumption, engine health, driving behavior, and maintenance schedules. The device connects to a cloud dashboard where fleet managers monitor their trucks. (2/52)
The company has been around for 11 years. It has 230 employees. Product development has 38 people running SAFe across two agile release trains. Train one has 22 people across four Scrum teams. Train two has 16 people across three Scrum teams.
The cross-functional dynamics are broken. The teams operate in silos. The hardware team does not talk to the cloud team. The cloud team does not talk to the data team. The data team does not talk to the QA team. The silos create delays. (3/52)
Last month, the hardware team shipped a new device prototype with a new GPS chip. They did not tell the cloud team about the new chip. The cloud team's software was not compatible. The integration failed. The prototype was delayed by three weeks.
The three-week delay cascaded. The data team could not test their analytics engine. The QA team could not run end-to-end tests. The program increment commitment was missed. (4/52)
The fleet management device industry is competitive. The delays are costly. The company's biggest competitor launched a similar device two months ago with the same features. The competitor got to market first. The cross-functional dynamics must be fixed. (5/52)
Sam Walton built Walmart on the everyday low price strategy. The model was simple. Walmart did not rely on sales or promotions. They offered low prices every day. The strategy eliminated the need for constant negotiation. Suppliers knew what Walmart would pay. Buyers knew what Walmart would charge. The process was predictable and efficient. (6/52)
But Walton's approach was not just about prices. It was about eliminating friction. Walmart's supply chain was integrated. Suppliers were connected to inventory systems. Stores were connected to distribution centers. Distribution centers were connected to suppliers. The integration eliminated information gaps, and the information gaps were the friction. (7/52)
When a store ran low on product, the supplier knew automatically. When a supplier had excess inventory, the distribution center knew automatically. The constant information flow kept the system running smoothly. The system was efficient because the friction was low. (8/52)
Walton applied the same thinking to Walmart's internal operations. Store managers shared sales data with each other. The data was not hoarded. When one store found a better way to stock shelves, the other stores learned. The constant information sharing kept the organization learning. The organization was efficient because the internal friction was low. (9/52)
For a transportation hardware SME, the cross-functional team dynamics problem is the same. The teams operate in silos. The silos create information gaps. The information gaps are the friction. The friction creates delays. The delays are costly. (10/52)
Walton's everyday low price strategy says: eliminate the friction. Connect the teams. Share information constantly. The constant information flow will keep the organization running smoothly. The organization will be efficient because the friction is low.
## The Core Principle (11/52)
Walton's everyday low price strategy was built on a simple insight: friction is the enemy of efficiency. Walmart eliminated friction by connecting suppliers, distribution centers, and stores into a single integrated system. The integration eliminated information gaps, and the information gaps were the friction. (12/52)
For a transportation hardware SME, the cross-functional team dynamics problem is the same. The teams operate in silos. The silos create information gaps. The information gaps are the friction. The friction creates delays. (13/52)
Walton's everyday low price strategy says: eliminate the friction. Connect the teams. Share information constantly. The constant information flow eliminates information gaps. The elimination of information gaps reduces delays. The reduction in delays improves efficiency.
## Step 1: Identify the Information Gaps Between Teams (14/52)
Walmart identified the information gaps between suppliers, distribution centers, and stores. The gaps were where friction lived. When a store ran low on product, the supplier did not know. The gap was the delay between the store running low and the supplier starting production. Walmart measured the gap. It was five days. Walmart closed the gap by connecting the store's inventory system to the supplier's production system. The gap dropped to zero. (15/52)
Your team should identify the information gaps between teams with the same approach. For a transportation hardware SME, the identification might look like this.
The release train engineer facilitates a session with representatives from all seven Scrum teams. Each team writes down the information they need from other teams on sticky notes. The notes are posted on a board with seven columns, one per team. (16/52)
The hardware team posts three notes. We need to know when the cloud team changes the API. API changes affect our firmware. We need to know when the data team changes the data schema. Schema changes affect our sensor data format. We need to know when the QA team changes the test environment. Environment changes affect our firmware flashing process. (17/52)
The cloud team posts two notes. We need to know when the hardware team changes the communication protocol. Protocol changes affect our API. We need to know when the data team changes the analytics requirements. Requirements affect our dashboard. (18/52)
The data team posts two notes. We need to know when the hardware team changes the sensor data format. Format changes affect our analytics engine. We need to know when the cloud team changes the data storage layer. Storage changes affect our queries.
The QA team posts two notes. We need to know when any team changes anything. We need 48-hour notice. We need a single source of truth for what is changing. (19/52)
The second biggest gap is between the hardware team and the data team. The hardware team changed the sensor data format six weeks ago. The data team did not know for two weeks. The two-week gap caused the analytics engine to produce incorrect results.
The identification took two hours. It created visibility. The visibility created urgency. (21/52)
For a SAFe team of 16 to 50, the information gap identification should happen at the start of every program increment. It should take no more than two hours. It should produce a prioritized list of gaps. For SAFe, the identification should be part of program increment planning as a planning input.
## Step 2: Create Low-Friction Information Channels That Run Constantly (22/52)
Walton created constant information channels. Walmart's suppliers were connected to Walmart's inventory systems. The connection was not a weekly meeting or a monthly report. It was constant. When a store's inventory changed, the supplier knew instantly. The constant channel eliminated the information gap.
Your team should create low-friction information channels that run constantly with the same approach. For a transportation hardware SME, the channels might look like this. (23/52)
The release train engineer sets up three channels.
Channel one is a shared change log. It is a single document in Confluence. Every team updates it when they make a change that affects other teams. The update takes two minutes. It includes what changed, why it changed, and when it changed. The document is a chronological log, not a wiki. It is simple and visible to everyone. (24/52)
Channel two is a Slack channel called cross-team changes. Every team posts to the channel when they make a change that affects other teams. The post includes a link to the change log entry. The channel is a notification system, not a discussion forum. It takes thirty seconds to post. (25/52)
Channel three is a weekly fifteen-minute standup. One representative from each team shares what their team changed in the last week and what they are changing next week. It is a synchronization meeting, not a status meeting. It is short and focused. (26/52)
The three channels are set up and run constantly. The hardware team changes a sensor data format. They update the change log and post to the Slack channel. The data team sees the notification, reads the log entry, and updates the analytics engine. The process takes thirty minutes. It used to take two weeks. The constant channels eliminated the information gap. (27/52)
For a SAFe team of 16 to 50, the constant information channels should be set up at the start of every program increment. They should include a shared change log, a Slack channel, and a weekly standup. For SAFe, the channels should be part of the release train operating model as operating model components.
## Step 3: Make Cross-Functional Dependencies Visible on a Single Board (28/52)
Walmart made supplier dependencies visible. Distribution centers had boards showing which stores needed which products. The boards were visible to everyone. The visibility eliminated surprises. When a store needed product, the distribution center saw it and acted. No emergency orders. No stockouts.
Your team should make cross-functional dependencies visible on a single board with the same approach. For a transportation hardware SME, the board might look like this. (29/52)
The release train engineer creates a physical board in the team area. It has seven columns, one per team. Each column has three swimlanes: Changes we made this week, Changes we are making next week, and Changes we need from other teams. (30/52)
The hardware team posts a card in swimlane two. It says, We are changing the communication protocol from MQTT to gRPC in sprint three. This affects the cloud team's API and the QA team's test environment. The card is red. Red means other teams are affected.
The cloud team sees the card and adds one to their column: We are updating the API to support gRPC in sprint three. We need the hardware team's gRPC specification by the end of sprint two. (31/52)
The QA team sees both cards and adds one: We are updating the test environment for gRPC in sprint four. We need the updated API and the new firmware by the end of sprint three.
The board is visible. The dependencies are visible. The timeline is visible. Everyone sees what is changing, who is affected, and when it happens. The visibility eliminates surprises. (32/52)
Last week, the hardware team posted a red card about changing the GPS chip in sprint five. The cloud team saw it immediately and started updating their drivers in sprint three. The two-week head start prevented the integration failure that happened last month. (33/52)
For a SAFe team of 16 to 50, the dependency board should be set up at the start of every program increment. It should be physical and in the team area. It should be updated daily. For SAFe, the board should be part of program increment planning as a planning artifact.
## Step 4: Eliminate Handoffs by Temporarily Embedding Specialists Across Teams (34/52)
Walton eliminated handoffs between Walmart's distribution centers and stores. When a new store opened, Walmart did not hand it off to the store manager. They embedded experienced managers from other stores. The embedded managers trained the new store's staff and stayed for six weeks. The embedding eliminated the learning curve. The new store reached full productivity in six weeks instead of six months. (35/52)
Your team should eliminate handoffs by temporarily embedding specialists across teams with the same approach. For a transportation hardware SME, the embedding might look like this. (36/52)
The release train engineer identifies the most critical cross-functional dependency: the communication protocol between the hardware team and the cloud team. The hardware team writes the firmware. The cloud team writes the API. The firmware and the API must match. When the firmware changes, the API must change. The handoff between firmware changes and API changes is the bottleneck. (37/52)
The release train engineer embeds a cloud developer on the hardware team for two sprints. The cloud developer sits with the hardware team, attends their daily standups, and reviews the firmware code. They see firmware changes as they happen. They do not wait for the change log or the Slack notification. They see the changes in real time and start updating the API immediately. (38/52)
The handoff is eliminated. The API is ready when the firmware is ready. The integration works on the first try.
In sprint three, the hardware team ships the new firmware. The cloud team ships the new API on the same day. The integration succeeds. No three-week delay. No cascading failures. No missed program increment commitments. (39/52)
In sprint four, the cloud developer returns to the cloud team and trains the rest of the team on the new protocol. The knowledge transfer is fast because the developer spent two sprints on the hardware team and understands the firmware. The embedding created knowledge transfer and reduced future dependency risk. (40/52)
For a SAFe team of 16 to 50, the specialist embedding should happen at the start of every program increment. It should last two sprints. The embedded specialist should sit with the host team and attend their ceremonies. For SAFe, the embedding should be part of program increment planning as a planning decision.
## Step 5: Measure the Friction Reduction Every Program Increment (41/52)