<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space; font-family: Calibri, sans-serif; font-size: 14px; color: rgb(0, 0, 0);">
<div><br>
</div>
<div>Derek wrote:</div>
<div><br>
</div>
<div><i>“I'm not sure if the use of work breakdown structure counts as Agile”</i></div>
<div><br>
</div>
<div>Use of a Work Breakdown Structure (WBS) is simply a good project management practice. It’s orthogonal to Waterfall (or other “plan-based”) lifecycles vs. Agile ones.</div>
<div><br>
</div>
<div>The WBS is no more and no less than simply a catalog of the work (to be) done on that project. It’s pretty difficult to manage a project when you have no handle on what the work to be done is. Where Waterfall/Plan-Based vs. Agile becomes relevant is largely
about when the project’s WBS is developed. The more Waterfall a project is, the more it is expected that the WBS is developed early (because is is expected to be pretty stable over the duration). On the other hand, “Progressive Elaboration” (aka “Rolling-Wave
Planning") is a PMI-recognized best practice that allows you to have an appropriate level of detail in the WBS and the resulting project plan, filling in missing detail as it becomes stable. I like to refer to Agile as “Rolling-Wave Planning on steroids”.
The hierarchical nature of an Agile project’s Product Backlog/WBS comes in how “Epics” get decomposed into “Capabilities” which get decomposed into “Features” which get decomposed into “Stories”.</div>
<div><br>
</div>
<div>A running battle I have with the agilista crowd is their insistence that, “our product backlog is our requirements”. No it’s not. Your product backlog is the Agile manifestation of your WBS. The requirements live elsewhere, but that’s another story for
another time.</div>
<div><br>
</div>
<div><br>
</div>
<div><i>“I'm not sure of the kind of questions that those involved might ask about such data. Suggestions welcome.”</i></div>
<div><br>
</div>
<div>To me, an extremely useful thing to look at would be “Rework Percentage” (R%). Add up total labor spent repairing defects (it’s a defect if it is a shortcoming found after the creator of that work claimed that that work was complete, e.g., going into a
review or inspection of some sort) and divide that by the total labor on that project. The limited but reliable data I have from 5 organizations of between 50 and 350 developers shows a weighted average of 61.2%. In other words, 61.2 out of every 100 labor
hours spent in those organizations goes to fixing defects discovered after the worker claimed their work was complete. This leads directly to the obnoxious but unavoidable conclusion that,</div>
<div><br>
</div>
<div>“<u>Rework is not only the single largest driver of cost and schedule on a typical software project; it is bigger than all other drivers combined!</u>”</div>
<div><br>
</div>
<div>Having said that, R% is highly manageable. I don’t have published, reference-able data but I do have experience on software projects that makes me highly confident R% can be well under 10%. I also have anecdotal data that suggests “Acceptance Test Driven
Development” can cut R% in half. R% is the net effect of what Martin Thomas is looking for in timing differences between defect injection and detection. The bigger the difference, the higher R%.</div>
<div><br>
</div>
<div>I saw in your paper that the CESAW data set does include rework data. So I think looking at R% both overall and on a project-by-project basis would be interesting and useful.</div>
<div><br>
</div>
<div><br>
</div>
<div>— steve</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>-----Original Message-----</div>
<div>From: systemsafety <<a href="mailto:systemsafety-bounces@lists.techfak.uni-bielefeld.de">systemsafety-bounces@lists.techfak.uni-bielefeld.de</a>> on behalf of Derek M Jones <<a href="mailto:derek@knosof.co.uk">derek@knosof.co.uk</a>></div>
<div>Organization: Knowledge Software, Ltd</div>
<div>Date: Tuesday, June 8, 2021 at 3:07 AM</div>
<div>To: "<a href="mailto:systemsafety@lists.techfak.uni-bielefeld.de">systemsafety@lists.techfak.uni-bielefeld.de</a>" <<a href="mailto:systemsafety@lists.techfak.uni-bielefeld.de">systemsafety@lists.techfak.uni-bielefeld.de</a>></div>
<div>Subject: [SystemSafety] Analysis of some Work Breakdown Structure projects</div>
<div><br>
</div>
<div>All,</div>
<div><br>
</div>
<div>Until recently data on the use of Agile in safety critical software</div>
<div>was almost non-existent.</div>
<div><br>
</div>
<div>I'm not sure if the use of work breakdown structure counts as</div>
<div>Agile, but here is an analysis of lots of data (project 615</div>
<div>was one of the safety critical projects):</div>
<div><a href="http://arxiv.org/abs/2106.03679">http://arxiv.org/abs/2106.03679</a></div>
<div><br>
</div>
<div>Never having used WBS, I'm not sure of the kind of questions</div>
<div>that those involved might ask about such data. Suggestions</div>
<div>welcome.</div>
<div><br>
</div>
<div>-- </div>
<div>Derek M. Jones Evidence-based software engineering</div>
<div>tel: +44 (0)1252 520667 blog:shape-of-code.coding-guidelines.com</div>
<div>_______________________________________________</div>
<div>The System Safety Mailing List</div>
<div><a href="mailto:systemsafety@TechFak.Uni-Bielefeld.DE">systemsafety@TechFak.Uni-Bielefeld.DE</a></div>
<div>Manage your subscription: <a href="https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety">
https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety</a></div>
<div><br>
</div>
</body>
</html>