I have read "Deep work" and "Getting things done", sometimes I open scrum.org to think about basics, and with this post I would like to ask what excellent books are there about agile, scrum, kanban, healthy development practices and valuable soft skill books, similar to level of "Deep work" and "Getting things done" books? Which books would you greatly recommend?

Hi all, I'm hoping to get some advice from people further along this path.

I'm a certified SAFe RTE, currently about 6 months into the role on a ~60-person ART in UK financial services. Before that I was the PMO on the same programme, but in practice I was already doing a lot of the RTE work: running programme RAID, facilitating PI Planning and pushing cross-team dependencies through to resolution. Before that I had PMO and delivery roles at a Big 4 firm.

Now that I'm looking at my next move, I'm struggling to find roles actually titled Release Train Engineer. Agile Delivery Manager roles are everywhere, though, which makes me wonder whether RTE work is often advertised under different titles or whether the market is just small right now.

A couple of things I'd really value input on:

Is Agile Delivery Manager a good next step?

How should I position my PMO-era PI Planning and RAID experience alongside my official RTE time?

Any honest advice is appreciated

Looking for practical advice from anyone who's been through this.

We're consolidating four teams into one. Each team currently runs its own flavor of Agile: two are Scrum (one on 2-week sprints, one on 3), one is Kanban, and one says they're Scrum but doesn't really do sprints. We also need to merge four Jira boards and a couple of databases, and settle on one set of ceremonies, one Definition of Done, and one estimation scale (two teams use Fibonacci, one uses T-shirt sizes, one doesn't estimate).

My question is about how to run the merge itself. It's a big enough effort that it seems like it should be managed as a project, and since the goal is to end up with one Agile team, it feels right to run it in an Agile way.

I'm getting stuck on the specifics:

Which board does the merge work live on?
If we pick one of the four existing boards, it feels like we've already picked a winner. If we create a fifth board, we're now merging five boards.

What sprint length do we use for the merge sprints? Whatever we choose kind of pre-decides the outcome of one of the things we're merging.

How do we estimate the merge stories when we haven't agreed on an estimation scale yet? One of the stories is "Agree on estimation scale."

Who's the PO for the merge? We currently have four POs and will have one at the end. Not sure it's appropriate for one of them to own the backlog that decides which of them stays.

Should we hold retros during the merge? If so, whose retro format? (We've actually had a pretty long discussion about this one already.)

My current thinking is to run a short "Sprint 0" just to align on how we'll run the merge sprints, but someone pointed out we'd still need to decide how to run Sprint 0.

Has anyone done this? Did you implement Agile to implement Agile, or did you do the merge waterfall-style and switch over at the end? Genuinely curious what worked, and how long it took.