Comments for Lean Software Engineering http://leansoftwareengineering.com Essays on the Continuous Delivery of High Quality Information Systems Fri, 06 Nov 2009 02:07:00 -0800 http://wordpress.org/?v=2.8.5 hourly 1 Comment on Scrum-ban by Prakash http://leansoftwareengineering.com/ksse/scrum-ban/comment-page-2/#comment-6161 Prakash Fri, 06 Nov 2009 02:07:00 +0000 http://leansoftwareengineering.com/?page_id=337#comment-6161 Hi Corey, A wonderful article and a great way to simplify Kanban learning. I don't get this line- "This might be a point that’s been lost on the Scrum community: it’s never necessary to estimate the particular sizes of things in the backlog. It’s only necessary to estimate the average size of things in the backlog" What is meant by estimating average size of things? All things are not the same. Let us say I have 5 MMFs in my in process (Specify) and my initial task is to find the lead time so that I can identify the limits for my backlog. I find that the lead time for 5 MMFs is 20 days. This means 1 MMF takes 4 days. If my sprint is 10 business days I could complete approx 3 MMFs. This would mean my backlog limit could be 3. But these 5 MMFs have varying sizes. If I have to identify MMFs of similar sizes to fit in my backlog (3) I would have to spend considerable time planning, breaking stories etc.. In the process if I don't find MMFs that could fit the 3 backlog limit then what happens? Hi Corey,
A wonderful article and a great way to simplify Kanban learning. I don’t get this line- “This might be a point that’s been lost on the Scrum community: it’s never necessary to estimate the particular sizes of things in the backlog. It’s only necessary to estimate the average size of things in the backlog”

What is meant by estimating average size of things? All things are not the same. Let us say I have 5 MMFs in my in process (Specify) and my initial task is to find the lead time so that I can identify the limits for my backlog.

I find that the lead time for 5 MMFs is 20 days. This means 1 MMF takes 4 days. If my sprint is 10 business days I could complete approx 3 MMFs. This would mean my backlog limit could be 3. But these 5 MMFs have varying sizes. If I have to identify MMFs of similar sizes to fit in my backlog (3) I would have to spend considerable time planning, breaking stories etc.. In the process if I don’t find MMFs that could fit the 3 backlog limit then what happens?

]]> Comment on Scrum-ban by Why we went from Scrum to Kanban « Derk de Geus http://leansoftwareengineering.com/ksse/scrum-ban/comment-page-2/#comment-6157 Why we went from Scrum to Kanban « Derk de Geus Tue, 03 Nov 2009 20:45:35 +0000 http://leansoftwareengineering.com/?page_id=337#comment-6157 [...] http://leansoftwareengineering.com/ksse/scrum-ban/ Filed under: Uncategorized Leave a comment Comments (0) Trackbacks (0) ( subscribe to [...] [...] http://leansoftwareengineering.com/ksse/scrum-ban/ Filed under: Uncategorized Leave a comment Comments (0) Trackbacks (0) ( subscribe to [...]

]]> Comment on Scrum-ban by Cumulative Flow Diagrams with Google Spreadsheets – BEKK Open http://leansoftwareengineering.com/ksse/scrum-ban/comment-page-2/#comment-6155 Cumulative Flow Diagrams with Google Spreadsheets – BEKK Open Tue, 03 Nov 2009 10:18:40 +0000 http://leansoftwareengineering.com/?page_id=337#comment-6155 [...] to never work on more than a certain limited number of items at any given time. Kanban, CONWIP and Scrum-ban are similar techniques to achieve this. I won’t go into detail about these techniques in this [...] [...] to never work on more than a certain limited number of items at any given time. Kanban, CONWIP and Scrum-ban are similar techniques to achieve this. I won’t go into detail about these techniques in this [...]

]]> Comment on Scrum-ban by PixelPoop » Decision “Gimbal Lock” and the Art of Temporary Commitment http://leansoftwareengineering.com/ksse/scrum-ban/comment-page-2/#comment-6154 PixelPoop » Decision “Gimbal Lock” and the Art of Temporary Commitment Mon, 02 Nov 2009 20:04:52 +0000 http://leansoftwareengineering.com/?page_id=337#comment-6154 [...] prioritization in any process, but particularly in the most flexible Agile processes…like ScrumBan, of which I am a [...] [...] prioritization in any process, but particularly in the most flexible Agile processes…like ScrumBan, of which I am a [...]

]]> Comment on Kanban systems for software development by I2E » Blog Archive » Sesiones Agile Open Space 2009 parte 1 http://leansoftwareengineering.com/2007/08/29/kanban-systems-for-software-development/comment-page-1/#comment-6152 I2E » Blog Archive » Sesiones Agile Open Space 2009 parte 1 Mon, 02 Nov 2009 08:12:19 +0000 http://leansoftwareengineering.com/2007/08/29/kanban-systems-for-software-development/#comment-6152 [...] A la conclusión que llegue es que kanban sobre todo encaja bien en procesos de mantenimiento o helpdesk, aunque también hay ejemplos en los que utilizan kanban para el desarrollo de software. [...] [...] A la conclusión que llegue es que kanban sobre todo encaja bien en procesos de mantenimiento o helpdesk, aunque también hay ejemplos en los que utilizan kanban para el desarrollo de software. [...]

]]> Comment on Multi-site teams: travel and the half life of trust by Bernie Thompson http://leansoftwareengineering.com/2009/08/06/multi-site-teams-travel-and-the-half-life-of-trust/comment-page-1/#comment-6139 Bernie Thompson Fri, 30 Oct 2009 17:25:57 +0000 http://leansoftwareengineering.com/?p=1951#comment-6139 Hi Matthias - very good point. And, in fact, where you do have "teams" within open source - usually people working for Canonical vs. Red Hat vs. Intel, etc. -- those tensions and "us vs. them" feelings definitely rear their heads (e.g. see http://video.google.com/videoplay?docid=3385088017824733336 ) The "pressure valve" is the choice to (at least temporarily) branch and deliver competing versions -- even if it's not always the right thing for the technology or for the end-user. And that happens all the time in Open Source. Commercial companies tend to force their teams to deliver just one thing. Hi Matthias – very good point. And, in fact, where you do have “teams” within open source – usually people working for Canonical vs. Red Hat vs. Intel, etc. — those tensions and “us vs. them” feelings definitely rear their heads (e.g. see http://video.google.com/videop.....7824733336 ) The “pressure valve” is the choice to (at least temporarily) branch and deliver competing versions — even if it’s not always the right thing for the technology or for the end-user. And that happens all the time in Open Source. Commercial companies tend to force their teams to deliver just one thing.

]]> Comment on Coffee cup kanban by Bernie Thompson http://leansoftwareengineering.com/2008/05/21/coffee-cup-kanban/comment-page-1/#comment-6138 Bernie Thompson Fri, 30 Oct 2009 17:18:00 +0000 http://leansoftwareengineering.com/?p=374#comment-6138 Dave - great point! That's exactly right. Dave – great point! That’s exactly right.

]]> Comment on The capture-recapture code inspection by Bernie Thompson http://leansoftwareengineering.com/2007/06/05/the-capture-recapture-code-inspection/comment-page-1/#comment-6137 Bernie Thompson Fri, 30 Oct 2009 17:16:48 +0000 http://leansoftwareengineering.com/2007/06/05/the-capture-recapture-code-inspection/#comment-6137 Hi Andrew - Capture-Recapture is actually designed for and really most valid with >2 reviewers. Corey's diagrams show 2 to illustrate better, but check out http://leansoftwareengineering.com/capture-recapture-inspection/ and especially the google docs spreadsheet template (set up for 5 reviewers) to see how it goes. Thanks for commenting! Hi Andrew – Capture-Recapture is actually designed for and really most valid with >2 reviewers. Corey’s diagrams show 2 to illustrate better, but check out http://leansoftwareengineering.....nspection/ and especially the google docs spreadsheet template (set up for 5 reviewers) to see how it goes. Thanks for commenting!

]]> Comment on The capture-recapture code inspection by Andrew Wagner http://leansoftwareengineering.com/2007/06/05/the-capture-recapture-code-inspection/comment-page-1/#comment-6132 Andrew Wagner Wed, 28 Oct 2009 16:02:15 +0000 http://leansoftwareengineering.com/2007/06/05/the-capture-recapture-code-inspection/#comment-6132 Any thoughts on how to generalize for more than two reviewers? Any thoughts on how to generalize for more than two reviewers?

]]> Comment on Lean scales differently than Agile by As Reuniões Diárias Funcionam para Equipes Grandes? « Acordo Coletivo (Empregados Petrobras) http://leansoftwareengineering.com/2007/09/03/lean-scales-differently-than-agile/comment-page-1/#comment-6131 As Reuniões Diárias Funcionam para Equipes Grandes? « Acordo Coletivo (Empregados Petrobras) Tue, 27 Oct 2009 22:25:19 +0000 http://leansoftwareengineering.com/2007/09/03/lean-scales-differently-than-agile/#comment-6131 [...] Ladas também acrescentou suas preocupações sobre a estratégia de comunicação no scrum-of-scrums para equipes grandes. Ele disse que o scrum-of-scrums poderia criar uma hierarquia profunda à medida que ele for [...] [...] Ladas também acrescentou suas preocupações sobre a estratégia de comunicação no scrum-of-scrums para equipes grandes. Ele disse que o scrum-of-scrums poderia criar uma hierarquia profunda à medida que ele for [...]

]]>