Building an agile programme while it grows

There is an almost unlimited range of models and frameworks to help modern initiatives succeed, but none of them will make decisions for you when things take an unexpected turn. Success comes from people working together and from how well the structures support their expertise and leadership.

A persistent lack of clarity challenges initiatives from several directions. Internally, critical points that may be unclear include responsibilities, prioritisation or who decides what. Externally, a lack of clarity comes from suppliers, stakeholder expectations and changes in the operating environment beyond your control. A single unclear point is rarely a problem, but they compound.

Good problems add to the lack of clarity too, and one of them is an initiative’s growth. When a successful project expands into several projects and eventually a programme, the old ways of working are no longer enough, and the larger undertaking needs a new way to operate. This is precisely when complexity grows faster than the structures supporting it, and without deliberately established management practices, the situation quickly becomes unmanageable.

How, then, do you build new structures that work? Let us explore a sound approach through a fictional case study. This is not an account of any individual client engagement.

The starting point: three reasons for change

Take a medium-sized retail chain that decides to modernise the back-end systems supporting its e-commerce and warehouse management. Behind this is a strong desire to embed AI firmly in the business and seek a real competitive advantage through it. The old ERP is built around a single external product and its vendor, and this arrangement creates three problems.

The first is dependency. Every change goes through the vendor, and there are no alternatives. This is the infamous vendor lock-in, a situation that offers the customer no benefit and increases risks the business cannot control.

The second is slowness: requests for changes queue up, and timelines stretch into months. At worst, the vendor delivers a release only twice a year. And often, the changes people need are not even selected for the release, leading to yet more waiting.

The third is inflexibility. The existing system cannot keep pace with how quickly AI-assisted tools are changing both the customer experience and internal processes. This is out of step with the business’s needs and puts its strategy at risk.

It is time for a change.

The first project is set up to assess the starting point and lay the foundations. This takes the form of a concrete, tightly scoped project to replace one specific part of the ERP’s functionality. Once the foundations are in place, the initiative expands into five parallel projects over roughly eight months. Teams from different suppliers join, each with different priorities, yet the aim remains one shared direction.

When the projects took on a life of their own

Natural growth first shows up as fragmentation. Each project follows its own logic, as though five separate initiatives happened to share the same budget line.

Each team uses AI in its own way. One automates testing, another experiments with AI-assisted code reviews, and a third has not had time to consider it at all. When one project solves a difficult technical problem, the information does not travel, and another team may solve the same problem again a month later. Meanwhile, the number of meetings grows, especially for key people, as each initiative wants answers to its individual questions.

No one manages dependencies across the whole programme. Risks are assessed only from each project’s perspective, so a programme-level risk surfaces only when it is already a problem for several teams at once.

A shared rhythm does not emerge on its own

The solution is not one big process but a few lightweight, recurring practices that together give the programme a backbone.

One of the first new practices is increment planning. Monthly planning brings all the projects around the same table to agree on the shared direction and objectives for the cycle rather than the finer details. The aim is to build cohesion across the projects and show how each piece makes a meaningful contribution to the month’s objective. From there, it is easy for each team to break off and plan its own project in more detail.

The weekly architecture meeting brings each project’s lead developer and the programme’s chief architect into the same discussion every week. Dependencies and technical conflicts surface before they can become obstacles, and each project stays up to date with what the others are doing. This planning happens well in advance, so that future plans can move forward with obstacles already cleared and questions answered.

All documentation, including the notes from the weekly architecture meeting, is collected in a shared wiki. AI-assisted search and summaries are added, so no one has to dig through five different places for information any more. All information is available to everyone at all times and, above all, is easy to search and accessible to AI. The same applies to every project’s plans and specifications.

A new shared demo session is introduced at the end of each increment. In this demo, all projects present their work at the same event. This condenses the schedule and builds cohesion across the programme. Openness is another objective: anyone can easily see how the others are progressing. The aim is to keep showing, through concrete examples, what each project has achieved in its own part of the work.

Pre-refinement makes the biggest difference to day-to-day work. A small core group from each project — the lead developer, Product Owner and a testing representative — resolves obstacles together before the planning session. Without this, planning meetings drag on and are ineffective. Now, the larger group discusses only what actually requires a joint decision.

Monthly planning sets the direction, pre-refinement clears obstacles, and all teams work in two-week sprints. The demo closes the cycle, while the weekly architecture meeting and wiki keep information flowing throughout.

Compromises, not perfection

Teams from different suppliers bring their own ways of working, but the programme makes a deliberate choice: everyone follows the same approach. From the outset, all teams work in two-week sprints, and the shared rhythm is built around them.

A consistent sprint rhythm makes shared reference points possible. Monthly planning, the weekly architecture meeting and the demo fall at the same points for everyone, so no one needs to fit their own schedule around anyone else’s. In return, teams have less room to manoeuvre: everyone must adapt to the same pace.

The first monthly planning session reveals that inviting everyone does not work: it becomes a listening exercise in which most people wait for their turn. Attendance is restricted to key roles, and the details move into pre-refinement. The shared demo is initially too long because every project presents everything. After that, only completed work and changes are shown.

The rhythm is not a finished model but a compromise that needs continuous adjustment. Every practice gets a chance to demonstrate its value, and any practice that does not reduce friction is dropped.

The programme level sets the direction, brings dependencies together and makes completed work visible. Projects deliver the work in two-week sprints, and the wiki keeps information available to everyone.

Key takeaways

The structure takes shape in a few months. Time is limited, forcing a choice of good enough over perfect: lightweight monthly planning before a heavyweight portfolio tool, a wiki before a perfect information system, and pre-refinement before a formal process model.

The benefits show up in day-to-day work. A shared direction guides all projects towards the same objective, and dependencies and risks surface early. Solutions and information travel between projects, so the same problem is not solved twice. Specialists have more time for the work itself when shared meetings focus only on what requires a joint decision. The programme’s status is also visible to everyone, and the shared information base gives AI a solid foundation from which to help.

Structure can be introduced into a programme in small steps, with substantial benefits: work becomes more efficient and more meaningful. There is no single right approach or process, but among the many possibilities, everyone is sure to find a way that suits them. If you would like to talk more about this topic and discuss your own experiences or needs, please get in touch. I would be happy to continue the conversation.

Teemu Sevon