From Scrum to AMMERSE

We want to uncover better ways of working.
Along with that, people work differently, and the type of work warrants different constraints.

This document is a guide to moving from Scrum to the AMMERSE Method.

AMMERSE Definition

Scrum is a lightweight framework, quite at odds with AMMERSE, a value system.

AMMERSE is technically more than a method.

  • AMMERSE is a value system: a set of values with feedback loops.
  • AMMERSE is a language: an abstraction to communicate about complexity
  • AMMERSE is an analytical tool: a means of testing the environment
  • AMMERSE is a method: a methodological approach using values as the foundation
  • AMMERSE is a facilitation tool: A structured means to mediate discussions about values and their implications.
  • AMMERSE is a decision-making framework: A guide for aligning priorities with organisational and individual goals.
  • AMMERSE is a diagnostic instrument: A method to identify misalignments and areas for growth between individual and organisational values.

Although that sounds rather complicated, the reality is that AMMERSE accomplishes all of that with seven values.

  1. Agile
  2. Minimal
  3. Maintainable
  4. Environmental
  5. Reachable
  6. Solvable
  7. Extensible

The rest of AMMERSE is just a mixture of psychology, social science, behavioural science, data, tools, systems theory, complexity theory, analytics and other aspects you may already know.

Scrum prescribes a formulaic set of process events, which is said to help generate value through adaptive solutions for complex problems. It claims to provide an answer in dealing with complexity. It does this by scheduling set events and proposes that a complex problem can be resolved by adding it to a backlog. It also suggests that timeboxing is an answer to complexity and that the complexity will somehow be solved by repeating events, including a daily standup and refining a backlog. It further states that it works because of empirical scrum pillars of “transparency, inspection, and adaptation”.

AMMERSE does not believe that a disciplined and controlled set of events with the repetitive mantra of transparency, inspection and adaption is a sure way of understanding complexity.

AMMERSE is a value system where complexity is tackled by means of understanding the context and the constraints of human behaviour, processes and the nature of the interrelated and sometimes arbitrary boundaries of domains. AMMERSE looks at the values operating in and around processes and the values within the problem space. It reasons about the gaps.
AMMERSE considers transparency as ‘when beneficial’, inspection as ‘what are the seven values’ and adaption as ‘what is the gap’, and how we want to modify the values of the system to close the gap to our desired direction. A time box is irrelevant to discover, reason, inspect, change, and adapt to the values in a system. Scrum’s arbitrary timeboxes and even gives you a recipe for this “Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”

AMMERSE does not place any time box on any activity.

In a nutshell, AMMERSE has the following:

  • Async activity
  • Documentation
  • Value Gap Analysis

AMMERSE does NOT

  • Require a Product Owner or a Product Backlog
  • The team does not look at a backlog to work from

Scrum may claim that its repetitive recipe deals with complexity, but it depends entirely on the people and their abilities and the nature of the work. No matter how often you repetitively try to count grains of sand on the wind, you won't be able to, no matter how iterative in process you are.

AMMERSE understands the complexity and provides the AMMERSE Value System as a tool for inspecting complexity by looking at constraints and other clues.

AMMERSE Theory

AMMERSE understands that complexity is complex and that linear processes or reductionist tools are insufficient. AMMERSE understands that there is science behind people’s behaviours, individually and as teams. AMMERSE understands that a given problem, whether scientific or social, involves more variables than humans typically can consider and takes tremendous cognitive effort. AMMERSE understands that cognitive heuristics are valid biologically but offer many challenges and rewards. AMMERSE understands that our abstractions and metaphors can be helpful and a hindrance, so we best be mindful of them.

AMMERSE is an abstraction of what we call personal values. It is an abstraction, a new language for communicating about people, interactions, motivations and behaviours, and at the same time, an abstraction for tasks, activities, value propositions, gaps and even how components in a system interact. This provides a single simple language to open up complexity.

AMMERSE understands that it is only one tool of many that could be used simultaneously to probe complex systems.

Scrum says it's transparent. But transparency can be good or bad, so why take one side of this argument? Transparency provides too much information and can also be negative on privacy.

Transparency is a value and it should be adjusted according to the outcomes we want.

Scrum says you must inspect and adapt, but it doesn’t tell you what or how to inspect what and neither how nor what to adapt to.
Scrum says it is founded on empiricism, but the framework remains the same, and the processes remain the same. It is not empirical about itself and doesn’t provide a recipe or any guide for you to be empirical about your methods, Scrum or your work.

Scrum claims to be empirical, but it is merely a repetitive, fixed process that demands you to be empirical. The Scrum process provides discipline, control of a backlog of items, and the instruction to be empirical and transparent.

AMMERSE does not have any fixed process. It also wants you to be empirical. However, it provides you with tools to do your job at different scales.

  • Heuristic (a mnemonic quick way of thinking that can lead you down a good path)
  • Descriptive (the same language to describe people, behaviours and systems)
  • Prescriptive (allows you to build on the language to create prescriptions for your context)
  • Empirical (will enable you to track and record your prescriptions heuristically - statistically)

Transparency

Transparency is one of hundreds of values. AMMERSE allows you to reason about as many values as your team or organisation can handle.

Inspection

The art of inspection is not a single activity or use of a single tool. Scrum offers nothing but a backlog and a regular meeting. This is not enough to deal with complicated or complex situations. Many of the meetings are held despite people having nothing to say or having the expertise to inspect what they are doing with any real tangible suggestions.

AMMERSE helps you inspect anything with the AMMERSE Value system and heuristics.

Adaptation

Scrum doesn’t provide any adaptive techniques, yet adapting is not a simple activity, as it takes a tremendous understanding of the system and the effects of actions. The more complex the environment, the more impossible it is to know.

AMMERSE provides a means of inspecting, recording it, and measuring again after the adaption for assessment.

AMMERSE Values

Although Scrum is often viewed as a strict framework, it is rooted in core values such as commitment, focus, openness, respect, and courage. In AMMERSE, values are also central, but they are defined and agreed upon by the individuals and teams rather than being prescribed.

While Scrum has selected a few values for you, AMMERSE provides the understanding of adopting your own values. Scrum pretends to know the best values, while AMMERSE offers a tool to inspect and adapt your values to your context.

Scrum Team

AMMERSE does not introduce a term where it is not needed. You can have any team you want.

Each member is in the team because they provide skills to allow everyone to deliver value. The team consists of values and is considered a prioritisation and balance of values, all participating to create value for others with values.

Developers

AMMERSE is not specific to development but AMMERSE applies even to code and design decisions, quality and more.

Product Owner

There is no Product Owner in AMMERSE, but there is nothing in AMMERSE that says you can’t have one if the value is there. AMMERSE provides the language to reason whether the value is there and what value is added. A Product Owner who understands AMMERSE values and how to see and create value may be a strong asset to the team.

Scrum Master

As with Product Owner, however, I suggest you change your title to Value Designer/Architect or something else to avoid confusion. A Scrum Master will have experience and can be valuable. A direct set of tasks for AMMERSE is evaluating values, doing gap analysis and fostering the right value culture. This includes vision, strategy, roadmap, feature analysis, team dynamics, etc.

Scrum Events

The Sprint

Replace Sprints with Stints

No fixed cadence, drum beats, or time-boxes are necessary. Scrum enforces discipline and control via time-boxes and set events that aid in dealing with complexity. However, most development teams are not in chaos, and who knows if they are dealing with a complex system. Also, complexity cannot be solved by mere discipline.

Instead, AMMERSE uses “Stints” of varying lengths based on the needs of the work. Teams can choose short stints (e.g., a day of mobbing to finish a single task) or longer stints (e.g., a month for two developers to complete an essential library). Different developers may operate on different, complementary timelines. A stint is when the team or a subset works towards delivering specified value.

A sprint is designed to control the team and arbitrarily “fit” things into a time box; this appeals to a manager who doesn’t have to think deeply about durations. By contrast, AMMERSE values hands-on, technically adept management and collaborative decision-making about how long each stint should last.

Mixing Stints

  • A day of mobbing on one task
  • A week of pairing for a few tasks
  • A month for two developers to complete an essential library while the others work for a week on different tasks
  • A design-only stint
  • A test-only stint

Sprint Planning

No Sprint Planning

Design and planning in AMMERSE are parallel tasks. There is no mandatory rule for extensive, joint sessions to design or estimate. Instead:

  • Continuous Design: An individual or lead architect can design at any time and share plans asynchronously with the team.
  • No Estimation Games: There is no event for sprint planning or formal estimation. Each developer or specialist can plan and design what is needed, sharing updates in the team’s channel.
  • Natural Flow: When more serious or intricate design is required, a specialist will create and communicate the architecture; otherwise, planning is decentralised and fluid.

Daily Scrum

No Synchronised Daily Standup

Instead of a daily standup, the team relies on asynchronous communication in shared channels (e.g., Slack, Teams, Discord). The rules:

  • At Most One Day of Silence: Each member posts updates to avoid going silent for too long.
  • Be Responsive: Everyone, including managers, must participate and be available.
  • No DMs By Default: Project-related communication stays in public channels for transparency.
  • Managers Are Included: They must also share their own tasks and avoid excessive direct inquiries like “How’s your work?” Instead, they post what they need or are doing.

Sprint Review

There is no Sprint Review in AMMERSE. Instead, an Alignment Meetup is scheduled when necessary.

Alignment Meetup

For 90 minutes, the entire team must be present, onsite or online. The discussion is purely about alignment and must not include progress reports. You can set a fixed date/time. However, it is best held with flexibility and adjusts according to the need and the value. Ie. Hold it when you need to.

What is alignment?

People are working on tasks; some are interrelated and require coordination. The usual coordination will generally appear in the team’s communication channels, so we are consolidating and confirming the alignment.

  • Alignment is teamwork
  • Alignment of work, timing.
  • Alignment of values, strategy, and deliverables.
  • Aim to have nothing to say

Most of the alignment should be outside of this meeting. If the team is adhering and working, and things are in rhythm, you may find that this meeting is superfluous. If there is nothing to say, cancel the meetup. If anyone suspects that the meeting is potentially moot, they raise it a day before in the team’s communication channel with the phrase, “Are we aligned?”. Anyone who feels the answer is a no must communicate their reasoning in the chat before the meeting. If it is remotely helpful to hold the meeting, then do so. If the team are all in the middle of things and there is nothing out of step, then the meeting should be deferred. Although you may want to hold the meeting at a set time per week, it is best to align according to logical gaps and stops in the workflow.

Intervention (Forced Alignment Meetup)

As a leader, you can force an alignment meeting. But you should not be doing this just because you can. Reasons for forcing an alignment meetup:

  • To get the team focused
  • To correct things that are going wrong
  • An emergency, either from the client or a change of direction
  • The team is not participating
  • The team culture needs to align

If intervention is required, do so with values. What values are you expecting, and why are you not seeing them? What are the behaviours in the team that are affecting value alignment?

Sprint Retrospective

No Retrospective Meeting

AMMERSE replaces the retrospective with a continuous improvement mechanism:

  • Request for Comment (RFC): Anyone wishing to improve a process or code quality can post an RFC in the shared channel.
  • Team Response: Every team member must respond with an opinion—agree, disagree, or elaborate.
  • No Scheduled Event: Improvements are handled as they arise, not relegated to a fixed ceremony.

Scrum Artifacts

Product Backlog

There is no product backlog in AMMERSE

Sprint Backlog

There is no sprint backlog in AMMERSE

AMMERSE Roadmap

Instead of a product and a sprint backlog, a simple document outlining the vision and objectives for the product and the team is necessary. This should be a short document focusing on high-level values, goals, market forces and competitor analysis.

Work and prioritisation

Stakeholders write what they want into an async channel. The team answers and goes through it when they can. Stakeholders who mention something and it is not picked up must escalate and provide better reasoning for its value. Developers seeking value will pick up and execute anything that has the potential to be of high value. The team looks at the vision, the roadmap and AMMERSE values to determine viability and priorities.

The team will ascertain the value proposition and priority on a stint-by-stint basis. Remember that people need no align to a stint as it is a continuous improvement mechanism.

The objective is whatever is pushed forward and clear to allow the greatest amount of value, to the greatest amount of stakeholders, aligning with team values.

Increment

There is no Increment

There is no need for this terminology. Software has releases and we are all trying to release value. Marketing departments want to release value or schedule a campaign to achieve desired value goals; developers want to push to the pipeline. There is no need for a special term. The important aspect is delivering value in the short-term, while not damaging the long-term viability of the same value.

There is no Definition of Done in AMMERSE. We strive for quality and have our testing and processes in place. Done is never actually done, even when you think it is. Done is abiding by the team's quality attributes and values. There is no need for a special term.

We use AMMERSE to discover the values of the team, product, and stakeholders and these are dynamic and can change.

How to Move from Scrum to AMMERSE

A short process to facilitate the move.

  1. Complete Your Current Sprint
    Avoid unnecessary disruption.
  2. Call an Introductory Meetup
    Prepare or confirm your asynchronous communication channel, set communication rules.
  3. Initiate a Two-Day Stint
    Continue normal tasks, posting updates asynchronously.
  4. Call Your First Alignment Meetup
    Occurs on Day 3 to decide priorities and set the second work stint.
  5. Second Alignment Meetup
    Reinforce communication practices, ensure tasks are clear, and confirm whether the team is aligned.
  6. Explore AMMERSE Values
    Consider training or certifications that help you think in systems and use values to guide team behaviour.

Alignment Meetup

  • Purpose: Align tasks, priorities, timelines, and overall strategy.
  • Duration: 90 minutes; hold when it’s genuinely needed.
  • Cancellation: If there’s nothing to discuss or the team is fully aligned asynchronously, cancel it.

Final Thoughts

AMMERSE is mutable by design: add or remove constraints as your situation demands. You can adopt roles, time-boxes, or more formal processes whenever they add value. Most communication and collaboration happen asynchronously among professionals who take personal responsibility, stay aligned with team values, and strive for shared outcomes.

Additional Scrum Issues

Some general points did not make it into the main text.

Misattribution to Scrum

Scrum often becomes an “umbrella” under which every success or failure is explained. If a team excels in communication or problem-solving, they credit Scrum for “guiding” them, even though these skills might be well outside Scrum’s scope. Conversely, if issues arise, the blame often shifts to not applying Scrum “correctly” rather than questioning whether the framework is suitable.
This dynamic can lead to Scrum being treated like a catch-all philosophy rather than what it is: a lightweight framework. AMMERSE, by contrast, encourages looking at the actual values, skills, and behaviours driving outcomes rather than assuming that any single method alone can account for all team performance.

Scrum’s “Lightweight” Yet Prescriptive Nature

Scrum is marketed as “lightweight,” but it imposes rigid rules: mandatory timeboxes, daily standups, fully synchronous attendance, strict roles, and backlog-driven work. Teams must repeatedly cycle through these events and artefacts without pause, making it more constraining than its “lightweight” label suggests. AMMERSE, by contrast, questions whether such a fixed set of constraints is universally beneficial or just another prescriptive recipe.

The Strain on High Performers

Scrum’s relentless sprint cycles and daily standups can amplify stress for motivated, quality-driven individuals. Knowing each day brings another checkpoint and that a sprint deadline looms can feel like continuous pressure rather than a supportive structure. For those who already hold themselves to high standards, Scrum’s rapid cadence and visibility can intensify anxiety instead of fostering well-being or genuine quality outcomes.

Monotony of Repetition

Scrum’s repeating cycles, every day a standup, every few weeks a Sprint Review, and so on, can become monotonous for team members who crave variety or more organic workflows. The predictability that some find comforting can feel tedious to others, leading to disengagement. This repetitive cadence risks stifling creativity and motivation over time, particularly for those who thrive on change and flux.

Narrow Definition of Values

Scrum only highlights a handful of values, commitment, focus, openness, respect, and courage, yet overlooks the wide range of possible values teams may prioritize.
It also treats concepts like transparency as purely beneficial, leaving no room for nuance around privacy or context-specific boundaries. In reality, values are nuanced, subjective, and highly dependent on a team’s situation; limiting them to a fixed set can constrain deeper exploration and adaptation. AMMERSE understands values, value feedback loops and how to think about the complex nature of systems using values.

Hypocrisy in Espoused vs. Inherent Values

Scrum highlights certain aspirational values, openness, respect, and courage, yet its built-in practices often reflect control and discipline with clockwork-like repetition. This mismatch can undermine the authenticity of the framework’s stated values and create tension for teams that feel compelled to uphold both ideals simultaneously. Many developers also do not realise that it is all about control until something feels off.

Issues with Autonomy

Scrum promotes autonomy and self-organisation, yet the constraints of daily standups, constant transparency, and the authoritative roles of the Scrum Master and Product Owner can create only a limited sense of freedom. In practice, teams operate under tightly controlled conditions, and this “autonomy within a box” can become an illusion, especially if true leadership is lacking to guide and empower rather than merely enforce the process.

Micromanagement Risks

Because Scrum enforces daily status updates, regular backlog grooming, and heavy visibility into everyone’s tasks, it can inadvertently enable micromanagement. Leaders inclined to control details may misuse these structures to scrutinise every step, undermining genuine autonomy and trust within the team.

FREE EVENT

The AMMERSE Method is a Scrum replacement and what Agile was always supposed to be.

AMMERSE Levels

Level 1

7 Principles: Agile, Minimal, Maintainable, Environmental, Reachable, Solvable, Extensible.

Level 2

The AMMERSE Set has weights assigned to 7 Principles. eg. “Enterprise Strategy”.

Level 3

AMMERSE Sets in a grouping that work together for a purpose. eg. Modes.

Level 3.1

You can extend AMMERSE by creating your own Sets and Frameworks.

Our goal is to enable business strategy, implementation and the reaching of objectives by giving you the tools to design your own methods. 

Sign up for the occasional email