Five countries, one development team
How IT informa structured the Diaverum clinic platform project across Lund, Gothenburg, Munich, Denver and Hua Hin
The development team working on Diaverum’s clinic platform was spread across five countries simultaneously: project management and testing in Lund, business analysis in Denver, development in Gothenburg, a developer in Hua Hin, and the project sponsor and steering group in Munich. For a business-critical project with strict requirements on predictability, cost and delivery, this geography had to be managed deliberately.
The challenge
Most project models assume a degree of physical proximity. Stand-ups, whiteboard sessions and informal communication fill gaps that formal processes leave open. With a team distributed across multiple time zones and locations, those informal channels are not available. Every handover between roles had to be explicit, every decision traceable, and every team member’s workload visible to the rest of the group.
The risk in geographically distributed development is not that work stops. It is that work accumulates invisibly, priorities drift, and handovers between roles create delays that compound across the project.
The approach
IT informa structured the project around a Kanban workflow, implemented in an open-source issue and task management tool. The choice of Kanban was deliberate: its emphasis on visualising the flow of work between roles made handovers explicit in a way that was well-suited to a distributed team. Each development package moved visibly through the process, with defined steps from requirements through development, code review, test and delivery.
The tool became the central point for information flow across the team: to-do lists, time reporting, code review, documentation and traceability from business requirements through to individual code changes. A clear distinction was made between persistent information, stored in a shared document repository, and short-lived information, kept within individual backlog items. This kept the system from accumulating noise while ensuring nothing of consequence was lost.
Handovers between process stages were handled with short, focused calls involving all relevant parties for that development package. Documentation discipline was treated as a function of relevance: over-documentation was considered as problematic as under-documentation, and the team worked to keep only what was necessary.
A further benefit of the approach was full traceability from management decisions through to individual code changes. Strategic decisions were entered into the system and linked down through requirements to the functions they produced. Every line of code could be traced back to a management-level decision, and every function had a record of who had developed it, who had tested it, and how long that testing had taken. This traceability was possible because requirements had been structured as system properties from the outset rather than as a flat list of tasks (see Managing requirements as system properties).
When the clinic platform underwent an external audit, this traceability was immediately available. The team could demonstrate not just what the system did, but the full chain of decisions and verification activity behind each function.
The result
The process worked. At the most intensive point in the project, the team demonstrated what a well-structured distributed workflow can achieve: a defect affecting members across Lund, Denver, Gothenburg, Hua Hin and Munich was identified, analysed, developed, reviewed, tested and delivered in under two hours.
The Kanban workflow and issue management approach ranked as the highest-rated item in the project’s post-delivery retrospective, cited by developers and testers alike as a critical factor in creating a well-functioning environment where very little was lost or dropped.