Comments on: Counting software defects http://www.mikelunt.com/blog/2006/08/19/counting-software-defects/ Life is great, and it only gets better. Sat, 20 Feb 2010 18:21:18 -0700 http://wordpress.org/?v=2.8.6 hourly 1 By: Speaker City » links for 2006-08-20 http://www.mikelunt.com/blog/2006/08/19/counting-software-defects/comment-page-1/#comment-19 Speaker City » links for 2006-08-20 Sun, 20 Aug 2006 22:00:59 +0000 http://www.mikelunt.com/blog/2006/08/19/counting-software-defects/#comment-19 [...] Continual Improvement » Blog Archive » Counting software defects When looking at a defect chart and waiting for the slope to point downwards, a good question to ask is “Why am I looking at a defect chart?”. (tags: defects agile lunt) [...] [...] Continual Improvement » Blog Archive » Counting software defects When looking at a defect chart and waiting for the slope to point downwards, a good question to ask is “Why am I looking at a defect chart?”. (tags: defects agile lunt) [...]

]]> By: Mike Lunt http://www.mikelunt.com/blog/2006/08/19/counting-software-defects/comment-page-1/#comment-18 Mike Lunt Sun, 20 Aug 2006 15:37:28 +0000 http://www.mikelunt.com/blog/2006/08/19/counting-software-defects/#comment-18 I agree with the transition situation, but a transition situation can quickly become status quo and linger for years. Even with a great project manager, a long list of defects can cloud the perception of the quality, which can lead to other issues within the organization. I’ve heard this explained as internal quality versus external quality, and it seems to make sense. Engineers often confuse the two, when what’s important to the customer is external quality. I agree with the transition situation, but a transition situation can quickly become status quo and linger for years. Even with a great project manager, a long list of defects can cloud the perception of the quality, which can lead to other issues within the organization. I’ve heard this explained as internal quality versus external quality, and it seems to make sense. Engineers often confuse the two, when what’s important to the customer is external quality.

]]> By: Klobetime http://www.mikelunt.com/blog/2006/08/19/counting-software-defects/comment-page-1/#comment-17 Klobetime Sat, 19 Aug 2006 18:37:04 +0000 http://www.mikelunt.com/blog/2006/08/19/counting-software-defects/#comment-17 With a green-fields project, a defect chart doesn't make sense I agree. When transitioning from waterfall to agile, though, it seems a reasonable middle step. Of course, I think that the defects should be prioritized right along with the stories and given time in an iteration accordingly. To me, the real magic of agile is really the prioritization. An agile team should be able to concentrate on just the most important things on their plate. Even if stories and features are split into two separately prioritized features, a solid product manager should be able to bring them together and keep the team focused. A weak project manager, though, is the kiss of death for even a strong agile team. With a green-fields project, a defect chart doesn’t make sense I agree. When transitioning from waterfall to agile, though, it seems a reasonable middle step. Of course, I think that the defects should be prioritized right along with the stories and given time in an iteration accordingly.

To me, the real magic of agile is really the prioritization. An agile team should be able to concentrate on just the most important things on their plate. Even if stories and features are split into two separately prioritized features, a solid product manager should be able to bring them together and keep the team focused. A weak project manager, though, is the kiss of death for even a strong agile team.

]]>