The first phase focuses on:

Embracing the Pull System.
Instead of assigning all tasks during the planning meeting, gradually move towards a pull system. This can be achieved by waiting until the last responsible moment to assign work, allowing team members to pick up tasks as they become available.

Limiting Work in Progress (WIP).
Implement WIP limits to discourage multitasking and encourage completion of tasks before starting new ones. A simple rule like "prefer completing work over starting new work" can be a starting point. You can express this with practical limits, like a team of three developers having a WIP limit of 4-5 items, allowing for occasional exceptions. This shift in focus moves from individual rules to rules governing the flow of work items.

Prioritising High-Value Items.
Introduce a "Ready" column after the "To Do" column on your Scrum board. This column holds high-priority tasks that team members can pick up when available, promoting focus on the most important work. Keep the limit for this column small to ensure it serves its intended purpose.

Visualising Flow.
Enhance your workflow visualisation by splitting the "In Progress" column into two: "In Development" and "In Test." Allocate WIP limits for each stage based on the average time spent. Our current WIP limit is 5, so we might assign a limit of 2 to the phase that requires less time, In Test for example. Therefore In Development will have a WIP limit of 3. This allows for team members with specific skill sets to focus on their strengths – those who enjoy writing code can specialise in development tasks while others focus on testing. It's important to note that this allows specialisation without forcing it.

Coordinating Handoffs.
To facilitate smooth handoffs between stages, a "Complete" column can be added between "In Development" and "In Test." This allows developers to move a completed task to "Complete" for a tester to pick up when available, or skip the “Complete” and keep working on it if they don’t want to hand it off. As we added a new column, we also should slightly increase our WIP to 4. This might cause an increase of Lead Time, but we hope to balance it with the advantage of specialisation.

Transparency and Agreement.
Establish clear handoff expectations by creating a simple checklist on the board. This ensures everyone on the team understands the expected outcome at each stage, reducing confusion and promoting transparency.

In the second phase of the transition, our focus shifts to optimising cycle time and making the planning process more responsive.

Fixed-Size Sprint Backlog.
With a smaller, prioritised "Ready" queue, the traditional Sprint Backlog becomes less essential. Instead of estimating a fixed scope for each iteration, we set a fixed size for the backlog itself. For example, if the team completes one item per day and the iteration is two weeks (10 working days), the backlog limit might be set to 10 or 12 items. During the regular Sprint planning the team will need only to fill the available slots up to their limit. This ensures there's always something valuable to work on, without overwhelming the team.

In the final phase of the transition, we fully embrace the pull system and decouple planning and release cycles.

Independent Cadences.
Instead of rigidly aligning planning and release cycles, we can decouple them to better suit the team's needs. For example, the team might opt for monthly releases while conducting weekly planning sessions to prioritise the next batch of work.

Just-in-Time Planning.
By setting an order point for the backlog, we can trigger planning when the number of items drops below a certain threshold. This ensures a continuous flow of work without excessive upfront planning. For instance, if the team completes one item per day and the backlog limit is 10, a planning session would be triggered when the backlog reaches 5 items. Therefore the planning might happen once a week on average.

By the end of this third phase, your team will have transitioned to a truly Kanban-based workflow.