Thanks Henrik. Interesting points. I'd love to address them and learn more about what your ideal team structure looks like.

- Since I was introduced to agile I've never worked with a dev team that didn't use sprints to mange workload. I've had design teams working with kanban and tasks not being restricted to time. My teams haven't necessarily been avant-garde though. Nonetheless, surely you still need a backlog with stories even if you don't use sprints?

- I admit that I struggle to understand the BA role fully. I find them extremely useful to take off workload from me if they're around and likewise I assume that they'd be doing a lot of requirement gathering if I wasn't around. (I mean, you do need to collect requirements in some shape or form right, waterfall or not?)

- Yes, I do think it's good to separate people in phases of the design and development process. I think Discover should come before Design and Develop and we need different skill sets for each phase. The true potential doesn't have to be 'everyone does everything' but rather 'everyone does their thing really well'. T-shapes and skill overlap is great as long as responsibilities are clear.

- UX researcher - yes, 100%, but they would be a support role, as the workload normally allows them to be a x-team resource. I'm on a war against the UX designer title because it's given me too much headache in the past. I'll go with UI or Product designer for now (but UI designer has been hijacked to mean more or less visual design). The system designer referred to would be in charge or a design system of reusable components. Well, titles are always tricky. WIP.

If you have something similar to my article but from your experience I'd be keen to have a read. This is only my very personal view based on what I've seen over the years (mainly in the UK and in Eastern Europe partner agencies) but it sounds like there are team structures and ways of working that I'm not even aware of.