LeSS Scrum Master David Nielsen and I have discussed system dynamics in complex organizational settings, with respect to Velocity, produced by a single team and/or multiple teams. We did only one cut (no dress rehearsals, dry runs or editing).
The following system variables were identified and their cause & effect relationship was ‘unpacked’:
- Ability to use Velocity as a metric
- Degree, to which combined velocity from multiple teams can be used as a measurement
- Effectiveness of team’s estimation techniques
- Likelihood that Customer/Product-centric development is valued, by business and the whole organization
- Dependency on traditional organizational structure and protection of a status quo of component managers
- Dependency on complex frameworks, processes
- Degree of measurement dysfunction
As well as a few helpful proxy-variables to ‘glue’ the model together.
Please, also refer to the following page on System Thinking, to make the best of the video and the model.
I like the idea of doing refinement with a members of multiple teams, but I question how important estimation accuracy is on the productivity, quality or throughput of an Agile team. Velocity is not defined in Scrum, and very light-weight estimation is good enough to do good Agile development. But more estimation overhead does reduce productivity.
Yes, indeed. The purpose of estimation is to have a conversation: CCC = card, conversation, confirmation, not to produce a number. If there is any number to be produced, it should be a free by-product from having a dialogue. Refinement and estimation by ALL teams that are involved in product development (same product, same backlog, same PO), at least, ensure that there is shared understanding of complexity/size of work. Opposite to that, would be X number of component teams, estimating in silos, and pretending that they can just ‘add up’ their story points for a shared velocity 😉