Developing business critical system with a team spread all over the world

Diaverum (iii)

Diaverum runs clinics in 14 countries, and requested a business critical system that would manage a team where the members are located far away from each other.


The assignment required the following questions to be answered:

  • How can we track time and follow up the cost per project member per software module and more?
  • How can we follow the flow of issues through the Kanban process?
  • How many issues are currently open on the requirements team, development team, test team, etc.?
  • How can we document decisions and create traceability to their consequences?
  • How can we guarantee traceability from requirements via development to test activities?
  • How can we maintain worklists in a team where the members are located in many different places far away from each other?
  • How can we notify members in the distributed team that a task has been added to their worklist?

There are quite a few project models and methodologies focused on a predictable delivery, but only a few, if any, of them works well with a geographically spread team.

One of Kanbans very interesting aspects is the flow of work between different roles in the project. This adds some benefits in a distributed development organization where handover between roles need to follow each development package. It also clarifies the need to be specific concerning relevant documentation. Over-documentation is as bad as missing documentation and relevance is of course very important to minimize time spent on short-lived information.


We defined our Kanban v1 process in an open-source tool named Redmine. The first version was up and running within a day of the process adaptation workshop and has been improved continuously since then.

Short phone meetings where used in handover from one process stage to another with participants from all interested parties in that development package. All relevant documentation used where either in document repository for persistent information, or in the Redmine Backlog item for all short-lived information.

Redmine became the focal point for most of the information flow in the team. Most areas where covered by to-do lists, time reporting, code review, and linking code change all the way back to the business requirements. One of the critical success factors was the transparency where all members of the team where able to track the progress and participate in the project.

Business critical projects must be predictable in terms of cost, time and result

With our knowledge, experience and skills we make a difference. That is why we do deliver more than expected. 


The geographical aspect of a project can lead to very positive but not always anticipated effects. During the most hectic part of the project we were present in Lund (project manager and test team), Denver Colorado (business analyst), Gothenburg (developers), Hua Hin Thailand (developer) and Munich (project sponsor and steering group). The most famous change was a defect that affected most of those cities, which took less than two hours from start to end including decisions, BA work, development, code review, test and delivery.