putting an end to silo mentality

shared knowledge and expertise facilitate mutual collaboration and innovation


on collaboration

Most collaborations between companies usually only take place within the framework of long existing project partnerships. Innovation is mainly understood as a company-specific, internal process. Fluxdock was created in order to change the silo mentality.

Read more

project workspaces

Working on a cross-company, collaborative and agile project during ongoing operations is a challenge. We have developed the Project Workspaces to create a distraction-free place for teams to focus on their innovation project.  

Find out more

the physical FLUXDOCK

The physical Fluxdock is located in the Dreispitz quarter of Münchenstein / Basel. On 1500 square meters of collaborative space companies from different branches work side by side and profit from the expertise of their neighbors.

Your workplace

how we work

Fluxdock makes Scrum, Design Thinking and agile project management accessible. We provide our clients easy-to-use tools and methods. Throughout the whole innovative process we are available with our experience and expertise. Still: some vocabulary is very helpful when working together on an agile project. So here are some explanations.


Product Owner (PO)

The Product Owner plays a central role in the project. He is the interface between the customer and the team. He conveys vision, goal and requirements of the project and is responsible for ensuring that the team understands and endorses them. He is responsible for the formulation of the "what" and the "why" (objectives, requirements and reasons for them). He prioritizes the requests, often in consultation with the team.  


The team consists of all professionals needed. It realizes the coordinated requirements in accordance with prioritization in demonstrative or productive increments (as part of products, concepts or information in general). The team is responsible for the "how" (e.g. technical solution, software framework, the way) of the implementation of requirements.  

Scrum Master (SM)

The Scrum Master designs the optimal process for the project, taking into account all conditions and always in consultation with the Product Owner and the team. He coaches the whole project team, settles any obstacles and optimizes the project process continuously.  




In the Planning, the Project Owner agrees with the team on the sprint goals. These form in the review at the end of the Sprint the basis for assessing the requirements. The selection of the highest priority requirements and the estimates of the workload to solve them form the Sprint Backlog. The team members decide how they want to implement the demanded requirements and discuss in the Planning the interdependencies and how they organize themselves in the Sprint.

At the end of the Planning all participants know to which sprint goals the team has committed, the form in which the results are to be presented, why the sprint goals are meaningful and which tasks must be fulfilled in order to achieve these goals.

Daily Scrum

The Daily Scrum is a daily meeting of the team with maximum duration of 15 minutes. Each team member answers the following questions:

1. What have I done since the last Daily Scrum?

2. How can I work until the next Daily Scrum?

3. Are there things that hinder me in the execution of my work?

The Daily Scrum is used to coordinate team members among themselves. Necessary consultations will be held with the necessary stakeholders afterwards. The Scrum Master moderates the Daily Scrum and takes care of the elimination of any obstacles.  


At the end of each Sprint, the team presents the results in the Review. The individual team members share their knowledge and experiences and present exclusively finished results.  

The team is oriented towards the following questions:  

1. What have we achieved?  

2. What have we not achieved and why not? (factual description of the reasons of non-achievement)  

3. What have we learned? (with respect to the product and its development)  

The Product Owner checks (ideally with the customer) whether the Sprint results correspond to his requirements. Findings are discussed together and possible amendments can be made as a basis for the next planning in the product backlog in the form of extensions, changes of priorities or by removing elements.  

The Review is organized by the team and moderated by the Scrum Master.


In the Retrospective the past work process is considered with the team. In this meeting the team and the Scrum Master reflect reflects on the process, collaboration in the team and with the Product Owner and other stakeholders. Improvement measures are prioritized and assigned to a responsible (person, team or organization) to be implemented as early as possible.. The findings and improvement measures that affect the team itself will be implemented directly in the next Sprint.                 

The aim is to shed light on the past Sprint and learn from it in order to make the upcoming Sprint more efficient.  

The Retrospective takes place after the Review at the end of each Sprint.  

The Scrum Master prepares the Retrospective and moderates it.  

The retrospective is based on the following questions:  

1. What went well?  

2. What have we learned?  

3. What do we want to do better next time?  

4. Who is responsible for measures of improvement?


Product Backlog

The Product Backlog is the list of requirements of the customer. This list is continuously updated by the Product Owner in close cooperation with the customer, reviewed and re-prioritized. The Product Backlog is the basis for the implementation of the project and describes what is to be implemented by the team. It is not a closed document and changes as the project progresses. At regular intervals, the elements of the Product Backlog are evaluated and re-prioritized. Existing elements can be removed and new ones can be added. High-priority requirements are described in great detail in contrast to low priority requirements and thus serve the team as a basis for creating the Sprint Backlog. Thus the Product Backlog is not a to-do list, which is processed in every case, but provides a pool of requirements that are processed in order of priority, as long as the time or financial resources are available.  

In summary, this means:  

  •  The Product Backlog contains all the requirements of the client with regards to the project target.  
  •  The requirements are prioritized according to criteria such as ROI, risk and overall importance.  
  •  Ideally the requirements give information on the “what”, the purpose and its target audience.  
  •  The Product Backlog is managed by the Product Owner in digital form.

Sprint Backlog

The Sprint Backlog is prepared by the Product Owner in a first version and discussed within the planning with the team. The team complements the individual requirements with specific tasks that lead to fulfill the request. The Sprint Backlog is thus a refinement of the Product Backlog and contains all tasks that are necessary to fulfill the Sprint goals. In the planning only as many tasks are planned as the team can handle, because the team commits to the execution of these requirements.  

In summary, this means:  

  •  The Sprint Backlog is the refinement of the Product Backlog.  
  •  The Product Owner prepares a first version of the Sprint Backlog for the Planning.  
  •  The team discusses the tasks in the Sprint Backlog and accomplishes them during the Sprint.  

For the organization and the follow-up of tasks from the Sprint Backlog, the team uses a task board (digital or physical).


valentin spiess | the interview

In this 23-minute interview, the initiator of the collaborative platform Fluxdock talks about agile methods, Fluxdock and his working philosophy.

The whole interview is in German though. If enough people complain, we will do our best to get it translated. 

the team

Jonas Gschwind, office management at Fluxdock AG

Jonas Gschwind | Studio Management

Jonas is responsible for studio and project management. A trained carpenter, he studied process design in Basel and cultural management in Lucerne. Co-founder and co-leader of Parzelle403.

Christian Hansen, concept and communication at Fluxdock AG

Joël Pregger | Assistant Studio Manager

Joël Pregger is a community developer, organizer and entrepreneur. Joël manages various projects for children and teenagers and also supports Jonas with studio and office management at Fluxdock AG.

Elias H. Schaefer, CEO of Fluxdock AG

Elias H. Schäfer | Board of directors

Elias studied International Relations in St.Gallen and Geneva. From 2012 to 2014 he sat in the Grand Council of the City of Basel. His experience as a representative and his wide network make him the ideal collaborative entrepreneur. Elias was the managing director of Fluxdock AG between 2015 and 2019.


come visit us 

The Dreispitz is Basel's largest commercial and service area. And with around 50 ha and several hundred established companies probably also one of the most confusing areas when you visit for the first time.  

So in order to make sure you find us, we created a small travel tutorial. We are looking forward to serving you  a coffee and showing you around.

Find us on Maps        or        Find us at Dreispitz