This document summarizes Leonardo Leite's thesis defense presented at the University of São Paulo, Brazil on organizational structures for development and infrastructure professionals in software organizations. The thesis presented a grounded theory on organizational structures developed through three phases of research involving interviews with software professionals. The research developed a taxonomy of four common organizational structures and analyzed why different structures are adopted, how their drawbacks are addressed, and implications for practitioners and scholars.

1. A grounded theory of organizational structures
for development and infrastructure professionals
in software-producing organizations
Thesis defense
Leonardo Leite
University of São Paulo (USP), Brazil
31/05/2022

2. 2
Advisors
Paulo Meirelles
Fabio Kon

3. 3
Agenda
● Context
● Phase 1
● Phase 2
● Phase 3
● Quality
● Implications

4. 4
Context
DevOps is a collaborative and multidisciplinary effort
within an organization to
automate continuous delivery of new software versions,
while guaranteeing their correctness and reliability.

5. 5
Context
DevOps is a collaborative and multidisciplinary effort
within an organization to
automate continuous delivery of new software versions,
while guaranteeing their correctness and reliability.

6. 6
Context
DevOps is a collaborative and multidisciplinary effort
within an organization to
automate continuous delivery of new software versions,
while guaranteeing their correctness and reliability.

7. 7
Context
DevOps is a collaborative and multidisciplinary effort
within an organization to
automate continuous delivery of new software versions,
while guaranteeing their correctness and reliability.

8. 8
Phase 1

9. 9

10. 10
Research problem –
DevOps adoption approaches

11. 11
Research problem –
DevOps adoption approaches

12. 12
Research problem –
DevOps adoption approaches

13. 13
Organizational structures
Groups of people, the responsibilities assigned to each group, and
the existing communication channels among these groups.
Aligned with:
Melvin E Conway. How do committees invent. Datamation, 14(4):28–31, 1968.

14. 14
Deploying DevOps in an organization
● Scarce literature
● Most sources → non academic
● Just listing structures
● No further explanation about the
structures

15. 15
Phase 2

16. 16
Research questions
● RQ1 - What are the organizational
structures adopted by software-producing
organizations to structure operations
activities between development and
infrastructure groups?

17. 17
Research questions
● RQ1 - What are the organizational
structures adopted by software-producing
organizations to structure operational
activities between development and
infrastructure groups?
Operational activities = application deployment,
infrastructure setup, and service operation in
run-time

18. 18
Research questions
● RQ1 - What are the organizational
structures?
● RQ1.1 - What are the properties of each of
these organizational structures?

19. 19
Research questions
● RQ1 - What are the organizational
structures?
● RQ1.1 - What are the properties of each of
these organizational structures?
● RQ1.2 - Are some organizational
structures more conducive to continuous
delivery than others?

20. 20
Taxonomy
● Classifications, collections of classes
grouping instances with shared properties
● Increases users' cognitive efficiency,
reasoning about classes instead of
individual instances
P. Ralph, Toward methodological guidelines for process theories
and taxonomies in software engineering, IEEE Transactions on
Software Engineering 45 (7) (2019)

21. 21
Methodology – Grounded Theory
B. Glaser, A. Strauss, The discovery of grounded theory:
strategies for qualitative research, Aldine Transaction, 1999 (1967).
● Constant comparative method
● Theoretical sensitivity
● Theoretical sampling
● (Open / Theoretical) coding
● Memos
● Theoretical saturation

22. 22
Methodology – Grounded Theory
B. Glaser, A. Strauss, The discovery of grounded theory:
strategies for qualitative research, Aldine Transaction, 1999 (1967).
● Focus on theory generation
● Not on hypotheses validation

23. 23
Phase 2 – 37 participants

24. 24
Producing the taxonomy with
Grounded Theory

25. 25
Producing the taxonomy with
Grounded Theory

26. 26
Producing the taxonomy with
Grounded Theory

27. 27
Saturation

28. 28
Our taxonomy

29. 29
Our taxonomy
Differentiation / Integration

30. 30
Our taxonomy
“The wall was very clear: after committing, our work [as developers] was done.” (I20)

31. 31
Our taxonomy
“Development and infrastructure teams participate in the same chat;
it even looks like everyone is part of the same team.” (I2)

32. 32
Our taxonomy
“It’s like each team is a different mini-company,
having the freedom to manage its own budget and infrastructure.” (I1)

33. 33
Our taxonomy
“You [dev] don’t need to worry about how things work, they just work.” (I33)

34. 34
Delivery performance questions
● Deployment frequency
● Time from commit to production
● Time to recovery
Nicole Forsgren et al., A taxonomy of software delivery performance profiles:
investigating the effects of DevOps practices. AMCIS 2020.

35. 35
Delivery performance classification
● High performers
vs.
● Non-high performers
Nicole Forsgren et al., A taxonomy of software delivery performance profiles:
investigating the effects of DevOps practices. AMCIS 2020.

36. 36
Delivery performance results
Evidence that platform teams
favor delivery performance

37. 37

38. 38
Phase 3

39. 39
Research questions
● RQ2 - Why do different software
organizations adopt different
organizational structures regarding
development and infrastructure
groups?

40. 40
Research questions
● RQ2 - Why different structures?
● RQ2.1 - How do organizations
handle the drawbacks of each
organizational structure?

41. 41
Phase 3 – 31 participants

42. 42
Phase 3 – 31 participants

43. 43
Phase 3 – 31 participants

44. 44
Theoretical coding
● Characterization
● Conditions
● Causes
● Avoidance reasons
● Consequences
● Contingencies

45. 45
Theoretical coding
● Characterization
● Conditions
● Causes
● Avoidance reasons
● Consequences
● Contingencies
RQ2
RQ2.1

46. 46
Resonance analysis
● 6C: employing the taxonomy
● Opportunities for refinements
● Coding: support vs confusion

47. 47
Resonance analysis
● 6C: employing the taxonomy
● Opportunities for refinements
● Coding: support vs confusion
“So I think our company fits the API-mediated dev & infra.” (I48)
“Thinking about the future, I still have a bias to continue
to the right [single department]” (I47)

48. 48
Resonance analysis
● 6C: employing the taxonomy
● Opportunities for refinements
● Coding: support vs confusion
“He asked my definition of "full-stack engineer" and then
concluded that this would apply to his case. However, he
warned about the polymorphism of this term.” (I38)
Action: full-stack engineers → with developers having infra background

49. 49
Analysis

50. 50
Saturation

51. 51
Refined taxonomy

52. 52
Refined taxonomy
“Here I work on the platform team.” (I50)

53. 53
Refined taxonomy

54. 54
Strong codes (46 in total)
Segregated Collaborating Single API-mediated
Conditions 0 2 1 4
Causes 0 3 3 6
Avoidance
reasons
0 0 2 0
Consequences 3 5 1 13
Contingencies 0 1 1 1
Strong code: appears in at least 3 interviews

55. 55
Examples of strong codes
● Condition for collaborating departments:
● proportion of infra people per development team
● Cause for API-mediated departments:
● pursuing to address delivery bottlenecks
● Avoidance reason for single departments:
● unsuitable for enforcing corporate standards
● Consequence of collaborating departments:
● possible conflicts due to blurred responsibilities
● Contingency in API-mediated departments:
● tuning the platform abstraction level to prevent developers
from over-relying on the platform as magical

56. 56
Examples of strong codes
● Condition for collaborating departments:
● proportion of infra people per development team
● Cause for API-mediated departments:
● pursuing to address delivery bottlenecks
● Avoidance reason for single departments:
● unsuitable for enforcing corporate standards
● Consequence of collaborating departments:
● possible conflicts due to blurred responsibilities
● Contingency in API-mediated departments:
● tuning the platform abstraction level to prevent developers
from over-relying on the platform as magical

57. 57
Quality
● Process adherence

58. 58
Grounded Theory
B. Glaser, A. Strauss, The discovery of grounded theory:
strategies for qualitative research, Aldine Transaction, 1999 (1967).
● Constant comparative method
● Theoretical sensitivity
● Theoretical sampling
● (Open / Theoretical) coding
● Memos
● Theoretical saturation

59. 59
Quality
● Process adherence
● Resonance analysis

60. 60
Quality treatments
Egon Guba, Criteria for assessing the trustworthiness of naturalistic inquiries. ECTJ 1981.

61. 61
Submitted to the IEEE TSE journal

62. 62
Implications for practitioners
● Guide to reflect (not necessarily for
acting)
● Increase awareness
● Support discussions and decisions

63. 63
Implications for scholars
● Guide to reflect (not necessarily for
acting)
● A deeper comprehension of the
software production phenomenon

64. 64
https://www.ime.usp.br/~leofl/devops/

65. 65
Extra slides

66. Theory
● “A system of ideas for explaining a phenomenon” [1]
● “A set of concepts that might be organized in list
form, or in a hierarchy, or in a network of
propositional statements” [2]
[1] P. Ralph, Toward methodological guidelines for process theories
and taxonomies in software engineering, IEEE Transactions on
Software Engineering 45 (7) (2019)
[2] B. Glaser, A. Strauss, The discovery of grounded theory:
strategies for qualitative research, Aldine Transaction, 1999.

67. Substantive theory
● Developed for a substantive, or
empirical, area of sociological
inquiry.
– Patient care, race relations,
professional education, delinquency,
research organizations
B. Glaser, A. Strauss, The discovery of grounded theory:
strategies for qualitative research, Aldine Transaction, 1999.

68. 68
Delivery performance results
Balance between specialization and coordination
Evidence that platform teams
favor delivery performance