Organization Refactoring – Move Team

Goal

The goal of this refactoring is to align the team structurally and strategically with the domain where it creates the most value, removing friction and improving collaboration, flow, and ownership.

Bad Smells

This refactoring addresses organisational misalignment signals such as:

“The teams we should interact with, have their own events.”
“We don’t really have much to do with the business owners in our domain.”
“We support a different part of the organisation than the teams around us.”
“The product this team works on is not part of our domain architecture.”

Overview

To prepare for moving a team to the right domain (e.g. ART, Tribe, or Value Stream), start by assessing the situation. Focus on alignment with the business value stream, customer journey, product lifecycle, and operational dependencies. Consider whether the team primarily contributes to a Business Value Stream (e.g. value delivery, product outcomes) or a Development Value Stream (e.g. platform, enabler, or capability building).

Assess the situation and decide whether to proceed with this refactoring or explore other solutions. Co-create a compelling change story that explains the purpose, direction, and benefits of the move. Create a backlog of transition activities, estimate the work, and assess risks. Define continuity checks and effect measures. Document a rollback plan in case outcomes are not achieved. Kick off with the teams and stakeholders, iterate toward the new setup, and review effects. Dare to pivot or rollback if needed and explore alternative options to improve alignment and value contribution.

🧭 Assess the Situation

Funding & Budget Ownership

Check: Is the team funded by its current domain, and can that responsibility be moved?
Why: Misaligned funding creates tension and delivery mismatches.
Precondition: Budget ownership can shift or is neutral enough not to block the move.

Product Management & Backlog Integration

Check: Is there a clear Product Owner / Product Manager in the destination domain?
Why: The team needs alignment with the product strategy, priorities, and feedback loops.
Precondition: A shared backlog or backlog integration plan is in place.

Portfolio Governance & Delivery Structures

Check: Are portfolio decisions and steering aligned with the destination domain?
Why: Conflicting governance can lead to misprioritisation or delivery delays.
Precondition: The team can participate in the portfolio events and rhythms of the target domain.

Architecture & Technical Dependencies

Check: Will the move create new architectural dependencies or orphan existing ones?
Why: Reassigning a team may disrupt architectural alignment.
Precondition: Architecture support is available in the new domain; review needed with architects.

Operational Support & Tooling

Check: Are there major differences in tooling, deployment pipelines, or ops models between current and target domain?
Why: Technical misalignment can create friction and waste.
Precondition: Plan in place for migration or integration of tooling and ops practices.

Team Interfaces & Knowledge Sharing

Check: Who are the team’s key collaborators, SMEs, and interfacing teams?
Why: A move can isolate a team from knowledge or key enablers.
Precondition: The new placement includes access to necessary expertise and support.

▶️ Execute the Move Team Refactoring

Create change story and communicate with team and stakeholders

Make sure the team and stakeholders understand why this move is happening and what success looks like?
Why: A move without purpose or story creates resistance and anxiety.
Precondition: A compelling and relevant change story is co-created with the team and target domain. A first backlog of activities needed for success is created.

Create continuity checks

To ensure that the Move Team Refactoring does not disrupt performance, three key metrics are tracked each iteration:

Team velocity
Customer satisfaction
Team satisfaction

These metrics are accompanied by brief commentary to explain trends, context, and reasoning behind any changes.

Create Change Backlog with Team and Architects

Define and prioritise transition activities collaboratively.

Gather risks:

Team-level risks related directly to the refactoring
Organisational risks from both source and destination departments

Define Exit Strategy with the Architects and the Teams

Check: What are the indicators that the move is working? What if it doesn’t?
Why: You need the ability to course-correct if the move leads to new frictions.
Precondition: A rollback or mitigation plan is prepared in case of failure.

Inject the Change in Delivery Events

Portfolio Planning (PI / QBR): Ensure the right resources are included and work needed for changes in portfolio management process are planned for the coming period.
Iteration Planning: Plan the change backlog work according to agreed capacity allocation.
Iteration Review: Check customer satisfaction. Share findings with stakeholders, and the team to maintain transparency, enable timely intervention, and support continuous improvement.
Iteration Retrospective: Check team satisfaction.

🔙 Conditionally: Rollback Moving the Team

Trigger rollback if:

Delivery is negatively impacted beyond the threshold
Team satisfaction or collaboration deteriorates
Expected benefits are not materialising

Rollback should restore the previous domain setup or pivot into a new improvement track.

🧩 Related Refactorings and Considerations

Consider other possible refactorings if full team movement is not viable:

Extract responsibilities instead of teams
Create a boundary-spanning role
Form a virtual or cross-domain team

Be mindful of:

Change fatigue
Identity loss within the team
Alignment with broader transformation goals or OKRs