The joint implementation of software, products or services
A development team is a group of people who together implement a software, a product, in some cases also a service.
Development teams often consist of employees of a company. In the case of cooperations or joint ventures, they can also come from different organisations.
How a development team is structured and how it works together depends on the context. Some organisations choose so-called “rich” process models such as V-Modell XT, others use smaller, more agile frameworks such as Scrum, for example, and others combine methods, process models or workflows to create hybrid working methods. In short, organisations have to decide which procedure and, consequently, which mindset fits their development and their development team.
The Development Team in V-Modell XT
The German V-Modell XT defines numerous roles within a development, such as
- hardware architect, hardware developer, software architect and software developer,
- configuration management administrator and configuration management manager,
- logistics developer, system architect, system integrator and auditor.
For each role, there is a formal role description that covers a maximum of five points:
- tasks and authority,
- skill profile,
- role assignment,
- accountability and
To enable smaller projects and developments to be carried out with V-Modell XT, employees may assume more than one role, provided there is no conflict of interest.
The Development Team in Scrum
Scrum, on the other hand, has long since abandoned the distinction of roles in the development team. The Scrum Guide 2020 even goes one step further and replaces the term role with accountability. Accountabilities are divided into three groups:
- Scrum Master,
- Product Owner and
So instead of development team, “only” developers are spoken of. The idea behind this is that the terms in Scrum are not job descriptions, but rather a minimum of responsibilities that are necessary to carry out Scrum.
Scrum has no hierarchy, neither between the accountabilities (Scrum Master, Product Owner and Developers), nor between the developers. This has two main goals: Decisions should be made on the basis of professional criteria. And the responsibility lies with the team and not with individual team members. The accountabilities that developers assume in Scrum are clearly described. “The Developers are always accountable for:
- Creating a plan for the Sprint, the Sprint Backlog;
- Instilling quality by adhering to a Definition of Done;
- Adapting their plan each day toward the Sprint Goal; and,
- Holding each other accountable as professionals”.
In practice, this leads to the following tasks for developers or development teams:
- assess the feasibility and effort of Backlog Items in Sprint Planning, decide on the scope of the sprint backlog and commit to a common sprint goal.
- produce a potentially deliverable Increment at the end of each sprint – in line with the Definition of Done.
- exchange information in the Daily Scrum about the progress of the sprint among themselves as well as with the Scrum Master and the Product Owner, if applicable. The sprint goal serves as an orientation. Obstacles – the so-called Impediments – on the way to the sprint goal are communicated and ideally (if necessary with the help of the Scrum Master) removed.
- present the realised backlog items or the increment in the Sprint Review.
- in the Retrospective try to optimise the common approach for the next Sprint.
Even though Scrum does not define explicit roles for the development team, ideally the team members have different skills and knowledge. The performance of the team depends largely on the combination of these skills. If an employee does not have the required knowledge, the team as a whole is challenged to support him or her in their work and to expand their skills. The sprint goal can only be achieved together.
Impulse to discuss:
Can development teams develop efficiently if they work with different frameworks depending on the project?
Already in the Scrum Guide version of November 2017 it was made clear that Scrum is not only suitable for software development but also for product development in general. Thus Scrum addressed the same objects – software, hardware, systems – as the V-Modell XT. The main difference was the self-organization and personal responsibility of the Scrum development team and an ideally associated agile mindset. Even if the Scrum Guide 2020 speaks of self-management instead of self-organisation and turns the development team into developers, nothing changes in the corresponding orientation.
Here you can find additional information from our blog: