Sometimes, we see traditional component teams, adopting Scrum dynamics and trying to sprint within narrow dimensions of their component specialty.
They [teams] go through ‘motions’ of sprinting (attending Scrum events, creating Scrum artifacts, assigning Scrum roles), yet at the end of a sprint, they are not able to deliver a PSPI. Such teams tend to have a weak Definition of Done (DoD).
When multiple component teams sprint, side by side, on the same calendar schedule, this may create the wrong impression of ‘scaling Scrum’.
And example would be team of UI/UX/graphic designers, sprinting “along-side” or “ahead of” business analysts’ teams, infrastructure teams, architecture teams, database teams, library teams… etc, component teams…
Directly from: https://less.works/less/structure/feature-teams
“What is sometimes not seen is that a component team structure reinforces sequential development (a ‘waterfall’ or V-model), with many queues with varying-sized work packages, high levels of WIP, many handoffs, and increased multitasking and partial allocation.”
Opening points:
- The WHO – Designers, UI/UX/User Experience experts and their managers. Others?
- The WHAT – product design, product innovation, user/customer experience
- The WHEN – before or concurrently with Feature/Product Teams?
- The WHERE -(physical or virtual) a separate sprint/team or same sprint, by a ‘sub-team’?
- The WHY:
- selected people are the best to do work?
- selected people cannot do anything else and need to be kept busy?
- developers cannot/do not want to think about design?
- this is by historical organizational design and it is un-touchable?
Opening questions:
- How about OTHER single-function specialty sprints (e.g. BA sprint, Arch sprint, Tech Design sprint…)?
- How about a queueing theory and queue management? Cycle time? WIP?
Reference reading:
- “Feature Teams vs. Product Teams? Organizational Implications of False Dichotomy”
- LeSS training opportunities (virtually and in-person)