[wpietri]

> Why do you want a display of open PRs at all?

All PRs are WIP, and minimizing WIP is very valuable in product development processes. See Reinertsen's The Principles of Product Development Flow for the math, but basically high/unpredictable latency drastically limits the pace of learning and causes a lot of upstream thrash and waste.

I remember talking with one team at the bird-themed social media company that was frustrated with slow PRs; they dropped average delay from 3-4 days to under 4 hours. They said it made a huge experiential difference and they loved the change.

[geofft]

Yes, I understand why you'd want to focus on solving the number of open PRs. I agree that keeping that number down is good. My question is why do you want to put this on a TV screen.

If you want people to focus on open PRs, tell them to open GitHub on their computers, don't tell them to look up at a TV screen periodically. Treat it like alerts: you have a list of open things to deal with and you need to get that number to zero. There's no threshold greater than zero of a long-term acceptable number of open PRs.

If the problem is that they have other things to look at too, installing yet another TV screen won't solve that, your team needs to make the management decision of what to prioritize. Options include making a unified dashboard of incidents/alerts/PRs/support tickets (and encoding which ones sort to the top), setting up a PR review rotation (i.e., for one week, completing reviews is your top priority barring all-hands-on-deck incidents), treating open PRs as alerts and escalating them if nobody replies within 4 hours, removing other work by deciding you'll deprioritize low-impact alerts (and hope that the increased development velocity ends up solving problems), etc.

[wpietri]

The notion with information radiators not that you tell them to look up. The notion is that people naturally look at things while walking around or when idle, so it's valuable to make important things visible. It also serves as a way to trigger and focus discussions.

For example, consider the Kanban board. Here's one I built a while back: http://williampietri.com/writing/2015/the-big-board/

We loved having a physical map of what we were up to. We'd have our daily stand-up around board and discuss it. You'd know when something was completed, because you'd see somebody move a card. I would often know when the product manager was thinking about something he'd go over to look right at it. That often sparked conversations. And we'd all have a feel for how work was flowing, something we'd talk about in our weekly retro.

Could this have been replicated with a system of alerts? No. Alerts are interruptive and necessarily threshhold-driven. I don't want my people caught in a cycle of continuous reactivity to things that at some point in history were seen as important enough to configure an alert. Except for emergencies, I want them to be serene, thoughtful, and proactive, which is very hard to achieve if you're continuously juggling alerts.

So I'd put up something with PR stats if it were something I wanted us to be aware of. Especially so if it were an item of concern in previous retros. Maybe that would eventually lead to an alert (although I'd hope not). But the first step in solving a problem is understanding the problem, and I think information radiators are great for that, especially when problems are thorny and don't have obviously correct answers.

[geofft]

That's fair - I think part of it is also that you don't really have a green vs. red state (which is a good part of what I object to in the demo presentation), you just have a general feel, and no specific state is defined as an actual problem. (And most of what you're trying to achieve is a shared sense of what's being done, which is very different from a shared sense of what's broken and needs fixing.)