The eight different organisations were selected opportunistically. As in the previous project, the individual members we interviewed are identified using the team letter and a number: ‘D1’. However, in this case not all of the organisations involved are companies, and in many cases the workshop participants came from several different teams. In this discussion, therefore, we refer to the set of participants in a single Developer Security Essentials intervention as a ‘group’. We use an identifying letter for each group, and the sequence of letters continues from the previous project, hence are D – K.
Several recruitment methods were used, as follows:
University: used the support of the Lancaster University ‘Academic Centre of Excellence in Cyber Security Research’ (ACE-CSR) team with its connections to government, and the Lancaster School of Computing and Communications Business Engagement Team and their contacts with companies near Lancaster.
Personal: used business contacts developed by the author in previous work in industry.
Conference: used leads from running the ‘Agile App Security Game’ (section 7.3.2) as a workshop at several UK developer conferences: AgileNorth, Agile Cambridge and Agile Manchester.
As in the previous project, a selection of the participants was interviewed, including the facilitator and usually a team leader, both before and after the interventions.
All of the developers interviewed were male, as were all managers and testers; only the three product managers were female.
From the previous project with teams A-C, it was known that the culture of the teams would have a definite impact on the nature of their interaction in workshops. Accordingly, we have added a categorisation of the organisation culture. This was a subjective estimate by the author based on the team’s behaviour during the workshops, using a taxonomy defined by Charles Handy [80] to describe the power of individuals’ roles and functions within an organisation. Table 18 summarises that taxonomy; it derives from the Provenmodels website [116].
8.2.1 Summary of Participating Groups
Table 19 summarises the groups, showing the organisation sizes (Small for less than 100, Large for greater than 5000); the culture of each team as discussed in the previous sections. It indicates the number of participants, the way in which the team was recruited.
It also shows ‘Security Maturity’, an estimate of their ‘secure software capability
Chapter 8: Further Trials (Magid 2)
maturity’ [90] by the author based on public information about the organisations and the groups’ discussions during the workshops, as follows:
Low: Little or no awareness or activity related to software security
Medium: Aware of and addressing security issues, typically including some developers with good security knowledge.
High: Experts at software security, within an organisational culture that assigns it a high priority.
For each intervention, the group designated one or two ‘facilitators’ (D1, E1, etc), and it was these facilitators who arranged and led the interventions. Since the skills and aptitudes of these facilitators were likely to be important, the table shows their roles and indicates, by the use of the plural, how many were involved.
The table shows how the different means of recruitment introduced groups with corresponding cultures. The author’s prior contacts with companies tended to be with the CEOs of Small to Medium Companies (SMEs); the workshops would only happen where such CEOs have influence over technical training for their teams; accordingly, we find the groups recruited tended to be Zeusian in nature. Similarly, the conferences which led to recruitment were in the ‘Agile Cambridge’, ‘Agile Manchester’ series: conferences targeted at senior technical development professionals, particularly ‘scrum masters’: a
Table 18: Organisation Cultures (after Provenmodels [116]) Zeus Power is concentrated in the hands of one individual, the top boss.
Control radiates from the centre’s use of personal contacts over procedures. The most powerful person dominates the decision making process.
Apollo A strong role culture places a premium on order and efficiency. Power is hierarchical and clearly defined in the company's job descriptions.
Decision making occurs at the top of the bureaucracy.
Athena Power is derived from the expertise required to complete a task or project. The work, itself, is the leading principle of coordination.
Decision making occurs through meritocracies. Employees move frequently from one project or group to another.
Dionysius Organisations exist for individuals to achieve their goals. Employees see themselves as independent professionals who have temporarily lent their services or skills to the organisation. Management is considered an unnecessary counterweight and given the lowest status. Decision
making occurs by consent of the professionals.
Table 19: Participating Developer Groups Org. size Culture Security
Maturity Size Facilitator(s) Recruited
D Large Athena Low 10 Managers University
E Large Apollo High 12 Security specialist University
F Small Zeus Low 3 Manager University
G Medium Zeus Med-High 10 Managers Personal
H Small Zeus Medium 8 Developer Personal
I Medium Athena Medium 14 Manager + Developer Conference J Large Apollo High 14 Security specialists Conference K Medium Athena Medium 16 Developers Conference
role involving the facilitation of software developers. We speculate that such professionals tend to favour Athenian cultures, since these give experts the most power in structured organisations (see Table 18); though Group J turned out to be marginally Apollonian rather than Athenian.
Figure 42 visualises some of the information from Table 19, adding the roles and numbers of interviewees for each workshop. Each group is represented by a ring, with an area proportional to the number of participants. The colours of segments in the ring indicate interviewee roles. The leaders and their roles are indicated by the squares (for a single leader) or rectangles (for two leaders) inside each ring; the colours show their normal roles. The locations of the rings indicate the size of the organisation involved (x axis) and the Security Maturity of the teams prior to the interventions (y axis).
Recall that we interviewed only a subset of the participants in each group. The colours of the ring segments represent the interviewee roles, not the overall participant roles. Since, however, we requested a representative sample of participants for the interviews, it is probable that the proportions of roles of the participants are similar to those shown here.
The visualisation shows the wide range of group sizes, organisation sizes and security maturity involved in the project. Unsurprisingly, only groups in large, security-adept companies had access to security professionals, and thus only groups E and J had these as facilitators. We had requested that product managers and testers join the groups; as Figure 42 shows, this happened only in the smaller companies, possibly because in small companies product managers and testers are closer to the development team, and more amenable to taking part in group activities. The smaller companies F and H didn’t have a
Figure 42: Composition of the Participating Groups Manager Developer
Product QA
Security
D E
F
G
J
H I K
Large
Small Company size
HighLowSecurity maturity
Chapter 8: Further Trials (Magid 2)
separate QA function; so, as shown, only the medium sized companies G and I had testers join the workshops32.