Part III Development: keeping the project on track
Chapter 16: How development works and what is expected of you
The most common brake on a project is a customer who has no time: nobody else can work out what your software should do. For most companies and public authorities, a hybrid works: a fixed budget cap, stages that end with a “continue or not” decision, and agile development within them. On your side, there must be a product owner with a real mandate and time, in practice full-time for larger teams.
The difference is when you hear the bad news
With the waterfall approach, the whole system is first described, then developed, and finally handed over. You are most involved at the beginning and at the end, and a problem often only shows up at acceptance. The UK government’s guidance warns that this way you can spend 18 months building a service that no longer matches policy, technology, or user needs GDS, agile development.
With agile development, you see a piece of working software after every short cycle, roughly every 1–4 weeks. You uncover risks early, but you have to make decisions and try out the software on an ongoing basis.
| Waterfall | Agile | Hybrid (recommended) | |
|---|---|---|---|
| When risk shows up | late, often at acceptance | early | early, plus decisions at the end of stages |
| Your work | a lot at the beginning and at the end | ongoing, more in total | ongoing, plus decisions at the gates |
| Suitable for | stable requirements: an upgrade, a migration, an off-the-shelf product | a new service, unclear processes | most companies and public authorities |
| Typical trap | the requirements go out of date during development | “agile” without a product owner | long stages, gates only on paper |
Chapter 10 discusses the contract and pricing models for each approach.
Sprint, backlog, and Definition of Done
A sprint is a short development cycle, usually two weeks long, that ends with a demo of the finished work. The backlog is an ordered list of everything that needs to be done; your product owner decides the order. The Definition of Done is a shared agreement on when a task is really finished: tested, documented, and deployable.
Watch out for an agile label on a waterfall
The most common trap is “agile development” with a fixed two-hundred-page brief and a fixed price. Or an agile contract without a product owner on the customer’s side. The Czech adaptation of the guide by 18F, the US federal government’s digital team, says that when a vendor claims an agile approach but handles every change with an additional order, “a red light should go on in your head” Česko.Digital, 2022.
Agile development can be reconciled with a fixed contractual framework in four ways:
- fixed budget and deadline, variable scope,
- payment for time worked, with a cap,
- a fixed price for the MVP, further stages as options,
- payment per accepted increment that meets the Definition of Done.
Chapter 10 discusses which approach suits your project and how to set the price.
How much of your time it will take
The product owner should be your employee, not someone from the vendor Česko.Digital, 2022. They decide on priorities, answer questions, and accept finished parts. They are like a homeowner who visits the building site every day: when they are missing, the builders either wait or build as they see fit. Decision-making by committee and a product owner working “10% alongside their regular job” are typical brakes. A fixed price does not replace your own management: in the digital building permit system project, the contract had a fixed price and deadline, and yet, according to the legal part of the audit, the projects did not have some of the roles required by the ministry’s methodology filled DSŘ audit, legal part, 2025 (more in chapter 20).
Appoint the product owner before you sign the contract, confirm in writing how much of their time you will free up from other work for the project, and give them a mandate: what they decide on their own and what they must submit to the steering committee. Choose key users from the people who actually do the work, not from those who happen to have time.
The hours given are rough estimates based on a 40-hour week, not measurement results. For key users, they are per person, so the total load is several times higher.
Cooperation is an obligation, not goodwill. Write the roles, hours, and deadlines for your answers into the contract, and ask the vendor to keep a record of what it is waiting for from you. Also watch the stability of priorities: when they change every week, team productivity drops and the risk of burnout rises DORA, 2024.
From day one, you need access to the backlog, the code repository, and the test environment. Only then can you see the real state of things (chapter 17).
What the team needs from you in every sprint
An agile project is more a series of small decisions than one big one. In every sprint, you are expected to provide:
- an ordered backlog: what comes next and why,
- quick answers to questions, so the team does not have to wait,
- participation of the product owner and key users in the demo,
- acceptance of finished work, or a clear “not like this” with a reason,
- data, access, and people from other departments when the team needs them.
Larger projects are also divided into phases. The UK government calls them discovery, alpha, beta, and live: exploring the problem, testing the solution on prototypes, development for a limited and later a wider group of users, and finally production GDS, agile development. At the end of each phase, there is a decision on whether to continue. These are exactly the gates of the hybrid model.
| How it goes wrong | How to do it right |
|---|---|
| How it goes wrongA product owner working “10% alongside their regular job,” or one from the vendor. | How to do it rightYour employee with a mandate, in practice full-time for a team of 5–9 people. |
| How it goes wrongA committee decides; questions wait for weeks. | How to do it rightThe product owner decides within the limits of their mandate; the steering committee handles decisions beyond that. |
| How it goes wrong“Agile” with a fixed two-hundred-page brief and a fixed price. | How to do it rightHybrid: a budget cap, stages with a decision on whether to continue, variable scope. |
| How it goes wrongKey users show up for the first time at acceptance. | How to do it rightKey users attend demos from the first sprint. |
| How it goes wrongSecurity brought in a week before launch. | How to do it rightSecurity involved in the requirements from the analysis on; a penetration test planned. |
| How it goes wrongCooperation “as needed.” | How to do it rightRoles, hours, and response deadlines in the contract; waiting time is recorded. |
- You must choose the agile approach already in the procurement procedure. A company can stop ordering whenever it wants; a public authority is bound by the tender conditions.
- In 2026, the Office for the Protection of Competition (ÚOHS) confirmed that even information from a clarification of the tender documentation that performance “will be carried out in an agile way” is part of the tender conditions ÚOHS, S0028/2026. So write it clearly and in good time.
- You must reserve a fixed price for the MVP and further stages as options in the tender documentation (Section 100, Public Procurement Act – ZZVZ). Chapter 10 describes a framework agreement with multiple vendors.
- An external project manager does not replace a product owner from among the authority’s employees. Also involve the authorities responsible for the relevant legislation, because a change in the law changes the scope.