Hepta Management System – The Operating System for Your IT Organization

From a self-stopping loom around 1900 to a certification industry worth billions: the history of lean and agile management is the history of one and the same confusion, repeated over and over. Toyota spent three decades refining a system of mindset, leadership and problem-solving culture – the West copied the Kanban cards and wondered why the results never came. The same pattern repeats with Scrum, which seventeen developers sketched on a postcard at a Utah ski resort in 2001 and out of which, within twenty years, grew a process industry estimated at 49 billion dollars, and with OKR, which drifted through Silicon Valley as a rumour for almost two decades before rule inflation hardened it into dogma. Anyone who knows this origin can tell the pragmatic recommendation from the "best practice" elevated to religion without effort. The chapter shows why no framework works "out of the box", and why it pays to understand the purpose of a method before copying its practice.

A child playing at driving turns the wheel, sounds the horn and hits the accelerator – and takes exactly that for driving. Organisations often do the same: they copy the visible form of successful role models – the meeting format, the planning tool, the org chart – without understanding the purpose those tools are actually meant to serve. Feynman's cargo cult with its bamboo runways, the Dunning-Kruger effect and the project plan as a "lie in bar-chart form" all teach the same lesson: the form can be perfect while the purpose is entirely missing – and anyone who has never experienced the yardstick does not even notice the difference. The pattern repeats in its purest form with AI, when bought-in toolbars simulate an "AI-driven" way of working where no value lands. The chapter sharpens the eye for the distinction that decides the success or failure of every method rollout: not whether the practice looks tidy, but whether it carries the purpose it was meant for.

An operating system does no work of its own – it makes everyone else's work possible by abstracting away complexity and offering a uniform interface. That is exactly what HeptaMS does for IT organisations: it replaces neither Scrum nor ITIL nor DevOps, but sits as a layer above them and names seven senses – Direction, Leadership, Flow, Cadence, Stability, Collaboration, Reach – from which an organisation should perceive its work. Each sense comes with the one question that matters, and the art lies in turning attention to wherever the organisation is currently not looking: stare only at agile delivery and you deliver fast until production goes down; tend only to stability and you reliably run software no one needs any more. Because no sense is more important than another and none works in isolation, HeptaMS becomes a repertoire rather than a checklist – frameworks turn interchangeable without any loss of bearings, and AI shifts the questions of collaboration and reach once again in fundamental ways. This chapter shows how to order frameworks under seven perspectives and six life-cycle phases so that the right tool is found for the situation at hand, instead of chasing every passing fashion.

In agile organisations, values are treated as non-negotiable goods – and that is exactly what turns them into the sharpest weapon in the toolkit: "Courage" ends any uncomfortable discussion, "Transparency" justifies inappropriate disclosure, "Commitment" forces through unrealistic promises. This chapter shows why imposed values are not values at all but disguised rules, ones you can no longer argue against without looking like a saboteur. It sets four fundamentally different value systems side by side – Scrum, SAFe, the Toyota Way and New Zealand's centuries-old Kaupapa Māori – and reveals that the most interesting answers do not come from the agile world. A central finding lays a myth to rest: the Toyota Production System was not a flowering of Japanese harmony but a deliberate counter-strategy against it – which is why agile rollouts copy the tools yet lose the philosophy that carries them. The chapter shows how organisations can pragmatically negotiate their own values instead of pinning someone else's list to the wall.

Three years after ChatGPT, AI in software development is no longer a forecast but a measurable reality – and the data contradict both popular narratives: neither the productivity miracle nor the soon-forgotten hype survives scrutiny. At a quarter of the most recent Y Combinator startups, 95 percent of the code comes from language models, while the first randomised study shows experienced developers who feel 20 percent faster and are in fact 19 percent slower – a self-perception gap that no better model closes. At the same time the code grows faster and gets worse on average: more duplication, less refactoring, more vulnerabilities, and the bottleneck moves from writing to checking. The talent pyramid is tipping measurably, junior employment is collapsing, and the reflex to respond with prompt training and tool licences addresses the visible action rather than the real lever. That lever lies not in the tool but in the way of working – in requirement clarity, architectural ownership, and review discipline. The chapter shows why the question is not whether an organisation uses AI, but whether it has the way of working in which these tools become productive.

Objectives and Key Results are placed as an instrument for change, not as a universal steering system: an Objective sets the direction qualitatively, Key Results describe measurable outcomes rather than tasks, and the cycle runs quarterly. The real benefit is not the goal system itself but the forced clarity about what truly has priority and what is deliberately dropped. Several elements of Google's practice are examined critically – cascading down to the individual level, publicly visible personal OKRs, and the seventy-percent rule – because they rest on conditions other organisations do not bring with them; for areas with stable requirements such as production, compliance or accounting, KPIs are described as the better fit. An overview sets Management by Objectives, the Balanced Scorecard, Hoshin Kanri, 4DX, V2MOM and OGSM alongside it and matches each to a particular need. Recurring rollout mistakes are named: too many Objectives, Key Results as a task list, coupling to pay, missing leadership involvement, and absent check-ins. As its boundaries, the chapter holds that OKR neither solves culture problems nor replaces strategy, and does not carry without active leadership.

Knowledge work cannot be ordered: what a developer, an architect or an analyst really contributes happens in the head and escapes classic command-and-control leadership — yet the counter-thesis of simply letting teams get on with it works no better. This chapter lays out the full spectrum of modern leadership: from McGregor's sixty-year-old and still sharpest diagnostic tool, Theory X/Y, through Situational Leadership and Appelo's seven levels of delegation, to servant leadership, Daniel Pink's motivation research and Kim Scott's Radical Candor. It shows why psychological safety is the factor without which nothing else holds — and why decentralised decisions, in the age of AI, are no longer a question of maturity but a precondition for staying able to decide at all. Rather than selling frameworks, the author places them in context, names their shared blind spot, and separates tools you merely know from tools you actually live. The chapter delivers both the models and the practical instruments — the delegation board, moving motivators, the test question for psychological safety — alongside the uncomfortable truth that all of them are easy to explain and hard to live by.

Ten developers in a room are not yet a team but ten individuals who happen to work on the same code. What turns a group into a high-performing team comes not from an org chart or a kick-off, but from deliberate decisions about size, composition, functional cut and the mix of experience – and from the time a team is allowed to stay together. The strongest and most often ignored lever is stability: teams grow more productive over years, while reshuffling after every project systematically destroys exactly that gain. Between the rule of five to nine, cross-functional feature teams, the four team types from Team Topologies and the surprising Google finding that the way a team collaborates beats its composition, a pragmatic picture emerges beyond the framework folklore. The topic gains particular urgency from AI: coding agents take over precisely the entry-level tasks on which juniors used to learn the craft – redesign the junior role deliberately, or save on positions now and discover in five years that the seniors who should have moved up are missing. This chapter shows which decisions make a team genuinely viable, and how to tell whether you have a team problem, a structural one, or in truth a strategy problem.

A product owner, a scrum master, a system architect: behind the confusing variety of roles in the agile frameworks lie only three functions that every software team has to fulfil at the same time. The Hepta Management System calls them Value, Flow and Architecture, exposing what Scrum, SAFe and Disciplined Agile each name differently and, in some cases, never staff at all. Their real value lies in the productive tension between them: Value wants to deliver, Architecture wants to protect, Flow wants to optimise, and only the counterweight makes a team sound. Anyone who leaves an axis unstaffed, or hands Value and Architecture to the same person, builds in a structural risk that reliably tips over under time pressure. The chapter shows how to distribute the three responsibilities cleanly in small and large organisations alike, why architecture responsibility is no longer optional in the age of AI, and how the often-diagnosed but rarely-named management vacuum can be traced precisely to a single unstaffed function.

Meetings are the most expensive habit in knowledge work – and the only one whose bill nobody adds up. Ten developers, two wasted meeting hours a day: that is two and a half unfilled full-time positions and 300,000 euros poured into nothing, while Bain puts the cost of unproductive meetings in US firms alone at more than 37 billion dollars a year. Yet the visible costs are only half the story, because after a badly run meeting the brain needs up to 45 minutes to become productive again. This chapter moves from the worked example through Meeting Recovery Syndrome and the research on meeting-free days to three norms of a healthy meeting culture, ritualised agile events, and the principle of "asynchronous by default, synchronous by exception". It argues not against meetings but against the thoughtlessness with which they are called – and shows why the time problem can only be solved through the structural problem behind it.

Lean Thinking is not another method alongside Scrum, OKR or ITIL but the attitude that decides whether those tools create value or merely produce activity. At its heart is a change of perspective: what counts is not how busy people are but how value flows through the organisation — you watch the baton, not the runners. Queueing theory shows why a team planned to 100 percent is not maximally productive but maximally blocked, and why spare capacity remains the precondition for flow. Through the five Lean principles, the three sources of waste — Muda, Mura and Muri — and the diagnostic tool of value stream mapping, it becomes visible how much lead time in IT organisations is pure waiting, often almost nine parts in ten. The chapter shows why Lean is the kernel running through all seven senses, and why the sense of Flow does not ask about Kanban boards but about whether you have the courage to remove the causes of the waiting.

When coding agents take over the routine share of software development, a developer's most valuable skill shifts from writing code to evaluating it – and the familiar logic of team building tips over with it. The entry market for juniors is collapsing while review becomes the new bottleneck: pull-request volume rises by 98 percent, the least experienced group is the most willing to skip the check, and the reliability tax consumes up to half of all developer capacity. This chapter shows why short-term efficiency – fewer juniors, more AI – creates a hollowed-out career ladder that returns in five years as a shortage of seniors, and how junior roles can be rebuilt into junior architects instead of being cut. It makes visible why the choice of technology stack shapes AI quality more than any prompt, why architecture responsibility belongs in the team rather than in a review board two levels above, and why burnout prevention in the age of AI is a structural question, not an HR one. Backed by data from Stanford, GitHub, Faros AI, CodeRabbit, Qodo and Sonar, plus a five-week field experiment in which an agent stubbornly built a monolith despite every instruction. The chapter delivers a concrete new team model and the lean answer of heijunka for a load that can no longer be solved at the individual level.

The sprints run, the dailies happen, the boards are colourful — and still the lead time from feature request to deployment does not budge. This pattern emerges whenever organisations copy the visible form of agile methods without grasping the principles that make them work. Tracing the arc from Royce's overlooked 1970 waterfall warning through the Agile Manifesto in Snowbird to today's industry of frameworks and certifications, the text distils why agile approaches succeed down to three load-bearing principles: manageable scope, localized decision making, and interaction. Scrum, Kanban and Scrumban then appear not as competing belief systems but as a spectrum from structured to flowing, from which the right method follows from two sober questions: how predictable is the work, and how experienced is the team with self-organisation? With equal candour it names the limits — regulated environments, fixed-price projects, immature organisations — and holds that agility is a means, not an end. The chapter shows that whoever masters the principles can use or adapt any framework, while whoever only copies the framework will be shopping for the next one in two years.

Scrum is the best-known agile framework, and for that very reason the one most often misunderstood. It did not originate in software development but in product development at Honda, Canon and Fuji-Xerox, where teams working in overlapping phases set the example. At its core lies not a collection of rituals but empirical process control: look regularly and then act, because complex work cannot be planned through to the end. Three accountabilities, five events and three artefacts together form a separation of powers that keeps product, process and delivery from being dominated by a single person. Anyone who understands the mechanisms behind the sprint, the Sprint Goal and the Definition of Done can adapt the framework to their own organisation; anyone who merely copies the form misses the point. The chapter shows when Scrum holds, where its limits lie, and why the team level has to work before scaling can succeed.

Kanban comes from Toyota's 1950s production line and was adapted by David Anderson for knowledge work — an evolutionary steering system that needs no new roles, events or reorganisation. It makes existing work visible on a board, limits the amount of concurrent work through WIP limits, and manages flow through a few core metrics. Its strongest lever is also its least intuitive: less concurrent work lowers lead time, often without anyone working faster, and Little's Law supplies the mathematical reason. From the six core practices through the three core metrics with the cumulative flow diagram to the four classes of service, a precise picture emerges of when Kanban is the better choice than Scrum. The text is just as honest about the limits: missing structure as a trap for inexperienced teams, WIP limits that demand discipline, and the fact that Kanban steers the flow, not the direction. The chapter shows how a simple card system becomes an instrument that makes throughput visible and improves it — as long as the data is maintained and the limits are respected.

Many dismiss Scrumban as a makeshift compromise – in fact it is the most pragmatic way to steer agile teams through the everyday reality where planned features and unplanned tickets compete for the same board. The hybrid combines the cadence of Scrum – the sprint as a rhythm for review, retrospective and planning – with the flow mechanics of Kanban: WIP limits, the pull principle and flow metrics instead of velocity. This lets a team take in unpredictable work without breaking the sprint commitment, while on-demand planning and bucket size planning keep the view open from next week to the yearly horizon. The crucial point is that Scrumban is no licence to dismantle structure but a deliberate trade: drop the uncomfortable Scrum elements without introducing WIP limits and metrics, and you end up with Scrum without discipline. The chapter shows where Scrumban comes from, the five core elements it consists of, the transition path along which teams grow into it, and how to tell reliably when the hybrid carries and when a team is better off staying with Scrum or Kanban.

Few topics divide agile teams as reliably as estimation: Story Points versus hours, Planning Poker versus #NoEstimates, Fibonacci versus T-shirt sizes. This chapter turns the debate around and shows that the method is rarely the problem – what matters is whether you estimate to fill sprints, to order priorities economically, or to justify budgets, because each purpose calls for a different answer. It explores the rarely named psychology behind the numbers, from somatic markers through the planning fallacy and anchoring to the stubborn myth that the first thought is always the right one. From the Fibonacci sequence and its limits beyond 13 points, through WSJF and the cost of delay, to velocity as a compass and Monte Carlo simulations as an honest forecast, it places every method against the criterion that truly counts: does it help the team learn from its own data? The rupture that AI-assisted development drives into effort-based estimation is weighed up soberly too. The chapter shows that good estimation is not a question of card values but of the ability to communicate uncertainty honestly – with it, not in spite of it.

When a product outgrows a single team, organisations reach reflexively for a scaling framework — SAFe, LeSS, Nexus or Scrum@Scale. Yet the most effective scaling is the kind you avoid: eliminate dependencies through the right team split and a clean architecture, and there is nothing left to coordinate. This piece walks through the four major scaling frameworks, setting their roles, cadences and philosophies side by side, and shows why Conway's Law turns every scaling decision into an architecture decision at the same time. It explains why the copied Spotify model so often decays into cargo cult, and why research traces the failure of large transformations almost never to technology but to culture and leadership. Team count, organisational maturity and overhead tolerance become a sober decision logic rather than a matter of conviction. The chapter shows that the most important choice is usually made before the framework is picked — and how to tell which framework fits, or whether none is needed at all.

Most large IT projects fail not because of poor project management but because of a systemic error: organisations start more initiatives than they can ever finish at once. Portfolio management operates one level up — where the organisation decides what to invest in at all, how many of those may run in parallel, and in what order. This chapter brings together three traditions: the governance strength of classic portfolio management, the flow orientation of lean portfolio management, and the hybrid reality in which both are needed. It shows how OKRs, portfolio kanban and WSJF prioritisation merge into a steering system that translates strategic intent into operational flow, and why the lean business case treats an investment as a hypothesis rather than a forecast. It is just as candid about the blind spots — the political dimension of stopping work, systematically under-prioritised enablers, and the day-to-day work that quietly ties up most of the capacity. The chapter shows that the biggest lever in a portfolio is not better planning but the courage to send a stop signal.

Eighty people, two days, up to 200,000 euros per event: big-room planning looks expensive until you set the cost of a quarter of teams working past each other next to it. PI Planning from SAFe is the best-known form, but the underlying pattern reaches further and carries the OKR alignment event, the Quarterly Business Review, the portfolio planning day and the open format of Open Space Technology just as well. From the Program Board with its red woollen threads through ROAM risk categorisation to the confidence vote, the most honest moment in any organisation, the mechanics are described so they can be applied with or without a framework, at fifty people as at five hundred, in the room as on the screen. The boundaries are named just as plainly: poor preparation that costs more than no planning at all, facilitation as an underrated side task, and the mistake of treating scaling as mere multiplication of rooms. The chapter shows how a shared plan turns into real commitment, and which five-part pattern carries every effective planning format, whatever it happens to be called.

Whether an IT landscape is built from one large system or from many replaceable building blocks looks like a technical question – yet it is a strategic one: years later it decides whether a system change is possible at all or only exists in theory. What began in the nineteen-nineties as rational bundling into ERP suites and portal frameworks is now often an invisible dependency that destroys the freedom to decide without anyone noticing. This chapter shows how three integration layers – identity through single sign-on, data through APIs, ETL and events, and presentation kept headless from the logic – do what the monolithic suite once did, but without its lock-in. It connects the balance of emergent design and intentional architecture with the idea of the composable enterprise, and makes clear why Conway's Law only allows the desired architecture through the right team structure. The boundaries are named honestly too: distributed systems are complex, integration has a cost, and for small organisations a suite is often the more economical choice. The chapter shows that loose coupling is not an end in itself but the architectural precondition for the make-or-buy question to remain a real decision, rather than a forced stay with the existing vendor.

In most organisations, make or buy is treated as a technology question — which software solves the problem best. It is really a strategic one: does the capability a piece of software delivers belong to what makes the company unique, or does it merely fill a commodity function that a thousand others need just as much? This chapter sharpens the choice between building, buying and renting around a complete five-year calculation that includes maintenance, operations, price increases, exit costs and the cost of delay — instead of setting only the licence against the development cost. It takes apart the most expensive conviction in IT management, "we are special", and shows how AI-assisted development tips the maths for point solutions, while systems of record such as CRM and ERP remain a different category. As a fourth option it describes decoupled extension: buy the core, build the decisive 20 percent independently through APIs, and so avoid vendor lock-in. The chapter shows how to structure this decision with a core-competence analysis, a full TCO and an honest look at the organisation's own capabilities, rather than leaving it to gut feeling.

In the age of AI, a coding agent writes code faster than a team can review it – and gets it wrong the moment the requirement is ambiguous or an architecture decision was never written into the source. The Hybrid Implementation Hypothesis (HIH) moves the bottleneck to where it belongs: a clarified, verified brief produced before the first line of code exists. It draws a strict line between a Requirements Agent that clarifies the what and why and anchors the architecture guardrails, and a Coding Agent that implements – a separation of powers that stops the same actor from deciding and building at once. Two verification steps put the assumption to the test, once before and once after implementation, so that a wrong assumption costs a sentence rather than a rebuild. A growing Architecture Decision Log feeds on lessons learned and steers the agent with more decision support on every iteration, without ever touching its model. The chapter shows how specification in the age of AI becomes a testable artefact that unites technical and functional requirement in one.

When an AI agent implements a feature overnight, tests and documentation included, the bottleneck of software development shifts: delivery is no longer scarce, but clarity about what should be built in the first place. This chapter shows why AI does not make software development uniformly faster but widens its variance, and why velocity loses its power to forecast as a planning figure. It introduces Spec-Driven Development as the structural answer, separates Kent Beck's augmented coding from mere vibe coding, and uses five technical mechanisms to explain why AI-generated code goes subtly wrong and how faulty fixes spread virally through a codebase. A sober tour of the SDD tool landscape, the "waterfall in Markdown" critique, and the question of whether AI makes the Agile Manifesto obsolete puts the hype in its place without succumbing to it. What remains is this book's central distinction: the two-week sprint was always only the practice; the purpose (regular feedback, limited batches, empirical control) stays and can be translated into new practices. The chapter shows how teams can re-time the BUILD phase in the age of AI without giving up their principles.

DevOps is not a framework and not a team name but a cultural change: development and operations stop being two departments with a wall between them and start working as one system. That shift rests on Gene Kim's three ways – flow, feedback and continuous learning – on the four DORA metrics that make software delivery empirically measurable, and on the sobering insight that no CI/CD pipeline, however perfect, repairs a culture in which reporting a fault is punished. The text takes apart the technical practices (continuous delivery, infrastructure as code, observability) as precisely as it does the organisational question of which team topology carries the load and which fails as a third silo. It dismantles the supposed trade-off between speed and stability, shows why DevOps and ITIL are complementary rather than competing, and names the boundaries openly – from regulated environments through legacy systems to the latest DORA finding that AI tools raise throughput and instability at the same time. The chapter shows that in the end it is not the org chart that decides success, but the single question Ron Westrum poses: what happens in this organisation when someone reports a fault?

Many see ITIL as a synonym for process bureaucracy – wrongly, because since ITIL 4 the rigid catalogue of processes has become a toolkit of 34 practices from which an organisation takes only what produces measurable value. This chapter sorts out what IT operations really need: incident and problem management, a change enablement that enables changes instead of smothering them in a Change Advisory Board, and above all the CMDB as the quiet backbone that answers within minutes which systems an outage affects and who is responsible for them. It shows why manually maintained configuration databases go stale on day one, and how autodiscovery turns documentation into a database that does not depict reality but is reality. Rather than staging ITIL and DevOps as opposites, it makes clear that both share the same management principles and combine into speed with structure. The boundaries are named honestly too: ITIL is no substitute for technical competence, and its greatest danger is not too little but too much. The chapter shows how the sense of stability can be reached with a few lived practices – and why that is worth more than 143 documented processes that no one follows.

For years cloud was taken to be self-evidently cheaper, more flexible and more modern — until David Heinemeier Hansson of 37signals did the sums, moved seven applications back onto his own hardware, and projected more than ten million dollars in savings over five years. This chapter treats cloud, on-premise and hybrid not as a matter of faith but as what it is: a procurement decision with an economic, a regulatory and a technical dimension. It works through the total cost of ownership honestly — including the costs that appear on no marketing slide, from egress fees to support tiers to price increases — and shows, through FinOps, how to bring cloud spend back under control. It clarifies why agile practices need no public cloud, when cloud repatriation makes economic sense, and why data location and data sovereignty are two different things under the CLOUD Act, GDPR, the EU Data Act and DORA. The chapter shows that the right answer is neither "everything to the cloud" nor "self-host everything", but running every workload where it belongs economically, legally and technically — and redoing that calculation regularly.

At three in the morning an alert wakes the on-call engineer — "CPU above 90 percent" — and once again it was only the backup job. These technically correct, operationally worthless messages are the heart of the problem this chapter dissects: monitoring is not a tool question but a leadership decision about what has to work, how you learn when it does not, and whose sleep you take for it. From the difference between monitoring and observability through SLOs, error budgets and burn-rate alerts to the craft of alerting on symptoms rather than infrastructure, it builds a practical map against alert fatigue. The second thread leads into the night itself: on-call as a legal, economic and psychological issue, with a country comparison spanning the United States, Australia, New Zealand and Germany, and four on-call models weighed against one another. The chapter shows that good monitoring does not lie in more dashboards but in the discipline of asking the right questions — and keeping the night as quiet as possible.

On 23 July 2025, an AI agent deleted a company's production database in seconds — despite a clear, repeatedly issued instruction to freeze all changes; a few months later the same pattern recurred at a second provider, this time taking every backup with it, through a token that could do far more than anyone intended. Incidents of this kind mark a new class of damage: an agent acts with the rights of its user, receives a plausible instruction, performs a plausible action, and the harm is irreversible before a human can step in. This chapter sorts the tool landscape that has grown up against this since 2024 into three complementary classes — vulnerability scanners, runtime guardrails and blast-radius audits — and shows why none is enough on its own. It explains why durable defence sits not at the model but at the action boundary: what an agent may actually do at runtime, which tools it can call, which credentials it can see, which actions force a confirmation. And it names the uncomfortable truth behind all the tooling: AI security is first a question of organisation and accountability, not of the next tool purchase. The chapter shows how to bring the two together, so that operations in the age of AI are not left to chance.

In most organisations, continuous improvement fails not for lack of will but for lack of structure — the classic lessons-learned ritual at the end of a project comes too late, does not transfer what was learned, and no longer helps the project itself. Kaizen turns this around: improvement is not a method you roll out but a daily attitude, carried by the people who run the process, in small, evaluated steps. Its engine is the almost hundred-year-old PDCA cycle, which the Improvement Kata extends with one decisive addition — improving towards a defined target condition rather than tweaking arbitrary dials. Four empirically grounded delivery metrics — deployment frequency, lead time, change failure rate and time to restore service — serve as a compass rather than a bonus-linked KPI, and disprove the widespread assumption that speed comes at the cost of stability. The biggest lever is also the most uncomfortable one: reserved capacity, because anyone who plans utilisation entirely around feature work has neither the structural nor the mental room to improve. The chapter shows how a consequence-free ritual becomes an effective routine — and where kaizen reaches its limits, because a system that is fundamentally set up wrong needs radical change, not small steps.

"Self-praise stinks" – this saying costs IT organisations more than they realise: teams deliver results no one sees, and lose the one reliable channel through which a product's direction can be corrected. The review steps in exactly here, not as a sign-off and not as a slide show, but as a shared inspection of the working product by the people who know the context. It delivers two signals at once – visibility for the team's work and product feedback that only emerges when someone reacts to something concrete rather than to a description. From the classic sprint review through the science-fair format to reviews at team, ART and portfolio level, the same principle scales beyond the team boundary – and where it fails becomes just as clear: missing stakeholders, no showable increment, and feedback that never turns into backlog decisions. The chapter shows how one structured occasion keeps good work from staying invisible and bad work from running on unnoticed.

The fact that stakeholders praise a feature says nothing about whether the people who have to work with it every day actually use it. Approval in the review and use in daily work are two different signals, and only the second one decides whether a product succeeds or fails. This chapter shows how to seek out real user feedback deliberately and early: through the Minimum Viable Product, which answers a hypothesis instead of finishing a product; through qualitative observation, which makes the why visible; through analytics, which supply the how-many; and through A/B tests, which turn endless argument into solid evidence. It ties these tools together into the Build-Measure-Learn cycle, sets out the data-protection limits from GDPR through Germany's works-council law to the differences between countries, and states plainly when each method works and when it does not. The chapter shows how organisations can replace the most dangerous assumption in product development, that they already know what their users want.

Retrospectives are seen as a Scrum ritual, yet no team needs a framework to benefit from them: any team that works together regularly gains from pausing on a fixed cadence to examine its own working process. What matters is not the frequency but that something concrete comes out of it that actually happens in the next cycle, not the vague intention “we should communicate better”, but a single improvement that gets done. Derby and Larsen’s five-phase model secures exactly that, with root-cause analysis at its heart: jumping straight from “what happened?” to “what will we do differently?” treats symptoms. Formats from the sailboat through 4Ls to Lean Coffee keep the routine alive, and psychological safety is what makes it honest in the first place. The chapter shows how a duty exercise becomes a learning tool, and where its limits lie, such as incidents, for which the blameless post-mortem is the better format.

Teams using AI agents usually fix their mistakes one at a time in review, efficient per incident, corrosive over time: the same “almost right” class of error keeps returning in variations as long as no one addresses the cause. This chapter carries the mechanics of the retrospective over to non-deterministic systems and adds two disciplines: a persistent ticket per class of AI error, and the separately maintained knowledge sources of the two agents an organisation works with, constitution, spec templates, architecture decision log. The lever is not the model but the knowledge base that improves data quality, while DORA research shows that AI is an amplifier that magnifies existing strengths and weaknesses. Heijunka and WIP limits on review work contain the structural overload of the reviewers. The chapter shows why retrospectives applied to AI are kaizen for systems that answer differently on every run, and where the boundary lies: tacit knowledge belongs in the conversation, not in the database.

The IT skills shortage has turned sourcing into a survival question for every IT organisation: across the English-speaking world and the German-speaking market alike, capacity can no longer be covered from the local labour market alone. Permanent staff, freelancers, nearshore, offshore or managed service are not a matter of the cheapest hourly rate but a strategy for gaining access to talent, and every option carries a cost beyond the headline rate. This chapter orders the five sourcing options along two axes, strategic importance and internal competence, and shows with hard numbers why 25-dollar offshore hours quickly become 35, why attrition in India has to be planned for as the norm, and why nearshore is not cheap onshoring. It challenges the common practice of putting external hands on the future projects and the company's own people on day-to-day work, and turns that logic around. An aside on NASA and SpaceX reveals why billing by the hour systematically sets the wrong incentive. The chapter shows how the right mix is led not as a contract but as a living decision oriented to importance and competence.

Hourly billing rewards whoever takes longest, and yet it is the default for work whose scope no one knows at the outset. This chapter shows how contracts can combine budget certainty with flexibility without one side taking advantage of the other: the agile fixed price with its four mechanisms, Change for Free, Money for Nothing, Risk Share and a checkpoint phase, the contract spectrum from firm fixed price to time and materials, and cooperative procurement on the New Zealand model. At its core is a shift of incentives: a contract that rewards change instead of penalising it and permits an early exit turns a zero-sum game into a partnership, and the documented evolution of contracts shows that form follows trust, not the other way round. The German legal picture holds an uncomfortable truth: neither the Werkvertrag nor the Dienstvertrag fits agile development completely, and case law remains inconsistent. The chapter shows which contract suits which way of working, and is expressly no substitute for legal advice.

A Scrum team in Frankfurt develops right up to the last day of the sprint, then quality assurance has to step in — and because both sit in the same time zone, an end-of-sprint bottleneck forms that easily costs a single team 195 person-days and more than 150,000 euros a year. Follow the Sun turns this drawback into an advantage: commit your code at 5 pm in Frankfurt and the test results are waiting the next morning, because a complementary team in Auckland has worked on it for eight hours in between. The chapter shows why the time zone is not a geographic side constraint but a resource — one that can be quantified through Erran Carmel's notion of calendar efficiency — and why the model still rarely succeeds. The IBM case studies make clear that it is not the time offset that decides success or failure, but culture fit and the discipline of clean handovers: USA/Australia worked, USA/India did not. It names concretely which time-zone combinations hold up from a German-speaking, Oceanian and American perspective, where the limits of the model lie, and why, from a German point of view, New Zealand of all places is the almost ideal QA partner. A pragmatic look at a productivity lever most organisations leave untapped — not out of ignorance, but because they treat the clock as a constant.

A signed contract is not a result but a beginning: the real work starts once the provider is on board and no one is left to say which way things should go. This chapter answers the uncomfortable core question of every outsourcing decision – does the organisation have enough subject-matter competence to lead its partners, or is it already being led by them? It shows how governance on three levels actually steers rather than merely administering reports, how OKRs become guardrails for external undertakings, and how SLAs with three to five relevant metrics and consequences that genuinely bite turn paper tigers into instruments of control. It gets especially sharp in multi-vendor environments, where three providers feed into the same value chain and none owns the interfaces between them – a no man's land that only the organisation itself can close. Whoever understands and steers the integration points steers the system as a whole; whoever does not is merely hoping. The chapter shows how a contract becomes a working partnership – and when it is wiser to draw the consequence in good time.

In May 2026, Cognition AI, maker of the autonomous coding agent Devin, announces partnerships with Cognizant and Infosys – and describes them not as a tool licence but as the delivery of autonomous software-engineering capacity. This creates a sourcing category that fits neither the SaaS nor the managed-service grid: the unit of delivery is no longer a person but a model run. This chapter places agentic delivery within the existing sourcing matrix, shows how the make-or-buy threshold shifts once a former six-month project takes three weeks, and dissects the three contractual questions that decide success or dispute in 2026: indemnification for intellectual-property infringement, warranty under non-deterministic delivery, and the new coverage gap in insurance policies. It explains the SLA mechanics for the case where a pull request is 95 percent correct, and names the real danger soberly with Deloitte's figure: only 21 percent of companies have a mature governance model for autonomous agents, while 74 percent intend to use them within two years. The chapter shows why governance in the age of AI is not software but a capacity – and why anyone who signs without it buys speed without a structure of responsibility.

Most IT books explain how to set projects up correctly – hardly any explain what to do once something has already gone wrong. This is exactly where the ACC principle comes in, borrowed from New Zealand's state-run no-fault accident insurance, which since 1974 has consistently put compensation and rehabilitation ahead of the question of blame: stabilise first, then analyse, then improve. Applied to project crises, this principle breaks the expensive ritual in which supplier, business unit, IT and executive point at one another in turn, each building a line of defence instead of a solution. From the psychology of the fundamental attribution error, through the economics of blame – whose administrative costs no budget ever shows – to the clear separation of accountability and blame, the principle offers a robust ordering for the moment things go sideways. The chapter shows why the question of blame slows the healing process rather than speeding it up, and how IT organisations win the first hour of a crisis simply by postponing it.

When a project tips over, the most convenient explanation is quickly at hand: the wrong method. Yet the industry’s success rate has hovered around one third for a quarter of a century even though almost everything now runs agile, and what decides success is not frameworks but starting conditions: user involvement, genuine executive backing, clear requirements. This chapter describes stabilisation as a fixed chain of a few decisions: read the early warning signs, assign the problem to a category, and only then work out options, opening up the room between the false alternatives of carrying on and adding people, with four levers from descoping to breaking the endeavour apart. Backed by Brooks’s law, the optimism bias and the sunk-cost rule, and rounded out with prevention: pre-mortem, rollback capability, declared reserves. The chapter shows how to make a project capable of decisions again, and that some endeavours can only be brought to an orderly close.

Where the first question after an incident is who is to blame, a team shifts into defensive mode, no one lies, everyone withholds. This chapter shows why psychological safety is the factor without which no honest root-cause analysis succeeds: Google’s Project Aristotle identified it as the strongest predictor of team performance, and the DORA report quantifies how much more often safe teams report near misses. Four survival strategies of conditioned organisations, timidity, obstructionism, people-pleasing and the covering reflex, explain the silence, while Sidney Dekker’s Just Culture separates honest error from repeated negligence. The five-step format of timeline, root-cause analysis with Five Whys, impact, corrective actions and review directs every question at systems rather than people. The chapter shows how a failure becomes insight rather than a tribunal, and why “blame aware” is more realistic than fully blameless.

An AI agent can delete a production database in nine seconds, four agents can burn through 47,000 dollars in eleven days unnoticed, and a single constitution violation can drift through hundreds of thousands of lines of code over weeks – the damage classes of the AI era are new, and the classic incident vocabulary has no word for them. This chapter develops the forensics and post-mortem discipline for exactly these incidents: why learning is not the same as fixing, why distributed decision chains no longer have a "root cause", and why responsibility always runs along the people around the agent, never along the agent itself. It shows what carries over from classic blameless analysis and what has to be added – the version snapshot before every agent run as a forensic precondition, test batteries instead of single reproductions when systems running at temperature above zero cannot be reproduced deterministically, and a responsibility analysis that, when several agents interact, treats the interaction itself as the source of harm. The ACC principle gains an operational extension here: pause the agent and roll back to a known good configuration first, then analyse – because the damage keeps growing while you wait for the exact cause. As the close of the book's AI thread, the chapter draws together what connects all seven AI chapters: that the visible practice has become cheap and neglecting the purpose expensive. The chapter shows how an organisation turns every AI incident into a step of learning rather than merely fixing it away.

At the end comes the most practical question of all: where do you start when an IT management model with seven dimensions sits in front of you and there is no capacity for seven building sites at once? This chapter pushes back on the widespread idea that change needs a burning platform first, and counters it: it is always exactly now the right time to do the right thing. It offers an honest stocktake along seven guiding questions, a four-phase implementation path from Assess through Pilot and Scale to Embed, and the uncomfortable truth that change cannot be delegated to consultants, tools or a role. Anyone who addresses the weakest sense first rather than the most interesting one gains momentum without overwhelming the whole organisation. The chapter shows why frameworks do not buy change and how a model on paper becomes a lived way of thinking.

The book closes with the author's conviction from 23 years in IT transformation: the problem was never the framework, it was always the understanding. The best organisations, on this reading, are the ones that stopped searching for the right framework and started asking the right questions – the answers have to be found anew in every organisation, with its own people and its own means. A pointer to heptams.org carries the work of the book on as a community of practitioners, with training and with whatever has changed since these pages went to print, above all AI-assisted development and the shift from writing to reviewing. The text ends with the place and year of writing, Auckland 2026.

Three tables map the functional role structure of the Hepta Management System – Value Owner, Flow Owner, Architecture Owner – onto the names used in Scrum, SAFe, LeSS, Disciplined Agile and PRINCE2/PMI, separated by team, domain/programme and portfolio level, each with German labels for organisations that run their role names in German. The mapping shows the closest functional match, not an exact equivalence, because some frameworks cut certain functions differently across levels or do not know them at all. Explanatory notes give the reasons for three levels instead of four, for the term "Owner" in the sense of accountability rather than property, and for German labels kept deliberately functional and free of inherited hierarchy vocabulary. The appendix closes by placing the missing explicit architecture role in Scrum and LeSS, and the origin of the title "Enterprise Architect" in the TOGAF tradition.

Around 80 alphabetically ordered entries define the central terms of the book, from ACC Principle and Agentic Delivery through DORA metrics, Kaizen and Little's Law to WIP and WSJF. Each entry points to the chapter where the term is treated in full. Terms that belong to the Hepta Management System itself – such as the VFA Triad, Practice and Purpose, the Seven Senses or the Hybrid Implementation Hypothesis – are marked as such. Where a term carries different meanings across frameworks, for example "epic" in Scrum compared with SAFe, the difference is noted explicitly.