The Human Operating Model in the Age of AI in Software Delivery

Part 12 of the Software Development in the Age of AI series

Most discussions of AI and organisational structure begin from the assumption that the existing organisation is broadly effective. AI is then introduced as an external force that will flatten hierarchies, alter spans of control, redistribute decisions and create new combinations of human and machine labour.

That assumption deserves closer examination in software delivery.

Many contemporary IT organisations were already fragmented before generative AI arrived. Over several decades they accumulated specialist functions, outsourced capability, delivery frameworks, coordination roles, workflow platforms and recurring ceremonies. Much of this structure arose in response to genuine problems, including technical complexity, organisational scale, supplier dependence, weak visibility and slow delivery. The difficulty is that the accumulated model has rarely been examined as a whole. Organisations have added layers more readily than they have tested whether those layers improved end-to-end delivery.

AI changes the conditions under which this structure operates. Analysis, coding, testing, documentation and investigation can now be accelerated, particularly when experienced people work with capable agents. As execution becomes faster, delays caused by ambiguous requirements, repeated hand-offs, duplicated documentation and procedural supervision become more visible. AI is revealing weaknesses that were already present rather than creating the need for organisational change from nothing.

The same technology also places greater demands on the organisation. Reliable AI-assisted delivery depends on clear scope, authoritative context, explicit boundaries, defined permissions, strong assurance and named accountability. The future human operating model cannot be designed by taking the current organisation chart and removing whichever jobs appear automatable. It requires a more fundamental examination of how IT departments evolved, why their present structures exist and which parts continue to contribute useful work.

From the computer department to corporate IT

Corporate IT did not begin with product owners, delivery leads, Scrum Masters, Agile coaches, squads, tribes or release trains.

Early computer departments were shaped by the technology and by the work required to use it. Mainframe computing was centralised, expensive and comparatively scarce. Organisations therefore concentrated technical knowledge within internal departments containing systems analysts, analyst programmers, programmers, chief programmers, systems programmers, database specialists, computer operators and project managers.

The names varied, but the responsibilities were usually recognisable. Analysts worked with users to understand administrative and business processes. Analyst programmers carried much of that understanding into system design and implementation. Programmers developed and maintained applications. Chief programmers and other senior technical staff provided design direction, reviewed work and carried responsibility for the integrity of the system. Operations staff controlled production environments, scheduled workloads and dealt with failures. Project managers coordinated substantial programmes of change and were expected to understand the deliverables, dependencies, resources, costs and risks involved.

Architectural work certainly existed, although it was often embedded within experienced technical roles rather than separated into a distinct profession. Analysis, design and programming remained relatively close because the organisation contained fewer boundaries through which the work had to pass.

These departments were not idealised communities of technical excellence. They could be hierarchical, insular and slow to respond. Users sometimes waited months or years for changes. Documentation could be excessive, and technical specialists could exercise substantial power over business departments that had few alternatives. Projects still failed, exceeded budgets or delivered systems that did not meet their intended purpose.

Even so, the organisation was largely shaped around the actual work of computing. Its roles had developed around analysis, programming, operations and project delivery rather than around a methodology imposed across the department.

Professionalisation and formal methods

As computing spread through government and industry, organisations sought to make systems development and IT management more systematic.

Britain played an influential role in that professionalisation. The National Computing Centre was established by the UK government in the 1960s to encourage the effective use of computers, develop skills and promote professional practice. During the following decades, it provided training, publications and consultancy to public and private organisations, including local authorities. Its role was not to invent the software development lifecycle, but to help turn emerging systems-development knowledge into repeatable organisational practice.[1]

UK public institutions also helped codify methods that later travelled internationally. Structured systems analysis and design approaches influenced how requirements and systems were examined. PRINCE emerged from UK government practice as a method for controlled IT project delivery before PRINCE2 broadened its application.[2] ITIL was developed during the 1980s by the UK government’s Central Computer and Telecommunications Agency, which documented and distributed a body of recommended practices for IT service management.[3]

These methods addressed related but distinct concerns. Systems-development lifecycles described the progression through analysis, design, construction, testing, implementation and maintenance. Project-management methods dealt with scope, deliverables, phases, resources, milestones, risks, budgets, governance and accountability. Service-management practices dealt with the operation, support and continuing improvement of live IT services.

The distinction mattered because developing a system, delivering a project and operating a service were not the same activity.

A credible project plan was also more substantial than the Gantt chart with which it is now often associated. It was a written body of analysis and agreement covering purpose, scope, deliverables, assumptions, phases, activities, milestones, dependencies, resources, costs, risks, responsibilities, governance and completion criteria. Schedules, resource charts and critical-path diagrams represented aspects of that plan, usually as supporting material. They did not constitute the plan by themselves.

Formal methods could become rigid and bureaucratic, particularly when organisations treated documentation as an end in itself or attempted to fix every technical decision too early. Their underlying purpose was nevertheless rational. They made the intended undertaking explicit, established who was responsible and exposed whether the proposed sequence, resources and commitments were credible.

Technology decentralises

The move from mainframes to minicomputers began to change the shape of IT departments. Computing no longer had to remain entirely within one central facility. Business units and regional offices could operate departmental systems, gaining greater control over their own applications and priorities.

Personal computers accelerated that decentralisation. Users could perform work without sending every request through a central computing function. Departments acquired applications independently, and local spreadsheets and databases proliferated. Some of this was empowering because it placed useful capability directly in the hands of users. It also created duplication, inconsistent information and systems that central IT neither understood nor controlled.

Client-server computing introduced another structural shift. Applications were distributed across desktop clients, application servers, databases and networks. New technical specialties and teams developed around each layer. Database administrators, network engineers, server teams, desktop support, middleware specialists and application developers increasingly operated across separate organisational boundaries.

This specialisation created genuine expertise, but it also increased dependency. A change to one business service could require agreement among application, database, infrastructure, network, security and operations groups. More people became involved in delivery, while fewer retained an end-to-end understanding of the system.

The modern coordination problem therefore did not begin with Agile. It grew partly from the increasing distribution of technology and ownership. As systems crossed more technical and organisational boundaries, organisations added coordination to manage the resulting fragmentation.

Packaged software, suppliers and outsourced capability

Packaged business software altered the balance again.

Organisations increasingly purchased enterprise resource planning systems, customer platforms, banking products, insurance applications and other large commercial packages rather than developing every capability internally. IT work moved towards configuration, integration, data conversion, vendor management and local customisation.

Consultancies and suppliers gained influence because they understood the products and controlled much of the implementation expertise. Outsourcing and offshoring extended this development. External delivery could provide scale, specialist capability and access to labour markets unavailable internally, but it could also transfer system knowledge, technical authority and institutional memory outside the organisation.

Permanent employees increasingly managed contracts, suppliers, governance, reporting and escalation while consultants performed much of the analysis, design and implementation. When suppliers changed, practical knowledge often left with them. New providers then had to rediscover the systems, creating further demand for documentation, transition programmes and management oversight.

Organisations responded by adding coordination. They introduced more supplier governance, more delivery oversight, more status reporting and more intermediaries between the business and the people performing the technical work. This did not necessarily restore ownership. It often institutionalised its absence.

By the time Agile entered many large organisations, their delivery environments were already fragmented across technical disciplines, suppliers, commercial products and governance boundaries.

Agile as an engineering correction

Agile emerged against a genuine background of frustration.

Software practitioners had experienced projects burdened by excessive documentation, delayed feedback, rigid technical prescription and plans treated as immutable even after their assumptions had failed. The Manifesto for Agile Software Development, written in 2001 by seventeen software practitioners, described a search for better ways of developing software. Its values emphasised individuals and interactions, working software, customer collaboration and responsiveness to change, while explicitly recognising value in processes, documentation, contracts and plans.[4]

The manifesto was not an argument against planning, nor was it a general theory of corporate management. It did not propose a universal organisational structure.

Its important contribution was to restore the role of evidence and professional judgement in software development. Capable technical teams should work closely with customers, deliver working results earlier and adjust their approach when reality contradicted the assumptions on which a plan had been based.

This was compatible with serious project management. A project could retain a defined purpose, scope, deliverables, milestones, dependencies, resources, costs and risks while allowing the engineering team to decide how best to achieve them. Project leadership remained responsible for the wider undertaking and its commitments. Engineers remained responsible for the technical method.

That division of responsibility required trust. It assumed that experienced people closest to the work were best placed to organise their execution within the agreed outcome and constraints.

From engineering principle to enterprise identity

The word Agile gradually escaped this original scope.

Executives began describing entire businesses as Agile in much the same way that they described them as innovative, transformative or disruptive. These words became desirable corporate identities. They implied speed, modernity and responsiveness, although they often said little about how authority, incentives, architecture or delivery actually worked.

A company could adopt the language of agility while remaining hierarchical and slow. It could reorganise teams, rename departments and introduce ceremonies without altering the dependencies, funding structures or decision rights that constrained delivery.

The difference between agility as a capability and Agile as an enterprise framework became blurred. The first concerns the ability to respond intelligently to evidence and changing conditions. The second became an installable operating model containing prescribed roles, terminology, ceremonies, reporting structures, planning intervals, maturity assessments and transformation programmes.

This expansion created a professional Agile industry. Consultancies could sell transformations, training organisations could certify practitioners, software vendors could encode the framework into tools, and human-resources departments could establish new career structures around it.

There was no need for every participant to act cynically. The incentives were embedded in the model. A principle such as employing experienced people, giving them a clear outcome and allowing them to organise the work is difficult to package. A framework containing roles, courses, assessments, workshops, implementation roadmaps and supporting products is easier to sell and easier for executives to mandate.

As the framework became more elaborate, organisations needed more specialists to install, administer and interpret it. Each addition could be defended individually, while the cumulative structure received far less scrutiny.

From accountabilities to organisational machinery

Scrum originally described a small team with a limited set of accountabilities. The current Scrum Guide refers to Developers, the Product Owner and the Scrum Master as accountabilities within the Scrum Team rather than as an enterprise hierarchy.[5]

Corporate implementations eventually contained a much broader collection of titles, including iteration managers, delivery leads, Agile delivery managers, product managers, Agile coaches, chapter leads, tribe leads, release train engineers, value-stream managers, portfolio leads and transformation specialists.

Some people holding these titles perform essential work. A delivery manager who controls budgets, negotiates resources, manages suppliers, resolves external dependencies and remains answerable for milestones is performing substantive project management regardless of the title attached to the role.

The concern arises when positions exist mainly to administer teams that are described as self-managing. Frameworks introduced roles to control ceremonies, backlogs, estimates, planning intervals, workflow states, dependencies and reporting. The engineering team retained responsibility for the technical result while procedural authority increasingly sat with people surrounding it.

This created a contradiction. Teams were expected to be autonomous, yet their work was structured, estimated, scheduled and monitored through an external procedural apparatus. The organisation could describe this as self-management while supervising many of the decisions through which self-management would normally be exercised.

The proliferation of responsibility also weakened accountability. Product vision might belong to one person, delivery to another, process to another, architecture to another, testing to another, release to another and operations to yet another. Each role appeared accountable for part of the process, but responsibility for the complete outcome became increasingly difficult to locate.

More accountable titles did not necessarily produce greater accountability. In some organisations, they divided ownership so widely that nobody remained answerable for the undertaking as a whole.

Teams designed around the methodology

Enterprise frameworks also began influencing organisational design.

Instead of beginning with the business outcome, system boundaries, operational responsibility, technical risk and expertise required, many organisations started with a methodology template. They established squads, tribes and chapters, assigned product and delivery roles, introduced fixed sprint intervals, required recurring ceremonies and represented work through epics, stories, tasks, points and workflow states.

The structure often implied autonomy even where the technical and organisational conditions made autonomy impossible. A squad might still depend on central architecture, shared databases, infrastructure teams, security gates, funding committees, external suppliers and executive approvals for routine delivery.

Changing the name of the team did not remove those dependencies. It changed the language used to describe them.

The framework had therefore reversed the natural relationship between work and method. Teams should be organised around the outcome, systems and expertise involved, with methods selected according to the needs of the work. Instead, the work was increasingly adapted to fit a standard organisational and procedural template.

The bureaucratic pipeline

The resulting delivery model can appear highly efficient when viewed through dashboards and workflow reports.

A request enters through business representatives or product functions. Analysts translate it into epics and stories. Product owners prioritise the backlog. Delivery roles prepare and monitor the work. Engineering teams estimate and implement it. Testing functions validate it. Release teams promote it, and operations receives the result.

Every activity has an owner, every ticket has a status and every team has a board. The movement is visible, but visibility does not establish delivery effectiveness.

The requirement may be scattered across a workshop board, several Confluence pages, an epic, multiple stories, acceptance criteria, ticket comments and informal conversations. No single document may explain the complete deliverable, assumptions, dependencies, milestones, resources, costs and risks. The organisation can observe work moving through its process while remaining unable to describe the undertaking coherently.

Epics, stories, backlogs, sprints, Miro boards and Confluence pages can all be useful within their proper scope. The problem begins when they are expected to perform the work of requirements analysis, project planning, dependency management and governance.

A backlog can organise prospective work, but it does not by itself establish a delivery strategy. A sprint can help a team organise near-term execution, but it does not provide an end-to-end project schedule. A workshop can help people explore a problem, but it is not an agreed plan. A page is not authoritative simply because it has been published.

The pipeline can therefore maintain an impressive volume of activity while leaving the underlying intent fragmented.

When the sprint became the planning horizon

Sprints were intended as short periods within which a team could pursue a goal, produce an increment and learn from the result. In many organisations they gradually became the dominant planning horizon.

The next fortnight was described in considerable detail. The following year was represented by broad roadmaps, loosely defined epics and aspirational dates. This did not necessarily reflect adaptability. It often indicated that project-level planning had weakened.

A sequential list of requirements, a set of milestones, resource estimates, dependencies and a critical path do not make a project waterfall. They are basic disciplines needed for any substantial undertaking.

The sprint should sit beneath the project plan. The engineering team should examine the agreed requirements and milestones, assess what can reasonably be achieved during the next cycle and decide how to organise the technical work.

In many organisations, this relationship was reversed. The wider plan was expected to emerge from the accumulated content of successive sprints. That approach could provide regular activity without offering a credible account of how the complete outcome would be delivered.

Large-scale planning and coordination by crowd

Large planning events demonstrate the consequences of this inversion.

Hundreds of people may be assembled to align teams, identify dependencies and negotiate short-term commitments. These events can reveal conflicts and provide temporary synchronisation, particularly in complex organisations. Their existence does not, however, mean that they provide a substitute for project planning.

A credible project plan does not require every person who may eventually touch the work to be present in the same room. It requires people who understand the intended deliverable to establish phases, milestones, dependencies, sequencing, resources, assumptions, costs and risks through informed negotiation with the experienced professionals capable of assessing them.

Teams can then organise their own work against those targets.

Large planning ceremonies often attempt to construct the macro plan by aggregating team-level intentions. Dependencies become items on boards, and capacity is negotiated before technical analysis has fully established the work. Many participants spend substantial time listening to discussions unrelated to their contribution. The event may expose complexity, but exposure does not resolve the architecture, ownership or organisational boundaries that created it.

Independent studies of large-scale Agile development repeatedly identify cross-team coordination, technical dependencies, requirements, integration, testing and knowledge sharing as persistent challenges.[6][7][8] The available research does not demonstrate that adopting a scaling framework causes these problems to disappear. Instead, it documents the additional coordination practices introduced to manage them.

The UK National Audit Office reaches a related conclusion from a governance perspective. Its guidance on Agile in large-scale digital change warns that iterative methods do not remove the need for boards and senior leaders to understand intended outcomes, dependencies, funding, skills, assurance, risk and accountability. Agile can change how delivery work is organised, but it does not remove the obligations involved in governing a substantial undertaking.[9]

That evidence supports a more demanding question. Organisations should examine whether a framework solves the structural problem or mainly provides a disciplined way of administering it. If supposedly autonomous teams require repeated mass coordination, the architecture, ownership boundaries and distribution of decision rights deserve as much attention as the ceremony used to align them.

The human cost of procedural management

The accumulated operating model places a particular burden on experienced engineers.

Senior engineers often carry much of the practical technical risk because they understand the systems, data, architecture, dependencies, operational history and likely failure modes. They are the people most likely to recognise that a requirement is incomplete or that an apparently isolated change has broader consequences.

At the same time, they may spend substantial amounts of time servicing people who manage the representation of the work rather than its technical substance. They attend recurring ceremonies, translate technical activity into framework-compliant stories, defend estimates expressed through points, repeat the same explanations across several layers and respond to people who possess procedural authority without carrying responsibility for the technical result.

This can produce a form of professional infantilisation. Engineers are described as members of self-managing teams while other roles supervise their backlog, estimates, workflow, planning intervals and commitments. Their expertise becomes decisive when a system fails, but their autonomy is constrained during the work that leads to the outcome.

The resulting frustration is often characterised as resistance to process. That interpretation is too convenient. Experienced engineers are generally familiar with the need for requirements, planning, security, testing, review, operational controls and accountability. Their objection is more often directed at process that consumes expert attention without improving intent, reducing risk or strengthening evidence.

The relevant measure is therefore not whether a ceremony was performed or a status updated. It is whether the activity improved the outcome enough to justify the professional time it consumed.

Why the model persists

The modern framework satisfies several organisational interests.

Executives receive visible evidence that transformation is taking place. Managers receive dashboards and reporting structures. Consultancies receive substantial programmes of work. Training organisations receive certification markets. Tool vendors gain workflows that embed their products deeply within delivery. Newly established professional roles gain career paths and institutional legitimacy.

These interests do not prove that the framework lacks value. They do make objective examination more difficult.

Failure does not necessarily discredit the method. It can be attributed to incomplete adoption, insufficient organisational maturity, resistant culture, weak leadership or a lack of further coaching. Critics may be described as outdated or as people who do not understand Agile properly.

A methodology becomes difficult to evaluate when success confirms the framework while failure is attributed to the people or organisation implementing it.

A mature professional discipline should impose the same test on every role, ceremony, artefact and governance layer, whether traditional or Agile. What delivery problem does it solve? Is the problem reduced or merely reported more consistently? Could the same outcome be achieved through a simpler arrangement with clearer ownership?

The time and money consumed by the process should be justified by evidence of value. Engineers should not carry the burden of proving that every imposed practice is unnecessary.

AI reveals the original Agile proposition

AI changes this debate in an unexpected way.

The original Agile proposition placed considerable faith in small, capable, self-managing teams. Such teams were expected to organise themselves around the work, collaborate directly, respond to evidence and deliver without unnecessary procedural interference.

AI makes that model more achievable.

A small group of experienced people supported by capable agents can investigate repositories, analyse systems, propose implementation approaches, write code, generate tests, examine failures and prepare documentation with a level of capacity that previously required a much larger human team.

AI is not independently accountable and should not own consequential organisational decisions. It can, however, provide much of the analytical and execution capacity needed for a small human group to operate as a genuinely capable delivery unit.

This places enterprise Agile in an uncomfortable position. The technology may allow organisations to move closer to Agile’s original logic while making the administrative structure accumulated in Agile’s name increasingly difficult to justify.

A small expert team using agents may need less allocation, less translation and less procedural supervision. It will still need clear outcomes, appropriate project planning, strong analysis, technical authority, assurance, security and accountability. Those disciplines support the work directly rather than supervising the team’s internal organisation.

AI exposes rather than creates the dysfunction

Commentary about AI and organisational structure often presents the technology as the reason companies must reconsider hierarchy, management and team design. In software delivery, many of the relevant deficiencies were already present.

AI makes them more visible because it changes execution speed and concentration of capability.

A two-week cycle appears less natural when a bounded change can be analysed, implemented and tested within hours. Repeated refinement becomes harder to defend when its real purpose is compensating for an unresolved requirement. Chains of intermediaries look less necessary when experienced people and agents can work directly from agreed intent. Large status meetings provide less value when reliable evidence can be obtained from the delivery environment.

The bureaucracy existed before AI. Faster execution makes it easier to see where elapsed time is really being consumed.

This is why simply inserting AI into the existing pipeline is unlikely to produce the full benefit. Organisations may generate stories faster, summarise more meetings, populate more fields and create new roles to supervise agent activity. That would automate the administrative model without correcting its underlying weaknesses.

The more significant opportunity is to use AI as a reason to reassess the model itself.

AI forces organisational clarity

Reliable AI-assisted delivery places greater pressure on the quality of work before execution begins.

Human engineers can sometimes compensate for incomplete requirements through conversation, experience and institutional knowledge. An agent may instead produce a coherent implementation of one plausible interpretation. The result can be technically polished while remaining fundamentally wrong.

As execution accelerates, ambiguity becomes more consequential.

Analysts must therefore produce clearer requirements and identify contradictions rather than simply converting conversations into stories. Committees and decision-making bodies must resolve disagreements over scope instead of allowing competing interpretations to travel into delivery. Architects and engineers must define system boundaries, dependencies and constraints. Reviewers must assess whether the result satisfies the intended outcome and risk rather than merely confirming that the prescribed workflow was followed.

Reliable delivery requires an agreed objective, current and authoritative context, explicit constraints, known dependencies, defined permissions and measurable evidence of completion. These are demanding organisational disciplines, but they are substantially different from ceremonial compliance.

AI does not diminish the need for governance. It exposes where governance has been reduced to process observation rather than decision quality.

Control after ceremony

Criticism of the current model should not be confused with an argument for uncontrolled automation.

AI introduces significant new risks. Agents can modify large areas quickly, act on faulty assumptions, expose sensitive information, generate misleading assurance and produce changes whose consequences are not immediately visible. The future operating model therefore needs stronger controls around quality assurance, independent verification, identity, permissions, security, privacy, provenance, auditability, supplier risk and release authority.

These controls should be connected to the work and proportionate to its consequences.

A story point does not provide assurance. Attendance at a stand-up does not establish governance. A ticket moving to a completed state does not demonstrate that the intended outcome was achieved.

More meaningful control comes from agreed scope, trusted requirements, bounded authority, independent evidence and named human responsibility. The purpose is not to remove discipline, but to direct it towards the aspects of delivery that influence quality, safety and accountability.

A new human operating model

A replacement for the current structure cannot consist only of removing roles and ceremonies. It must describe how software delivery should be organised when experienced people and agents can perform more work with fewer hand-offs.

Organise around outcomes and systems

Teams should be aligned with coherent business outcomes, products, services or system boundaries. Their design should reflect the expertise required, the operational responsibilities involved, the dependencies that cannot be removed and the risks associated with the work.

A team should not be described as autonomous if it lacks authority over its system or remains dependent on several unrelated functions for routine delivery. Where dependencies are unavoidable, they should be acknowledged explicitly rather than concealed behind team labels.

Restore project-level planning

Substantial undertakings still require an authoritative project plan. It should describe the purpose, scope, deliverables, phases, milestones, assumptions, dependencies, resources, budget, risks, governance arrangements and evidence of completion. Current UK government project-delivery guidance similarly retains the need for defined outcomes, planning, assurance, resources, governance and control across projects and programmes.[10]

The plan should evolve when evidence changes the project’s assumptions. Its existence does not impose a rigid technical method on the engineering team. It provides the wider context and commitments against which the team organises its work.

A backlog can support execution, but it should not replace this level of planning.

Separate requirements from technical work definition

Business and project analysis should establish what the organisation intends to achieve, including the relevant rules, constraints, dependencies and evidence of success.

The engineering team should determine how those requirements are decomposed into technical work. It may use stories, tasks, specifications or another internal method according to the nature of the system and the work involved.

AI can assist engineers by analysing systems, identifying possible dependencies and proposing implementation plans. The engineering team remains responsible for deciding whether those proposals are technically and operationally sound.

Use small expert delivery units

AI increases the capability of small teams, but it does not remove the need for expertise.

An effective delivery unit requires access to business knowledge, analysis, engineering, operational understanding, assurance and security. These are responsibilities rather than a mandatory set of permanent titles. A small team may combine several of them, while a large regulated programme may require dedicated specialists.

The structure should follow the work rather than reproduce every role created by a framework.

Give agents bounded authority

Agents should operate through controlled identities, permissions, tools and environments. The organisation must define what each agent may inspect, propose, modify, test, deploy or approve.

Authority should reflect the sensitivity and consequences of the work. An agent may be allowed to prepare a low-risk code change and run automated tests while remaining unable to access production data or execute a production deployment.

These boundaries should be built into the delivery environment rather than relying on informal instructions.

Maintain continuous evidence

Requirements, design decisions, implementation changes, tests, reviews, security checks, approvals, deployments and production outcomes should remain connected.

Evidence should accumulate throughout delivery, allowing reviewers to trace the relationship between the original intent and the result. This becomes particularly important when several agents and tools contribute to the same change.

Apply human attention according to risk

Human intervention should be concentrated where ambiguity, novelty, consequence or irreversibility requires judgement.

Routine and reversible changes may proceed with limited intervention where automated evidence is strong. Changes affecting payments, safety, privacy, regulatory reporting or critical infrastructure require deeper and more independent review.

The purpose of human involvement is to protect the outcome, not to preserve an inherited approval ceremony.

Restore clear accountability

Each significant outcome needs named human ownership.

Different people may be responsible for the requirement, technical decision, assurance decision and release authority, particularly in large or regulated environments. Those responsibilities should be explicit and connected. The participation of several specialists and agents should not allow accountability to dissolve across the process.

Human work that becomes more valuable

AI increases the value of people who can understand business outcomes, resolve ambiguity, negotiate scope, reason about systems, identify dependencies, make technical judgements, assess risk, evaluate evidence and accept responsibility.

Analysts should spend more time performing analysis and less time populating backlogs. Project leaders should manage deliverables, milestones, dependencies, resources, budgets and risks rather than supervise the engineering team’s internal task sequence. Engineers should retain control of technical decomposition. Security, assurance and governance specialists should help define controls throughout delivery rather than operate only as final gates. Operational expertise should ensure that production evidence influences future requirements, tests and decisions.

The common feature of these responsibilities is judgement. AI can assist with the work, expose relevant information and accelerate execution, but the organisation still needs people capable of determining what the evidence means and which consequences are acceptable.

Work that deserves reassessment

Activities designed mainly to allocate, supervise and report slow human execution should no longer carry a presumption of necessity.

Mandatory story templates, arbitrary points, velocity targets, repeated status ceremonies, mass planning events, duplicated documentation, externally imposed sprint boundaries and technical decomposition by non-technical intermediaries should be retained only where they solve a demonstrated problem.

The same applies to roles whose principal function is moving information between other roles or maintaining the workflow through which work is represented. Some organisations may find genuine value in particular practices, especially where teams are inexperienced, dependencies are substantial or coordination is unavoidable. The appropriate test is contribution to the outcome rather than conformity to a methodology.

This is not a demand for universal abolition. It is a demand for objective assessment.

The leadership challenge

Executives should resist treating AI as the next corporate identity.

Declaring an organisation AI-first will not create the clarity, expertise or accountability required for reliable delivery. Buying agent platforms and appointing new coordinators may simply add another layer to the existing structure.

Leadership must be prepared to examine why current roles and ceremonies exist, which responsibilities have become fragmented and whether the organisation retains enough internal technical knowledge to judge the work it commissions.

The relevant questions are practical. What is being delivered? Who understands the system? Where is the authoritative requirement? Which dependencies constrain the outcome? What resources are needed? Who can make the technical decision? What evidence demonstrates that the result is correct? Who remains accountable when it is not?

An organisation able to answer those questions is better prepared for AI than one with an elaborate transformation programme but weak ownership of its systems and outcomes.

Conclusion

The human operating model for software delivery has evolved through several technological and organisational eras.

Centralised computer departments concentrated technical knowledge and authority. Formal methods professionalised systems development, project delivery and service management. Minicomputers, personal computers and client-server systems distributed computing and created new specialisations. Packaged software, outsourcing and consultancy dependence fragmented ownership and moved practical knowledge beyond organisational boundaries.

Agile emerged as a legitimate engineering correction to rigid processes, delayed feedback and excessive distance between technical decisions and the people doing the work. Its original logic placed trust in small, capable teams that could organise themselves around a clear outcome.

Enterprise Agile expanded far beyond that purpose. Frameworks began shaping organisational structures, roles multiplied around supposedly self-managing teams, and procedural authority became separated from technical responsibility. Epics, stories, sprints, boards and ceremonies were increasingly used to provide the appearance of planning and control, even where end-to-end ownership remained weak.

AI now makes the consequences of that evolution harder to ignore. It increases the capacity of small groups of experienced people, reduces the need for some of the machinery created to allocate and monitor human execution, and exposes where delay is caused by ambiguity, hand-offs and procedural supervision.

At the same time, AI demands greater precision. Scope must be agreed, requirements must be clearer, context must be authoritative, boundaries must be explicit and evidence must be stronger. Quality assurance, security, governance and accountability become more important because incorrect work can be produced and propagated much faster.

The emerging human operating model should therefore be organised around outcomes and coherent systems, supported by credible project planning, strong analysis, engineering-led decomposition, bounded agent authority, continuous evidence and risk-based human intervention. It should retain roles and practices that contribute materially to delivery while removing the presumption that every element of the existing framework is necessary.

AI is not requiring a previously effective IT organisation to abandon a successful model. It is revealing that much of the current model was already poorly aligned with the work and sustained partly by the conditions of slow, distributed human execution.

The opportunity is to move closer to the original Agile proposition: small groups of capable people trusted to organise around a clear outcome, now supported by machines that multiply their analytical and execution capacity. Realising that opportunity will require organisations to simplify the structures surrounding engineering while strengthening the disciplines that protect the outcome.

Whether they do so will depend less on the capability of the agents than on the willingness of leaders to distinguish useful control from inherited ceremony.

References

[1] UK Parliament (1965), ‘National Computing Centre’, House of Commons debate, 7 December.

https://hansard.parliament.uk/commons/1965-12-07/debates/f3efe022-11bd-4f42-814a-2c8ad8312b32/NationalComputingCentre

[2] PRINCE2 (n.d.), ‘Management Overview: PRINCE2’.

https://www.prince2.org.uk/management-overview/

[3] IBM (n.d.), ‘What Is IT Infrastructure Library (ITIL)?’

https://www.ibm.com/think/topics/it-infrastructure-library

[4] Beck, K. et al. (2001), ‘Manifesto for Agile Software Development’.

https://agilemanifesto.org/

[5] Schwaber, K. and Sutherland, J. (2020), ‘The Scrum Guide’.

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf

[6] Uludağ, Ö. et al. (2022), ‘Revealing the State of the Art of Large-Scale Agile Development Research: A Systematic Mapping Study’, Information and Software Technology.

https://arxiv.org/abs/2007.05578

[7] Biesialska, K. et al. (2021), ‘Mining Dependencies in Large-Scale Agile Software Development’.

https://www.essi.upc.edu/~biesialska/Biesialska_2021-Mining_Dependencies_in_Large-Scale_ASD.pdf

[8] Dingsøyr, T., Moe, N.B. and Seim, E.A. (2018), ‘Coordinating Knowledge Work in Multi-Team Programs: Findings from a Large-Scale Agile Development Program’.

https://arxiv.org/abs/1801.08764

[9] National Audit Office (2022), ‘Use of Agile in Large-Scale Digital Change Programmes’.

https://www.nao.org.uk/insights/use-of-agile-in-large-scale-digital-change-programmes/

[10] UK Government (2025), ‘Government Functional Standard GovS 002: Project Delivery’.

https://www.gov.uk/government/publications/project-delivery-functional-standard