Sell the way you work. Use Agile contracts.

Simplicity, quality, clarity, teamwork, and the ability to adapt to change - we work, of course, according to the principles of the Agile philosophy. We don't apply these principles only to operational processes (the "Agile development" of software). These principles guide all our activities, including sales.

When we approach a potential new project, we avoid excessive analysis. We know the risk of getting lost in the details is always lurking. Instead, we commit to looking at things from a higher perspective. We start by showing an interest in the potential client's business model and asking where they would like to go by working together. We then propose contract arrangements that do not limit the possibilities of change during the project: Agile contracts.

Agile contracts involve short work cycles (usually one to three weeks each) with a fixed cost. We set goals with the client for each cycle and work to achieve them. At the end of each iteration, we present what we have delivered and proceed with the next cycle. The client pays for the work after each iteration separately. If, for any reason, the collaboration fails to meet expectations, the client can express their concerns and use the available options (e.g., repeating the sprint at no additional cost or terminating the relationship without payment for the contested iteration).

A good contract fades into the background. It's a contract that the client and provider don't need to consider while they happily work together to reach their goal. Agile agreements focus on the value created rather than the time spent, have only a few simple rules, and build trust between everyone involved.

Before collaborating, we always run an exploratory workshop, which is helpful to uncover fit. Second, we put a great effort into assigning the best people for the job. Third, we try to be extremely transparent and realistic about things we don't know. For example, a client once asked for a feature, but we weren't sure about its technical feasibility. In that case, we shared our doubts about that and proposed to build a proof of concept before digging into the actual development.

The only crucial point that requires special attention is ensuring alignment with the client in the event that we approach the target budget and there are still features to be done. It must be explained well that the client can keep the budget fixed by reducing the scope (which means building less) or extending the scope and the budget.

Selling projects with Agile contracts is like putting billing and payment on autopilot. The team can focus entirely on their work. However, there are a couple of things to consider. First, there is a significant responsibility toward the client. You need to put the right people on the project and shield them from external distractions. Second, if the client is not already accustomed to this approach, they might have some doubts or concerns.

We use agile contracts to help the client manage risk consciously. The last thing we want is for them to feel uncomfortable during collaboration. Betraying a client's trust and making them feel they were mistaken in relying on us is simply unacceptable.

Getting started with Agile Contracts

Initially, to sell Agile projects, we offered a free one-day workshop to introduce the client to our way of working. We worked with short, one-week iterations. This approach was quite demanding for us due to frequent revisions, but it gave the client the necessary control and the ability to halt at any time.

Over time, we refined our sprints, and our track record gained the trust of clients. Now, iterations last two or three weeks, allowing the team enough time to work on substantial tasks at the right level. This maintains an excellent relationship with the client through discussion moments that can be scheduled within the sprint, not just at its conclusion.