Skip to main content
16 events
when toggle format what by license comment
Dec 22, 2011 at 18:56 comment added Thomas Owens The question has been updated to enhance that paragraph. Your recent comment should be worked into an answer, along with answering my other questions about what agile organizations are actively doing to achieve the PP goal to the approval of auditors and what types of feedback auditors are giving organizations about these other techniques. I think you might be right: The SPs explicitly mentioned might be inappropriate for some projects, but it doesn't address what people are doing to obtain and maintain CMMI certification using alternative practices, since each PA must be covered.
Dec 22, 2011 at 18:52 history migrated from programmers.stackexchange.com (revisions)
Dec 22, 2011 at 18:16 comment added S.Lott @ThomasOwens: "and the need for a WBS which would be of little value in many agile and lean projects" The implementation of the CMMI through a bunch of Specific Goals is laudable. But merely laudable. The CMMI is not a bunch of specific goals. It's a bunch of vague, broad principles. Some of the Specific Goals are biased in a bad direction. The PP goal is a bad idea -- as stated. The statement of that goal is bad. The goal is good. CMMI is good. The way it is stated has a clearly bad bias. What more do you want to know? It's bad. You know that. Excellent.
Dec 22, 2011 at 18:14 comment added S.Lott @ThomasOwens: The specific words "I disagree with some of their conclusions about how other practices of Scrum satisfy (or fail to satisfy) practices required by CMMI." Must either be explained with details (i.e., list the conclusions) or removed from the sentence. The fact that you actually mention disagreements without detailing the disagreements makes it impossible to understand what you disagree with. Either remove the sentence or name the disagreements so that we can understand what you're saying.
Dec 22, 2011 at 16:30 comment added Thomas Owens I still don't understand what edit you think should be made - the paper has flaws in other sections unrelated to my question. The fact that flaws exist in other sections is only relevant in that it calls into doubt the part that addresses my question (which may or may not be flawed). As far as your second comment, there is also no organization. There is nothing, other than my mental disconnect between the CMMI, the assertion of the SEI that the CMMI can be successfully applied to agile projects, and the need for a WBS which would be of little value in many agile and lean projects.
Dec 22, 2011 at 16:20 comment added S.Lott "do I address this issue before it becomes a problem?" You are addressing the issue before it becomes a problem. "Did you go through a CMMI audit in an agile organization?" is irrelevant to your organization and your audit. Since you have no audit, you're doing the right thing. When you have an audit, you may need to change. Do you get what Agile means? Solve one small problem now. Don't anticipate future problems which do not yet exist.
Dec 22, 2011 at 16:18 comment added S.Lott @ThomasOwens: "the paragraph regarding the academic paper" was perfectly clear. The specific words "I disagree with some of their conclusions about how other practices of Scrum satisfy (or fail to satisfy) practices required by CMMI." Must either be explained with details or removed. Those words. The reference to unexplained disagreements. Either explain or omit. The paper -- as a whole -- is good. Those words, however, are confusing.
Dec 22, 2011 at 15:32 comment added Thomas Owens As far as asking an auditor: There is no auditor. There is no audit. There is no agile project team. There's no estimate, nor is there a WBS. There is a problem - how, as a software process engineer, do I address this issue before it becomes a problem?
Dec 22, 2011 at 15:29 comment added Thomas Owens The purpose of the paragraph regarding the academic paper in my question is to demonstrate an attempt to find an answer prior to asking this question, finding some research, but having problems accepting this as an answer due to other concerns with conclusions made by the authors, which add doubt to all of their statements. The reasons why this paper is questionable is beyond the scope of this question, however people answering should be aware that I researched this topic, found a possible answer, but I can not simply accept it on its own without further confirmation.
Dec 22, 2011 at 15:14 comment added S.Lott @ThomasOwens: "alternative means of producting estimates" can mean anything. You're not talking about "estimates". You're talking about "project scope" which is a slightly different thing. If your Defined or Managed process is Scrum where backlog == scope, backlog story points == overall estimate, and sprint story points == sprint estimate, you seem to be covered. Don't ask me for audit input; I'm not your auditor. Ask your auditor. If they expect to see waterfall, Agile will fail. If they expect to see Managed, Agile will pass.
Dec 22, 2011 at 15:12 comment added S.Lott @ThomasOwens: "because Scrum doesn't explicitly call for size measures". You're saying this is factually incorrect. It's not a conclusion. It's a premise. Please update the question to state this. Or remove the whole mess.
Dec 22, 2011 at 15:11 comment added S.Lott @ThomasOwens: "specific conclusions in the paper I don't agree with, that's beyond the scope of this question". Then remove the words from the question. Please update the question to remove this.
Dec 22, 2011 at 14:21 comment added Thomas Owens Can you also expand on your "no"? Did you go through a CMMI audit in an agile organization? What did your organization do to achieve the requirements of this process area? What were the comments presented by the auditors in their close-out review session?
Dec 22, 2011 at 14:20 comment added Thomas Owens As far as specific conclusions in the paper I don't agree with, that's beyond the scope of this question. But one is that Scrum doesn't satisfy SP 1.2 Establish Estimates of Work Product and Task Attributes. The authors assert that this is because Scrum doesn't explicitly call for size measures, but that's because Scrum is a process framework that is meant to be tailored. Scrum clearly calls for a team to identify a size measure (often, but not always, Story Points) and a method to compute them (often, but not always, Planning Poker). By implementing Scrum, you implement this CMMI requirement.
Dec 22, 2011 at 14:17 comment added Thomas Owens Only this one SP seems to be plan-centric, unlike the others in the Project Planning process area as well as most of the other process areas. The others are generic enough to apply to both agile and plan-driven methodologies, even in the text regarding CMMI 1.3, which accounts for agile methodologies. Ignoring this practice outright would be risking CMMI Level 2, and it doesn't leave much room the way its written for modification (although CMMI is supposed to be a framework, and many other practices lend themselves well to modification and interpretation).
Dec 22, 2011 at 14:04 history answered S.Lott CC BY-SA 3.0