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.
- Agile
- Minimal
- Maintainable
- Environmental
- Reachable
- Solvable
- 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.
- Complete Your Current Sprint
Avoid unnecessary disruption. - Call an Introductory Meetup
Prepare or confirm your asynchronous communication channel, set communication rules. - Initiate a Two-Day Stint
Continue normal tasks, posting updates asynchronously. - Call Your First Alignment Meetup
Occurs on Day 3 to decide priorities and set the second work stint. - Second Alignment Meetup
Reinforce communication practices, ensure tasks are clear, and confirm whether the team is aligned. - 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.