> 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
___