Comments on: How can an Agile team influence the quality of upstream components http://maccherone.com/larry/2010/04/15/how-can-an-agile-team-influence-the-quality-of-upstream-components/ Visualization is like photography with data as the subject. Impact is the result of perspective, focus, and illumination. Fri, 03 Feb 2012 11:09:14 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Larry Maccherone http://maccherone.com/larry/2010/04/15/how-can-an-agile-team-influence-the-quality-of-upstream-components/comment-page-1/#comment-62 Larry Maccherone Tue, 27 Apr 2010 22:19:29 +0000 http://maccherone.com/larry/?p=191#comment-62 @Jeff. I was responding to a question from an actual client who indicated that he was worried about the quality of the upstream components, so it wasn't my thesis. So, you may be surprised to hear that I agree with your statement that the upstream code is not necessarily of lower quality. My background is with high assurance environments with safety and security concerns. Some of the process definitions I have used in those environments tend to produce higher quality (especially from a defect perspective) code than your average Agile team.<br /><br /> I'm not sure what you are objecting to with respect to peer review. Can you please say why you think it is "complete BS"? You may also be surprised to hear that I also think there is no gain in trying to force Agile "religion" on a non-Agile team. In re-reading my post, I can see how you might think I was saying that especially when I said, "You don’t control their process but you may be able to influence it at the boundary between them and you." However, it was not my intent to imply that the downstream team should try to force the upstream team to adopt Agile practices. All of my suggestions target the frequency and level of feedback that the downstream team gives to the upstream team. These things could be done even if the downstream team was not Agile. I chose these particular activities because they are requests that the non-Agile upstream team might be willing to accommodate. I might also point out that peer review is not generally accepted as an Agile practice. Some might consider that suggestion anti-Agile. Its inclusion in my list is related to feedback and has nothing to do with Agile religious doctrine. @Jeff. I was responding to a question from an actual client who indicated that he was worried about the quality of the upstream components, so it wasn’t my thesis. So, you may be surprised to hear that I agree with your statement that the upstream code is not necessarily of lower quality. My background is with high assurance environments with safety and security concerns. Some of the process definitions I have used in those environments tend to produce higher quality (especially from a defect perspective) code than your average Agile team.

I’m not sure what you are objecting to with respect to peer review. Can you please say why you think it is “complete BS”?

You may also be surprised to hear that I also think there is no gain in trying to force Agile “religion” on a non-Agile team. In re-reading my post, I can see how you might think I was saying that especially when I said, “You don’t control their process but you may be able to influence it at the boundary between them and you.” However, it was not my intent to imply that the downstream team should try to force the upstream team to adopt Agile practices. All of my suggestions target the frequency and level of feedback that the downstream team gives to the upstream team. These things could be done even if the downstream team was not Agile. I chose these particular activities because they are requests that the non-Agile upstream team might be willing to accommodate.

I might also point out that peer review is not generally accepted as an Agile practice. Some might consider that suggestion anti-Agile. Its inclusion in my list is related to feedback and has nothing to do with Agile religious doctrine.

]]> By: Jeff http://maccherone.com/larry/2010/04/15/how-can-an-agile-team-influence-the-quality-of-upstream-components/comment-page-1/#comment-61 Jeff Tue, 27 Apr 2010 19:35:41 +0000 http://maccherone.com/larry/?p=191#comment-61 This is pretty much BS. Your entire thesis is predicated on the fact that the Agile team produces higher quality code than the non-agile team. This is not necessarily the case. Your point about meeting cadence and automated testing stands. Your point about peer review is complete BS. I recommend focusing on the API/Interface, and not so much on trying to force the Agile 'religion' on the non-Agile team. This is pretty much BS. Your entire thesis is predicated on the fact that the Agile team produces higher quality code than the non-agile team. This is not necessarily the case.

Your point about meeting cadence and automated testing stands.

Your point about peer review is complete BS.

I recommend focusing on the API/Interface, and not so much on trying to force the Agile ‘religion’ on the non-Agile team.

]]>