> In the current BSIMM-V dataset is it possible to narrow the data down to only > organisations practising Agile dev? I think it would be interesting to see > which BSIMM activities are popular with agile houses, and which not.
One of the reasons not to do this is that publishing data that would be split into too many or too small pools would potentially allow someone to reverse-engineer the exact results of some of the participating companies. Aggregate data provides a level of anonymity. Moreover, I think this sort of split would be largely arbitrary. Especially for large companies, it's often not straightforward to classify them as agile or non-agile. Many companies also have mixed-mode dev shops with waterfall product management bolted on top of an agile dev team, or an agile dev team throwing code over the wall to a traditional ops team, or a mix of agile and non-agile teams working side by side. Now, some observed activities clearly are purely development activities, and some would not make any sense at all as dev team activities. How would you classify the results if the company had agile dev teams but waterfall product management? > Ideally, it would be nice to not only differentiate between Agile and > non-agile, but different degrees of agile based on the length of iterations > and/or the frequency of deployments. E.g. less-agile = 3 month iterations > and multi-month deploys, more-agile = continuous delivery with multiple > deploys per day. Even in purely agile shops, not everyone has a concept of an "iteration" (kanban is a continuous flow of tasks - which is often how maintenance of legacy software would be done), and "deploying" means different things for different industries (think embedded systems that have no update channel). In addition, I don't think you can measure agility through purely measuring cadence. The point of being agile is to be able to respond to change, and not all companies _need_ to be reinventing their product daily like a budding startup with an existential crisis. Although continuous integration would probably help the majority of companies, on the product management (i.e., backlog management) side, it depends on your customers and industry whether more is indeed better. - Antti _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates _______________________________________________
