Forskning på digitalisering 2026 uke 19

Leif Knutsen · email · 2026-05-04 source ↗ Reader 🖥️

Agile & XP DORA & Engineering Metrics Learning Culture & Slack Legacy & Organizational Forgetting Team Autonomy

Current software engineering research highlights a recurring tension: agile transformation, measurement, and AI-assisted code analysis all require structured, disciplined approaches that seem to contradict the flexibility they aim to enable — and these paradoxes are not yet resolved.

practical · curated research digest — A weekly newsletter summarizing and commenting on recent research in digitalization (EDOS — Forskningsnytt om digitalisering). Each item follows a consistent HVA / INTERESSANT / HVA SA structure (What / Interesting / So what). The author adds practitioner commentary atop each summarized paper. Three main items plus three bonus links.

Structure

Part	Role
1. Rammeverk for smidig transformasjon (Framework for agile transformation)	Presents an Italian study proposing an iterative roadmap for organization-wide agile transformation, then critiques the irony of structured frameworks for agility
2. Hvordan male programvareutvikling (How to measure software development)	Surveys measurement challenges in software engineering, arguing for pragmatic metrics tied to learning loops rather than control, invoking Deming's quality cycles
3. KI og store programvarelagre (AI and large code repositories)	Reports on using LLMs to analyze large repositories, introducing the PRIMES methodology for systematic prompt engineering
Bonus items	Brief pointers to three additional studies: frontline leadership (Australia), micro-foundations for net-zero (OECD), and Norwegian airport network effects on local growth

Key terms

smidig transformasjon Agile & XP
Organization-wide adoption of agile practices beyond the development team — requiring structural, cultural, and individual change across the entire organization
laeringssleyfer (learning loops) Learning Culture & Slack
Measurement cycles designed for understanding and improvement rather than control — tied explicitly to Deming's PDSA/observation cycles
PRIMES
A disciplined methodology for iteratively building, testing, and evaluating LLM prompts across models when analyzing large code repositories
bemyndigete team (empowered teams) Team Autonomy
Teams with genuine decision-making authority, listed as a key benefit of agile transformation

Propositions

explicitAgile transformation requires the entire organization to become agile, not just development teams
explicitStructural, perceptual, and individual barriers prevent organization-wide agile adoption
explicitcontestedThere is an irony in using structured, stage-gate frameworks to promote agility — but large organizations need structure, predictability, and accountability
contradicts ←New Skills to Navigate Continuous Change · p8 — Merchant claims change spreads best through organic team-to-team contagion rather than mandates; the research digest holds large organizations need structured, stage-gate transformation frameworks.
explicitSoftware engineering measurement tends to measure what is easy rather than what is useful
explicitAgile practices have made software measurement harder, not easier
explicitThere is a tendency to confuse learning with control; measuring convenient things creates an illusion of control
explicitSoftware development processes are not yet well enough understood for effective measurement, and LLM-generated code makes this harder
explicitPrompt design is the decisive factor when using LLMs to analyze large code repositories
explicitdevelopedLLMs can likely perform legacy code refactoring and redesign faster and better than humans, especially for code shaped by obsolete resource constraints
extends ←Case Study: Refactoring at Scale with Agents · p2 — Where that document asserts LLMs 'can likely' refactor legacy code faster/better than humans, this case study supplies a concrete, measured instance (300k LOC, 3 weeks, $4,000) with explicit qualification of failure modes.
extends ←When AI Writes the Code, Specifications Need an Exit Strategy · p10 — Agrees LLMs can refactor legacy code shaped by obsolete constraints, and adds an explicit judgment framework (preserve/verify/redesign/remove) for deciding which legacy behavior should actually survive the translation.
explicitThe cost of understanding existing software can feel equivalent to rewriting it, which is a barrier to reuse
implicitThe most valuable part of agile transformation frameworks may be ensuring feedback that demonstrates the benefits

Arguments

Organizations should measure for learning, not control strength: medium

LLMs are well-suited for legacy code analysis and refactoring strength: medium

Structured agile transformation frameworks are necessary despite their paradoxical nature strength: medium

Narratives

Questions addressed

⭕ How can organizations transform to become agile beyond their development teams?
An iterative roadmap is proposed but its effectiveness is not evidenced
⭕ What should we actually measure in software development, and how do we avoid the illusion of control?
Measure for learning via Deming-style cycles, but no concrete metrics specified
✅ How can LLMs be effectively used to analyze and work with large existing codebases?
Disciplined prompt engineering via the PRIMES methodology, with systematic testing across models
⭕ What are the practical barriers to software reuse?
Identified (cost of understanding equals cost of rewriting) but no solution offered beyond LLM assistance

Gaps

incompleteNo engagement with whether agile transformation frameworks actually work — the Italian study is summarized but its evidence base is not examined
incompleteThe claim that LLMs can redesign legacy code 'faster and better' than humans is asserted without evidence or qualification of failure modes
closed byCase Study: Refactoring at Scale with Agents — Supplies exactly the evidence and failure-mode qualification that gap asked for: a measured before/after Code Health transformation with cost and time figures, a model comparison showing weaker models plateau at local optima, and explicit acknowledgment that many refactoring attempts failed or degraded quality along the way.
incompleteThe measurement section invokes Deming but does not specify which concrete metrics would satisfy the learning-over-control criterion in modern agile contexts
incompleteNo discussion of how LLM-generated code interacts with the measurement problem — if LLMs generate code, what does 'developer productivity' even mean?
incompleteThe bonus items (frontline leadership, sustainability micro-foundations, airport effects) are too thinly described to extract any propositions