Comments on: Latency, Throughput, and Variance http://www.threeriversinstitute.org/blog/?p=209 Thoughts on programming Thu, 29 Jul 2010 21:19:43 -0400 hourly 1 http://wordpress.org/?v=3.0.1 By: Optimizing the whole « Leaning towards java http://www.threeriversinstitute.org/blog/?p=209&cpage=1#comment-685 Optimizing the whole « Leaning towards java Thu, 11 Jun 2009 15:16:01 +0000 http://www.threeriversinstitute.org/blog/?p=209#comment-685 [...] 11, 2009 in Uncategorized I read this plog post a while back and it struck me as having a lot af lean elements to it. I see a lot of [...] [...] 11, 2009 in Uncategorized I read this plog post a while back and it struck me as having a lot af lean elements to it. I see a lot of [...]

]]> By: Matt Wynne http://www.threeriversinstitute.org/blog/?p=209&cpage=1#comment-603 Matt Wynne Sun, 31 May 2009 15:37:07 +0000 http://www.threeriversinstitute.org/blog/?p=209#comment-603 Interesting thoughts. Kanban advocates like David Anderson and Karl Scotland think about this stuff a lot, and would argue that reducing variance first is the key - in the end, the main thing the customer / business wants is *predicatbility*, and achieving that predictability gives the team the peace and stability they need to gradually pick up their pace. By measuring cycle time (latency) and variance of that cycle time and aiming to reduce both while imposing a tight limit on the amount of work in progress, I think Kanban adds some really useful tools to the ones in the XP box. Interesting thoughts. Kanban advocates like David Anderson and Karl Scotland think about this stuff a lot, and would argue that reducing variance first is the key – in the end, the main thing the customer / business wants is *predicatbility*, and achieving that predictability gives the team the peace and stability they need to gradually pick up their pace.

By measuring cycle time (latency) and variance of that cycle time and aiming to reduce both while imposing a tight limit on the amount of work in progress, I think Kanban adds some really useful tools to the ones in the XP box.

]]> By: Zachary Spencer http://www.threeriversinstitute.org/blog/?p=209&cpage=1#comment-593 Zachary Spencer Fri, 29 May 2009 15:34:10 +0000 http://www.threeriversinstitute.org/blog/?p=209#comment-593 EXCELLENT article. I'm sharing it with the entire product development team at my company! We're very heavily focused on increasing thoroughput without considering variance or latency. EXCELLENT article. I’m sharing it with the entire product development team at my company!

We’re very heavily focused on increasing thoroughput without considering variance or latency.

]]> By: Richard Veryard http://www.threeriversinstitute.org/blog/?p=209&cpage=1#comment-591 Richard Veryard Fri, 29 May 2009 09:36:23 +0000 http://www.threeriversinstitute.org/blog/?p=209#comment-591 Nice example, but I'd argue that the "latency" and "throughput" in your example are perceived rather than actual - developers may think they've finished a particular task, but if they haven't done it properly they haven't really finished it after all. Like when you go through the revolving door but you've left one of your bags outside on the pavement and have to go back outside again. I often draw system diagrams where I show how "perceived" and "actual" get out of synch, and how you could bring them back together. But I admit - these diagrams can get more complex than yours. Nice example, but I’d argue that the “latency” and “throughput” in your example are perceived rather than actual – developers may think they’ve finished a particular task, but if they haven’t done it properly they haven’t really finished it after all. Like when you go through the revolving door but you’ve left one of your bags outside on the pavement and have to go back outside again.

I often draw system diagrams where I show how “perceived” and “actual” get out of synch, and how you could bring them back together. But I admit – these diagrams can get more complex than yours.

]]>