In this Areopa Academy webinar — the 105th in the series — Ivan Milanov, Engineering Manager and Business Central developer with 15+ years of experience, presents a framework he calls the “3S”: Scrum, Stoicism, and Systems Thinking. Moderated by Bert Verbeek, the session explores how these three disciplines can help BC teams move from daily firefighting mode to clearer thinking, better decisions, and a more sustainable working pace.
The Problem: Daily Chaos in BC Projects
Ivan opens with a candid description of what working on a Business Central implementation often feels like from the inside: urgency everywhere, cross-functional friction between developers, product owners, and stakeholders, too many meetings without clear outcomes, and a constant stream of notifications and shifting priorities. This is especially common in end-user environments where the team supports a live system while also delivering new features.
The goal of the session is not to eliminate this complexity — which is inherent to ERP work — but to introduce tools that help teams design clarity into how they work rather than leaving focus and structure to chance.
The 3S Framework
Ivan defines each of the three pillars before showing how they reinforce one another:
- Scrum — An agile framework for structuring work through iterative sprints. It provides rhythm, transparency, and a built-in mechanism for continuous improvement.
- Stoicism — A Hellenistic philosophy focused on virtue, resilience, and accepting what is beyond your control. Ivan draws on modern Stoicism for its practical applicability to team dynamics and decision-making.
- Systems Thinking — A holistic approach that examines how parts of a system interconnect. It encourages teams to step back, see the bigger picture, and fix root causes rather than symptoms.
Scrum: Structure, Commitment, and Continuous Improvement
Ivan covers the core elements of Scrum, clarifying a common point of confusion: Scrum is a framework for getting work done, while Agile is the broader philosophy. Scrum is defined by the Scrum Guide — co-authored by Jeff Sutherland and Ken Schwaber — and is grounded in empiricism: knowledge comes from experience and observed results, not upfront assumptions.
📖 Docs: The 2020 Scrum Guide — the official, freely available reference for the Scrum framework by Ken Schwaber and Jeff Sutherland.
The Agile Manifesto outlines four foundational values that underpin Scrum: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. Ivan emphasizes that “responding to change” does not mean abandoning your sprint commitment at every new request — it means recognising change, evaluating it, and deciding consciously how to act.
On the Scrum process itself, Ivan stresses the distinction between the product backlog (everything the product owner has planned, ordered by priority) and the sprint backlog (what the team commits to in a given sprint). Protecting the sprint backlog from constant churn is important: every unplanned swap erodes the team’s commitment. Ivan’s rule of thumb is that as long as the sprint goal is not jeopardised, one swap may be acceptable — but frequent changes signal a planning problem.
Stoicism: Resilience and Focus for Developers
Stoicism originated in ancient Greece and was developed further by Roman figures such as Marcus Aurelius, Seneca, and Epictetus. Ivan introduces six Stoic principles and maps each to practical team situations:
- Virtue is the only good — Wisdom, justice, courage, and temperance are what matter. In a team context, this translates to doing quality work and being honest, even when it is uncomfortable.
- Accept what you cannot control — Focus your energy on your sprint backlog and your own actions. External noise — stakeholder politics, changing business requirements — is real, but reacting to everything is a fast path to burnout.
- Self-improvement and self-awareness — The sprint retrospective is the institutionalised version of this principle: a recurring opportunity for the team to examine what worked and what did not.
- Mindfulness and present-moment focus — Active listening in meetings, particularly in remote setups, is more difficult than it appears. Ivan notes that a 15-minute daily stand-up is only valuable if everyone is genuinely present.
- Strength in the face of adversity — A resilient mindset helps teams absorb difficult sprints, production incidents, and unexpected scope changes without losing their footing.
- Relationships and social cohesion — Happy teams perform better. Building good working relationships is not optional for high-performing Scrum teams.
Systems Thinking: Seeing the Bigger Picture
Systems Thinking asks developers and managers to zoom out. In a Business Central end-user environment, this often means understanding not just the code change in front of you, but how it interacts with integrations, middleware, and the users downstream. Ivan argues that too many teams address symptoms — pressing a button to fix a daily error — instead of diagnosing and resolving the underlying cause.
The “tools of a system thinker” slide contrasts several pairs: disconnection vs. interconnectedness; linear vs. circular thinking; working in silos vs. allowing emergence; breaking things into parts vs. synthesizing the whole; isolation vs. relationships. These are practical reminders to document system interfaces, build shared knowledge within the team, and think about feedback loops rather than one-way cause-and-effect.
The Perfect Mix
Ivan brings the three disciplines together in a single diagram: the Scrum cycle (sprint planning → daily scrum → sprint backlog → sprint review → retrospective → increment) annotated with the concepts from Stoicism and Systems Thinking that reinforce each phase. Feedback loops, interconnectedness, acceptance of what you cannot control, self-improvement, and circular synthesis all map directly onto specific moments in the Scrum cycle.
The message is that these are not three separate methodologies to adopt in sequence — they are complementary lenses that make each other more effective in practice.
Practical Applications
The Scrum Board
Ivan describes the Scrum board as the team’s single source of truth. “If it’s not on the board, it doesn’t exist.” Every ticket must reflect its real status — whether in Azure DevOps, Jira, or any other tool — so that stakeholders can check the board instead of pinging team members. This transparency is what makes inspection and adaptation possible.
Code Review in Business Central
Code review is relatively new to the BC ecosystem but is becoming established practice. Ivan lists its core benefits: catching defects early (when they are cheaper to fix), spreading knowledge across the team, improving overall code quality, mentoring junior developers, creating shared ownership rather than siloed expertise, and protecting against technical debt.
He also notes that code review is applicable even to CAL-based environments: using Object Manager History, it is possible to compare versions of an object and conduct a meaningful review. Ivan references Tine Staric’s session “Reviewing the Code Review” from BC TechDays 2024 as a deeper resource on this topic.
Estimations
Scrum typically uses Fibonacci numbers (1, 2, 3, 5, 8, 13…) to estimate story points, because work complexity grows non-linearly. Ivan acknowledges the debate around estimations — Allen Holub and the #NoEstimates movement argue that estimates are waste in mature agile organisations — but his practical recommendation applies regardless of where you stand: split your user stories and tickets as small as possible. Smaller items lead to better understanding, faster feedback, and less risk.
Retrospective Prime Directive
The retrospective is where the Stoic principle of self-improvement meets the Scrum ceremony. Ivan highlights the Prime Directive, originally formulated by Norm Kerth in Project Retrospectives: A Handbook for Team Review:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
This framing is important for creating a psychologically safe environment where retrospectives are genuinely useful rather than exercises in blame. No one underperforms on purpose; the team’s job is to build conditions where everyone can do their best work.
📖 Resource: LeadDev — an engineering leadership community running conferences in London, New York, and San Francisco, with articles and talks on topics including retrospectives, team health, and engineering management.
Memento Mori for Sprints and Backlogs
Ivan applies the Stoic concept of memento mori — “remember that time is limited” — to two Scrum artefacts. For sprints, the two-week boundary is not a punishing deadline but a commitment the team sets for itself: a checkpoint for reflection, learning, and improvement. For backlogs, the principle is “if it’s not a hell yes, it’s probably a no.” Items that keep shifting without ever being done should be flagged, and if they never rise in priority, archived. Every item ignored today is potential technical debt tomorrow.
80/20 and Delivering Value Early
The Pareto principle — 20% of features deliver 80% of the value — has a direct implication for delivery strategy: release early, even when the product is not “finished,” and collect feedback fast. Ivan shows a value curve from Jeff Sutherland’s book illustrating that the first 20% of features often covers the large majority of what users actually need.
Giving and Receiving Feedback
Ivan distinguishes between being kind and being nice. Being nice means avoiding difficult conversations; being kind means having them in a constructive way. He recommends the SBI model (Situation – Behavior – Impact) for structuring feedback: describe when and where the event happened, describe the observable behavior, then explain the impact on the team or the work. This makes feedback specific, objective, and less likely to feel personal.
Fix the Root Cause, Not the Symptom
Ivan closes the practical section with a reminder drawn from Systems Thinking: action is the antidote to paralysis. “If you don’t know where to start, just start. Action reveals the path.” Once you have taken the first step, the next step becomes visible. And once you are moving, look deeper: diagnose the underlying problem so you are not pressing the same button to work around the same bug every day.
AI Will Change the Tools — Not the Humans
Ivan addresses AI tools briefly but directly. Tools like GitHub Copilot and Cursor can accelerate coding, code review, and analysis. But the skills that determine how well a team works — communication, collaboration, problem-solving, and engineering judgment — become more important as routine coding tasks are automated. The future belongs to engineers and managers who know how to work well with people.
Key Takeaways
- Focus beats chaos. Stay centred on what is in your sprint commitment and within your control.
- Scrum is clarity. Clear cycles, clear ownership, clear improvement — not just a process.
- Be a Stoic. Virtue and excellence matter. Everyone does their best; help each other grow.
- Systems Thinking is essential. Everything is connected — think bigger than the task at hand.
- Technical debt is invisible but deadly. Unfinished work today is tomorrow’s burden.
- Deliver value early. Done is better than perfect; early delivery is your best feedback loop.
- Retrospectives and feedback are superpowers. Reflect, be kind, be direct, and grow stronger as a team.
- The future belongs to those who know how to work with people. Engineering mindset matters more than tool expertise.
Materials and Inspiration
Ivan recommended the following resources for those who want to go deeper:
- Substack — A wide range of engineering management and agile authors publish practical articles here.
- Allen Holub — Agile thought leader and vocal advocate for the #NoEstimates perspective.
- LeadDev — Engineering leadership conferences (London, New York, San Francisco) and a growing library of articles and talks.
- Book: Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland — the co-creator of Scrum’s accessible introduction to the framework.
📖 Docs: The 2020 Scrum Guide — a free, concise (~13 pages) reference for the Scrum framework, maintained by Ken Schwaber and Jeff Sutherland at scrumguides.org.
Ivan can be reached via LinkedIn or email at astramementosol@gmail.com.
This post was drafted with AI assistance based on the webinar transcript and video content.