Process, plan and organisation: how the work is divided and how it changes

The 2001 manifesto is a statement of preference, not an abolition. Its fourth value puts responding to change over following a plan. That value keeps the plan's worth and ranks it second (Beck and others, 2001). The twelve principles behind the manifesto ask for delivery every couple of weeks. The claim is about cadence, not about whether anyone plans.

The second unit turns from the time horizon to the organisation that does the work, and it defends the plan's thesis, sharpened into two claims that can be tested apart. Iterative and agile methods change who decides what, and when. They do not remove planning, and they say so in their own definitions. Nobody can read the outcome evidence as a controlled comparison of process, because the organisations and the respondents in it chose to be there. The change is a transfer of decision rights. Adopting a method is therefore a redistribution that the organisation has to permit, not a purchase that a manager makes on a team's behalf (Conway, 1968; Cataldo and others, 2006).

The claim: agile relocates the decision, it does not delete the plan

The normative documents state the architecture. Scrum is a lightweight framework founded on empiricism and lean thinking. Its formal events implement transparency, inspection and adaptation. The framework is purposefully incomplete, so its users build on it (Schwaber and Sutherland, 2020).

Scrum Teams are cross-functional ... They are also self-managing, meaning they internally decide who does what, when, and how. (Schwaber and Sutherland, 2020)

Read as a specification, that passage fixes where authority sits and how often someone exercises it. One accountable person orders the work. The team chooses the method. The Sprint sets the cadence. The plan survives as a backlog re-ordered continually, not as a document approved once. Extreme Programming made the same move from the practice side. It presents small releases, pair programming, continuous testing and an on-site customer as mutually supporting practices justified by experience (Beck, 1999).

Beck formed the practice bundle while he led the Chrysler Comprehensive Compensation payroll replacement, known as C3. The system went live in 1997, paying about ten thousand people, and new development stopped two years later (Fowler, 2004). The method arrived from a single setting, so the practices carry that setting's history rather than a comparison with an alternative.

The evidence base is thin, and its largest sample is self-selected

Dyba and Dingsoyr's systematic review measured how thin the base was. Searching to 2005, they identified 1996 studies, of which 36 were empirical. They called for more and better studies under a common research agenda (Dyba and Dingsoyr, 2008). The decade review that followed delineated the conceptual structure of agile scholarship. It closed by urging a theory-based approach (Dingsoyr and others, 2012).

Serrador and Pinto analysed 1002 projects across industries and countries. They found a positive association between the extent of agile use and success, both as efficiency and as stakeholder satisfaction. The perceived quality of the project vision was a marginally significant moderator (Serrador and Pinto, 2015). The data came from a questionnaire circulated through professional networks and LinkedIn groups, reaching practitioners who are online and reading English. The same study found no significant difference in upfront planning between agile and traditional projects.

Gemino, Horner Reich and Serrador studied 477 cross-industry projects. They found that 52 per cent were hybrid. Agile and hybrid both raised stakeholder success over traditional approaches, at the same budget, time, scope and quality (Gemino, Horner Reich and Serrador, 2021). The comparison describes a minority.

Organisation is the variable a process comparison leaves out

Conway's argument is a constraint. Organisations that design systems are constrained to produce designs that copy their communication structures. Organising a design team forecloses alternatives, because the necessary paths do not exist (Conway, 1968). Cataldo and colleagues computed coordination requirements from technical dependency data in a large project. The requirements were volatile, and they often crossed team boundaries. Where observed coordination matched them, development time shortened (Cataldo and others, 2006). Nagappan, Murphy and Basili found organisational metrics from Windows Vista. These included ownership and the number of teams touching a binary. The metrics were statistically significant predictors of failure-proneness. They out-performed churn, complexity, coverage, dependencies and pre-release bug measures (Nagappan, Murphy and Basili, 2008). Herbsleb and Grinter's distributed-project case study supplies the cost. Integration was the hardest part, and stable plans and processes helped only to a point (Herbsleb and Grinter, 1999).

The method as practised is reconstructed by the team

Hoda, Noble and Marshall used grounded theory with 58 practitioners in 23 organisations in New Zealand and India. They identified six roles that the methods never define: Mentor, Coordinator, Translator, Champion, Promoter and Terminator. Each role does work the methods assume, from initial guidance to removing members who threaten self-organisation (Hoda, Noble and Marshall, 2013). Jorgensen found expert judgement the most frequent strategy, and no substantial evidence in favour of formal models. He recorded twelve evidence-supported guidelines, including estimating top-down and bottom-up separately (Jorgensen, 2004).

Contested question: does the process or the organisation determine outcomes?

Two literatures disagree and rarely cite one another. The project-management side holds that process choice is associated with success (Serrador and Pinto, 2015; Gemino and others, 2021). The software-engineering side holds that structural variables determine outcomes, and that the method label sits downstream of them. Conway's constraint fixes organisation as the unit of analysis (Conway, 1968). Coordination requirements computed from technical dependencies predict development time (Cataldo and others, 2006). Organisational metrics out-predict code metrics for failure-proneness (Nagappan, Murphy and Basili, 2008). A third position refuses the framing. With a hybrid majority and a process made of undefined roles, no variable has two levels (Gemino, Horner Reich and Serrador, 2021; Hoda, Noble and Marshall, 2013).

The disagreement is partly about measurement, which sets recalled satisfaction against failure-proneness and development time drawn from records. It is partly about sampling, which sets volunteers against one organisation's history. Neither design separates adoption from selection. One design per project would settle it. That design would measure process fidelity against the method's own definition, coordination requirements against actual coordination, and objective outcomes such as post-release failures and integration effort. It would instrument adoption rather than let someone choose it. That is the agenda Dyba and Dingsoyr demanded in 2008. It is the theory-based approach that the decade review urged (Dyba and Dingsoyr, 2008; Dingsoyr and others, 2012). Nobody has run it at scale.

What to do while the dispute is open

The evidence on the two sides is unequal. Conway's constraint and the coordination measures come from records and from one large product, while the process side rests on self-selected questionnaires (Conway, 1968; Nagappan, Murphy and Basili, 2008; Serrador and Pinto, 2015). The strongest objection to this unit's thesis is that conditions, not methods, carry the effect. Russo and colleagues ran an exploratory study of 192 software engineers and a confirmatory study of 290 during enforced working from home. Time spent on specific activities was similar to pre-pandemic times. Activity-specific variables such as autonomy during coding predicted satisfaction and productivity, while activity-independent ones did not (Russo and others, 2023). Changing the arrangement did not change the distribution of working time, which cautions against the first claim. Autonomy inside the activity is a question of who decides, and it carried the effect, which supports the second.

One counter-argument remains. Serrador and Pinto's association holds across two outcome dimensions. Gemino and colleagues' regression accounts for a substantial share of variance. Across their multiple outcome measures, the range is 0.21 to 0.41 (Gemino and others, 2021). No study cited here instruments for adoption, so process may still move outcomes. While the dispute is open, a designer should name who decides what and when, and let the backlog show the decision, rather than buy a method whose effect cannot be separated from the team that chose it. On this evidence it has not been shown to.

Where the argument is heading

The named work points away from the method label, towards decisions, times and settings. A hybrid majority makes the two-way contrast untenable as a design (Gemino, Horner Reich and Serrador, 2021). The operative process consists of roles that the methods never specify (Hoda, Noble and Marshall, 2013). The predictors of satisfaction and productivity sit at the level of a single activity (Russo and others, 2023). Methods move decisions, and self-selected evidence does not yet show what moving them is worth.

The sources this unit rests on

Three publisher titles appear below in British spelling where the original uses an American form; nothing else has been changed.

• Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M. and others (2001). Manifesto for Agile Software Development. https://agilemanifesto.org/ The manifesto states four values and twelve principles, ranking individuals and interactions, working software, customer collaboration and response to change above their counterparts. It fixes what agile claims and is this unit's target.
• Beck, K. (1999). Extreme Programming Explained: Embrace Change. Reading, MA: Addison-Wesley. https://archive.org/details/extremeprogrammi00beck Beck presents Extreme Programming as a bundle of mutually supporting practices, among them continuous testing and an on-site customer. It documents the movement's argument, not its effects.
• Fowler, M. (2004). C3. https://martinfowler.com/bliki/C3.html A short note by a consultant on the Chrysler project whose reboot under Kent Beck pulled together the practices of Extreme Programming. It records that the system went live in 1997 paying about ten thousand people and that new development stopped in 1999.
• Schwaber, K. and Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum. https://scrumguides.org/scrum-guide.html The guide defines Scrum as a lightweight framework founded on empiricism and lean thinking, implements transparency, inspection and adaptation, and calls itself purposefully incomplete. Its team is self-managing and decides internally who does what, when, and how.
• Dyba, T. and Dingsoyr, T. (2008). Empirical Studies of Agile Software Development: A Systematic Review. Information and Software Technology 50(9-10), 833-859. doi:10.1016/j.infsof.2008.01.006 The review identified 1996 studies of agile development to 2005, of which 36 were empirical. It called for more and better studies under a common agenda, and measures the evidence against adoption.
• Dingsoyr, T., Nerur, S., Balijepally, V. and Moe, N. B. (2012). A Decade of Agile Methodologies: Towards Explaining Agile Software Development. Journal of Systems and Software 85(6), 1213-1221. doi:10.1016/j.jss.2012.02.033 The decade review analyses publications and citations in the ten years after the manifesto and urges researchers to embrace a theory-based approach. It shows a field mapping its literature rather than testing its claims.
• Serrador, P. and Pinto, J. K. (2015). Does Agile work? A quantitative analysis of agile project success. International Journal of Project Management 33(5), 1040-1051. doi:10.1016/j.ijproman.2015.01.006 A questionnaire study of 1002 projects found a positive association between the extent of agile use and success as efficiency and as stakeholder satisfaction. Respondents were recruited through the Project Management Institute and LinkedIn groups and described projects they had already judged, and the study found no significant difference in the amount of upfront planning between agile and traditional projects.
• Hoda, R., Noble, J. and Marshall, S. (2013). Self-Organising Roles on Agile Software Development Teams. IEEE Transactions on Software Engineering 39(3), 422-444. doi:10.1109/TSE.2012.30 Grounded theory with 58 practitioners in 23 organisations over four years identified six informal roles, Mentor, Coordinator, Translator, Champion, Promoter and Terminator, through which teams make themselves self-organising. None is method-defined.
• Conway, M. E. (1968). How Do Committees Invent? Datamation 14(5), 28-31. http://www.melconway.com/Home/Committees_Paper.html Conway argues that organisations designing systems are constrained to produce designs that copy their own communication structures, and that organising a design team forecloses alternatives for want of communication paths. It fixes organisation as the unit of analysis.
• Cataldo, M., Wagstrom, P. A., Herbsleb, J. D. and Carley, K. M. (2006). Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools. In Proceedings of the 2006 Conference on Computer Supported Cooperative Work (CSCW 2006). New York: ACM, 353-362. doi:10.1145/1180875.1180929 The authors computed coordination requirements from technical dependency data and compared them with observed coordination. Requirements were volatile and often crossed team boundaries, and where observed coordination matched them development time shortened.
• Nagappan, N., Murphy, B. and Basili, V. (2008). The Influence of Organisational Structure on Software Quality: An Empirical Case Study. In Proceedings of the 30th International Conference on Software Engineering (ICSE 2008). New York: ACM, 521-530. doi:10.1145/1368088.1368160 Organisational metrics built from Windows Vista data, including ownership and the number of teams touching a binary, were statistically significant predictors of failure-proneness, out-performing churn, complexity, coverage, dependencies and pre-release bug measures. It is product-level evidence that organisation predicts quality.
• Herbsleb, J. D. and Grinter, R. E. (1999). Splitting the Organisation and Integrating the Code: Conway's Law Revisited. In Proceedings of the 21st International Conference on Software Engineering (ICSE 1999). New York: ACM, 85-95. doi:10.1145/302405.302455 A case study of a geographically distributed product found integration the most difficult part, with coordination problems exaggerated across sites when informal channels broke down, and concluded that stable plans and processes help only to a point. It prices the organisational split that a process choice does not describe.
• Jorgensen, M. (2004). A review of studies on expert estimation of software development effort. Journal of Systems and Software 70(1-2), 37-60. doi:10.1016/S0164-1212(02)00156-5 The review found expert judgement to be the most frequently applied estimation strategy and no substantial evidence in favour of formal estimation models, and recorded twelve evidence-supported best-practice guidelines, including estimating top-down and bottom-up separately. Estimation is a judgement discipline, not an artefact the process produces.
• Gemino, A., Horner Reich, B. and Serrador, P. M. (2021). Agile, Traditional, and Hybrid Approaches to Project Success: Is Hybrid a Poor Second Choice? Project Management Journal 52(2), 161-175. doi:10.1177/8756972820973082 A study of 477 cross-industry projects found 52 per cent were hybrid, and that agile and hybrid approaches increased stakeholder success over traditional approaches at the same budget, time, scope and quality. It shows the two-way comparison describes a minority.
• Russo, D., Hanel, P. H. P., Altnickel, S. and van Berkel, N. (2023). Satisfaction and performance of software developers during enforced work from home in the COVID-19 period. Empirical Software Engineering 28(2), Article 50. doi:10.1007/s10664-023-10293-z An exploratory study of 192 software engineers and a confirmatory study of 290 during enforced working from home found working time close to pre-pandemic patterns, and autonomy during coding predicting satisfaction and productivity. Setting and decision rights, not the method, carried the effect.