Team Methods – Teams in Scaled Environment, Part 3

Scrum/XP as a basis Teams typically use a solid implementation of Scrum as a mainstay and deliver valuable software after each sprint, which is usually…

Scrum/XP as a basis

Teams typically use a solid implementation of Scrum as a mainstay and deliver valuable software after each sprint, which is usually every two weeks.

They use the roles defined in Scrum: the product owner represents the authority over the user stories to be implemented. The Scrum Master drives the continuous improvement process at the team level and works to remove obstacles. The team members work together to realize the software. They are specialists and at the same time generalists who can also help out outside their area of expertise if necessary.

In Scrum, it has been found that teams have a hard time using adequate agile software techniques and have a hard time delivering on the promise of flexible changeable software in sprint cycles. These agile software techniques come from Extreme Programming and are usually an integral part of Scrum implementation.

Teams in Kanban mode

Some teams find it easier to think of themselves as Kanban teams when much of their work is event-driven defined. These can be teams with a high proportion of maintenance work, but most importantly, systems teams and DevOps have a mix of tasks that suggests the use of Kanban.

The advantage of Kanban over Scrum can be a faster response time for new requirements and a lower planning overhead. Kanban also makes greater use of metrics to improve and assess the team’s work. In particular, the cumulative flow diagram (CFD) very quickly shows the development of a team’s value creation and, if applicable, the development of the team’s value. a WIP limit that is too high.

On the other hand, Kanban teams are subject to similar restrictions as Scrum teams in order to work effectively in a release train:

  • Kanban teams have the same code quality requirements
  • You need an equivalent to the product owner to bring about quick, decentralized decisions
  • Make the same commitment to release targets and manage dependencies with other teams
  • Participate in release planning, other meetings, and associated planning and estimating, working on the same release schedule

In a release train, Scrum and Kanban-based teams can coexist with these boundary conditions and each use the form of work that is best for them.

Leave a Comment

Scroll to Top