Co-development teams

In our software development projects we work with project teams. Depending on the type and size of the project, a team is put together based on the specific technical knowledge and skills of the developers. Often a team consists entirely of developers from Ibuildings, but we also work in co-development teams where, in addition to developers from Ibuildings, the client’s own developers also work on the project.

In such a co-development project it is necessary to pay extra attention to a good foundation for the project. In addition to an introduction to the tools Ibuildings uses in software development projects, there must also be agreement on the working method underlying the project. In other words, make sure that we as a team speak the same language.

For this purpose we organize a kick-off workshop with all participants of the project. The objective is to create a common support base within the development team. This increases effectiveness and results in an environment in which changes can be translated into results faster.

Which topics will be discussed during this workshop:

Using the same language

At Ibuildings we embrace the principles of Agile development, but we are fully aware that ultimately it is the customer who should feel comfortable with the chosen development methodology. So in the first instance it is about convincing and, based on our practical experience and examples, explaining why a methodology or parts of it can contribute to a positive project result.

Within the Agile methodology, we often choose Scrum as the main methodology. Scrum embraces change during a project, giving you better opportunities to make adjustments during development, while keeping a grip on costs and lead time.

Scrum defines different roles; the Product Owner, the Development Team, the Scrum Master and the Stakeholders. In addition, we distinguish different elements that support the process; Sprints, Backlog, Stories, Restrospective, Sprint schedules, etc. The workshop discusses in detail what these roles and elements are and why it is so important to keep using them consistently and well.

Based on the wishes of the customer, another method can of course also be chosen as a basis. The most important thing is that during the kick-off it becomes clear which roles and elements there are and what the common definition is.

Practical assignment

The most important part of the workshop is of course the practical exercise. The developers are divided into teams and they will iteratively develop a product. Each team appoints a Scrum Master who discusses with the Product Owner what needs to be made in the sprint. We do this with lego cubes and the assignment is to develop an ‘animal’. We do this in a number of sprints with the roles Scrum Master and Product Owner but also with the elements Sprint, Stories and Backlog. The goal is to add new features to each sprint until the product for the Product Owners is finished at the third sprint.

Scheduling Poker

After a brief explanation about Planning Poker, we also put this part into practice with various exercises. Different teams are put together and the assignment is to make an estimation for building a conservatory. In preparation, a number of stories are made, a small functional design and a number of technical specifications.
This exercise always provides more than enough discussion about measuring complexity within a team. The ultimate goal, of course, is to arrive at a discussion about the content and vision of the work among the individual team members.

Putting it into practice

It goes without saying that every organization is different. And change takes time. As a final part of the workshop, we also explicitly consider this. What do you expect to encounter when changing your own organisation? And in the collaboration with Ibuildings? What are the things you want to focus on as a developer?

After the workshop we will start working on the development project. In the first weeks, the attention for speaking the same language together remains very important. Both the Ibuildings developers and the client’s developers have made so many implicit work arrangements over the course of time that misunderstandings quickly arise.
The Scrum Master has to stay very alert to this and keep giving attention at stand-up meetings or Retrospectives.