When I did it, it was less regimented: we got everyone in a room for a whole day, making out teams’ right plans and dependencies on a physical wall, using pieces of string to show dependencies. It was not only fun to do but helped everyone get a better understanding of what was going on and avoided some dependencies that would have bitten us in the butt without this. I’d post a picture if I could :)
Have you ever tried Big Room Planning? I first observed it at LEGO, and then tried it with all of the Tech teams at King. Definitely interesting, but also hard to do.
I have facilitated a few, but it doesn't alleviate the challenges Kent outlined above - it helps with alignment and transparency. However. most orgs fail to put in sufficient slack (why - see Henrik's video on the resource utilization trap) and then everything comes apart rather quickly.
I don’t know if there is a really good description, but I found this article that talks about how LEGO uses it and why. https://velocityagile.substack.com/p/lego-using-big-room-planning-to-calm
When I did it, it was less regimented: we got everyone in a room for a whole day, making out teams’ right plans and dependencies on a physical wall, using pieces of string to show dependencies. It was not only fun to do but helped everyone get a better understanding of what was going on and avoided some dependencies that would have bitten us in the butt without this. I’d post a picture if I could :)
Have you ever tried Big Room Planning? I first observed it at LEGO, and then tried it with all of the Tech teams at King. Definitely interesting, but also hard to do.
I haven't tried it. Link?
You can always watch this video with Henrik Kniberg when he has big room planning at Lego. https://m.youtube.com/watch?v=TolNkqyvieE
Still, it doesn’t fix dependencies- it just tries to address them.
I have facilitated a few, but it doesn't alleviate the challenges Kent outlined above - it helps with alignment and transparency. However. most orgs fail to put in sufficient slack (why - see Henrik's video on the resource utilization trap) and then everything comes apart rather quickly.
I always thought that applying network analisys on codebases data would help orgs to understand software dependency complexity.
In more details:
1. Create a 2-mode network (committer.team_id x git_repo),
2. Project it into 2 single-mode networks (commiter.team_id x committer.team_id and git_repo x git_repo)
3. Generate centrality metrics on the 2 single-mode networks to find out important nodes and sub-graphs.
Do you think it could be a proxy for the Awareness item?
That's one path to awareness. See also "Your Code as a Crime Scene".