Really depends on the team and how "productivity" is determined. This may be an alternative approach to some but it seems to have been beneficial so far.
It's a combined view of:
- what's getting done in X sprint/month/(however you measure it).
- frequent blockers faced by the team
Combining these two will give you (presumably a project manager) a more informed stat of how productive the team is (as a whole). If you are seeing a developer constantly quiet and not getting a ton of stuff done, reach out to them, see where they are stuck. Could be a complex problem they are solving that's taking longer or a new bug with a package/framework/language your developing in but have yet to ask the team for assistance on.
In the past, teams I've worked with had essentially a weekly 0.5-1 hour meeting where they discussed hot topics, issues anyone was running into, concerns and sharing knowledge on new features/new things. The team would also discuss any blockers anyone was having, and attempt to resolve them or at least figure out a path to resolution.
In the end, less blockers ideally would mean more productivity. Development isn't always as cut and dry as X task takes Y time.