In software development, the term "agile" is used so frequently that its meaning can become diluted. For some, it is a strict set of rules and ceremonies. For others, it is a vague aspiration for speed. At Ximedes, a company rooted in complex fintech and public transport payment solutions, the approach is more fundamental.
It is a mindset built on a simple truth learned over two decades: change is not an exception, it’s a constant. This realisation prompted a significant shift from the rigid, fixed-price contracts of the early 2000s to a more fluid, collaborative way of working.
To understand this evolution and its implications for clients, we sat down with Joris Portegies Zwart, a software engineer turned CEO of Ximedes, who has witnessed this transformation firsthand. He offers a direct perspective on why the company embraces change, how it manages customer involvement, and why solving the core problem will always be more important than the specific development methodology used to get there.
You’ve been in this business for a long time. How did Ximedes initially approach software projects?
“When I started back in 2003, we mostly did fixed-price, fixed-date, and fixed-scope projects. We successfully delivered what we promised within those constraints. However, we soon discovered that a change in scope during a project was inevitable. We managed this through a "change control board," which treated every deviation as a formal exception. Over the last two decades, both the industry and our own contracts have undergone significant evolution. We came to accept that change is not an edge case but a fundamental part of the process. At its heart, agile development is about embracing that reality, and that is a principle we fully adopt.”
If change is constant, how do you involve the customer without them feeling overwhelmed or, conversely, getting in the way?
“Greater change requires greater customer involvement. It is that simple. In a framework like Scrum, this is managed through the Product Owner role. This person, who is typically on the client side, holds the authority to decide on priorities and approve changes. They are actively involved in the development process on a daily basis. This deep engagement ensures they are never taken by surprise by the direction the project takes. Constant communication removes the risk of misalignment.”
Is there a risk that the customer will become too involved, with opinions that create bottlenecks instead of giving value?
“Yes, change needs to be managed. Unmanaged change leads to chaos. Frameworks provide structure. This is why Scrum uses sprints, which are fixed periods of time, often two weeks, where the scope of work is locked. This provides engineers with the focused time they need to plan and execute effectively, without constant interruptions. It creates a predictable rhythm for both the development team and the customer.”
Agile is sometimes misinterpreted as having no plan. How do you balance the need for a foundational direction with the flexibility to adapt?
“That’s a critical point. A complete lack of planning is chaos, not agility. We inherited a valuable lesson from our days of fixed-scope projects: you must have an idea of the target. We kick off every project with a workshop phase. This can last a few days or longer, and its purpose is to get our bearings. We work with the client to discover the functional and non-functional requirements and discuss the high-level architecture, phasing, budget, and overall scope. This gives us a shared understanding of the general direction we need to run in before we start the first sprint.”
So, is there an official way of working at Ximedes? A framework you choose, and swear by?
“Scrum is a well-known agile framework, but we are not dogmatic about it. Our company is mature enough to adapt its processes to meet the specific needs of each customer and project. We prioritise flexibility over rigid adherence to a single playbook. For some projects, we might tailor sprint durations. For others, we might use a Kanban-like approach without any sprints at all. It depends on the customer's capacity to engage as a product owner. Our commitment is to solving the problem and delivering a quality solution, not to follow a specific framework.”
Looking ahead, do you see this agile approach becoming standard everywhere?
“We see clear differences between markets. In the Netherlands, clients have primarily adopted agile development. Many have become sophisticated development organisations themselves, and we integrate deeply into their teams. In markets like Germany, we find that the fixed-price model is still often preferred because customers are not always set up to fill a product owner role. Some clients see us as a "product supplier" rather than a "software supplier".”A partnership built on trust
How does this affect how you charge for projects?
“An agile process typically aligns with charging customers for the hours spent on their projects. While fixed-price, flexible-scope models exist, they are less common. Ultimately, building trust is the most critical element, especially with new customers. Our estimates form the basis for their budgets, and the entire process depends on collaborative decision-making. That collaboration can only succeed if there is mutual trust and respect.”
When defining Ximedes’ core focus, it sounds like the methodology is secondary. Is that right to assume?
“Exactly. Our primary goal is to understand a customer's problem and solve it efficiently. The specific development method or technology we use is a means to an end. This is why we do not brand ourselves simply as a technology supplier. We are specialists who solve problems in specific domains, such as payments and public transportation. Our clients trust us to choose the right tools for the job, just as you would trust a plumber to fix a leak without asking about the brand of their wrench. We are in the business of change, and our ability to deliver quality solutions comes from our commitment to adapting.”