Squads

Let’s start with squads. These are comparable to a Scrum team and form the basis of the Spotify model. Squads are self-organized agile teams that include all the resources it takes to develop a product or service from start to finish. Of course, each of these teams also has a product owner who is responsible for the backlog and prioritization. In addition, each squad has an agile coach to provide methodological support to the team and organize events such as retrospective or planning.

Tribes

A tribe comprises several squads that work together on a product or service. There is a so-called tribe lead who ensures that the squads can work together in the best possible way. There are regular meetings where the squads can exchange ideas and present their work so that everyone is up to date.

Chapters

A chapter includes employees with the same expertise. These are distributed among the different squads within a tribe. Chapters also have a chapter lead, who organizes regular meetings to enable an exchange among each other.

Guilds

Guilds are gatherings of people with the same skills or interests from different tribes. The so-called guild coordinator takes care that meetings take place where the members of the guilds can exchange information. This has a great advantage for the improvement of the organization.

Summary

To recap: Under the Spotify model, an organization is divided into tribes, which are responsible for developing a product or service. Within a tribe, members with different expertise (squads) are brought together to independently develop a product or service. In addition, members with the same expertise are brought together, both within a tribe (chapters) and across tribes (guilds) for experience sharing and further development.

Unlike what we know from frameworks such as Scrum, there are no practices that must be followed or mandatory meetings that must be held. Squads self-organize how they best get their work done. This can happen through the use of the Scrum framework, Kanban, or other methods.

Likewise, chapters and guilds determine for themselves how they want to best organize their collaboration.

Now you can confidently answer yes to the question if you are familiar with the Spotify model.

Let’s start from the beginning, what is Kanban anyway, and how did it come about?

The inventor of the Toyota production system, Taiichi Ohno, developed Kanban in 1947, and it is an implementation of the control method in production known as the pull principle.

He was inspired by the process of filling shelves in supermarkets. This is because supermarkets stock just enough products to satisfy consumer demand. The stock levels match the consumer habits of the customers. This avoids storing excess goods and occupying space for goods that are needed. It is simple and leads to great efficiency in inventory management.

So, Taiichi Ohno adopted this process in Toyota production. The cycle begins with the delivery of the required materials, including the kanban card, to the consuming location. As soon as the materials have been used up, the kanban card is returned to the responsible supplying point. Here, the production or procurement of the required materials in the specified quantity begins and as soon as this has been achieved, the materials are sent back to the consuming point, including the kanban card. You then have a self-controlling control loop without a central planning instance.

The technology used in this system has of course evolved in recent years, but it still forms the core of what is known as just-in-time production.

How is Kanban applied in software development today?

In principle, the Kanban method can be used in any industry due to its timeless core principles, which are explained in detail below. In the area of software development however, the agile method was particularly successful, because here no expenditures for the conversion are necessary like for example the change of physical processes. All that is needed is a board with cards, which can certainly be mapped virtually.

By the way, the word Kanban comes from Japanese and literally means ‘visual signal.’

It is not without reason that Kanban is one of the most widespread agile management methods alongside Scrum. However, in order for the agile method to work properly, it takes a bit more than just a board and cards.

The Kanban board is of course in the center. It is there to visualize the tasks and to optimize the workflow of the team. A simple Kanban board consists of the three steps To do, Doing, and Done. Depending on the size, structure and goals of a team, the workflow can be extended or adapted accordingly. The Kanban cards map the tasks to be completed, and their progress is transparently mapped on the board. The Kanban cards provide information on the type of task, who is responsible for the task, how long it is estimated to take, etc.

Now that we understand what the principles behind Kanban are, let’s look at the six practices that help us achieve great success with the Kanban method.

1. Make the work visible
   To visualize the work, workflow and risks, the Kanban board is used. The work is represented by the cards on the board, the workflow is described by the columns from left to right, and the risks can often be seen in the detail of the cards, but often also visually, such as too many tickets in the “Doing” column.
2. Limit the work-in-progress (WIP).
   Limiting the WIP means that there is never too much work and never too little, so that exactly the right number of cards can be processed by the available resources. This is achieved through the pull principle, where new work is drawn only when sufficient capacity is available. For this to work, the WIP limit must be set and adjusted.
3. Manage flow
   Flow means the movement of work through the workflow from left to right. The project manager is responsible for ensuring a fast flow while keeping an eye on blockages and risks. The better the flow, the more efficiently the team works.
4. Make process rules explicit
   In order for everyone to be looking in the same direction and for discussions to be rational and objective, guidelines are needed. These need to be documented and shared with everyone.
5. Introduce feedback loops
   Feedback and continuous improvement are crucial in Kanban, as in all other agile frameworks. In the Kanban method, the meeting cadences you have set for yourselves are suitable for this. The only mandatory meeting is the Daily Kanban. Here it is a matter of taking a daily look at the flow and recognizing blockages and obstacles and clearing them out of the way. Other meetings, such as Refinements, Retrospective, Planning, or Review are scheduled as needed.
6. Improve collaboratively, evolve experimentally
   In Kanban, collaboration and experimentation go hand in hand as long as there is clarity and consensus on how to approach work and problems.

So, start right where you are, pay attention to the principles, apply the practices, and tell me about your successes!

The role and limits of the Product Owner

The PO is responsible for maximizing the value of the product and represents the product vision. In general this person is located on the side of the commissioning company, while the Scrum Master and development team can also be part of the service provider. In his position, the PO is responsible for communication with the stakeholders and the technical coordination of the development team. One of the most important tasks is the preparation of the product backlog to ensure that it is in a usable state at all times.

In theory, that sounds like a manageable amount of work (spoiler: it’s a hell of a lot of work). On top of that, in an ideal world….

• POs are available 100% of their working hours towards the project.
• POs speak the „language” of the developers.
• it’s not the first development project as a PO and he has experience with software development.
• POs should have appropriate status, reputation and trust within the customer organization – ideally the PO is in charge of the product.

Unfortunately, reality often turns out to be different and the PO provided by the customer is not able to fully serve the role. There are many possible reasons for this:

• POs often don’t have the time to answer urgent questions from the development team and provide feedback.
• POs are competent in the technical field. However, it’s difficult for them to communicate what they want. They have less experience with prioritization and, in the worst case, do not know what is required.
• The title „Product Owner” is often assigned lightly when a project is due – mostly additional to the actual tasks of the person and/or without the option of further training.
• The Product Owner has little organizational support (or believes he or she has none).

The effects caused by a less than ideal PO setup are numerous: time pressure right at the start of the project, additional workload for the development team, as well as unclear responsibilities and a lack of product vision.

Therefore, reality often differs from those ideal conditions. This is why the Scrum Guide explicitly acknowledges this circumstance: The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

This is where the Proxy PO gets involved.

What is a Proxy PO and how can he be of service

The term „proxy” comes from the Latin term “proximus” and means “the next one”, which already suggests the role of the Proxy PO: A Proxy Product Owner stands between those who make decisions about a product and those who develop the product. He is considered an incomplete version of the Product Owner.

A Proxy PO typically takes care of activities that are normally done by a PO. These include:

• capture the needs of the customer
• creating user stories
• Ddfinition and prioritization of the backlog
• planning the implementation of backlog items (together with the team)
• deciding when to release increments to customers

In short: With the help of the Proxy Product Owner, the Product Owner’s workload can be reduced and the workflow improved. In the best case, the Proxy PO acts as a team with the Product Owner. However, it is important to note that the Proxy PO is not a second PO!

The Proxy PO…

• is not the owner of the product. He neither makes the main decisions about the product nor is he really responsible for its success.
• does not control the product budget.
• does not define the vision or strategy of the product.
• does not have the final decision about the backlog and its items.

Thus, it has to be clear internally (and externally) when to address the „original“ and when to address the proxy, and how long the stand-in will last (short-term or permanent, temporary and situational, or continuous).

Another possible scenario besides a „substitution“ of the PO by the Proxy Product Owner is PO coaching. Here, the Proxy PO provides support in terms of consulting, especially with regard to methodological issues. PO coaching is especially helpful when the Product Owner has enough time for the role, expertise and a clear vision for the product, but too little experience with the tasks of a PO itself.

How to decide if a Proxy PO can support your project

Establishing a Proxy PO in the project can bring significant advantages for agile software development. Product development can be improved in a complex environment, the Proxy PO can contribute his skills, and the PO can expand his skills.

Nevertheless, we recommend that you do not „blindly“ rely on a Proxy PO. Instead, the first priority should always be a joint discussion between the customer and the service provider. The following questions should be covered:

• Which tasks in the area of product ownership must be fulfilled in the process of product development for the project to be successful?
• To what extent can the customer meet these expectations – both in terms of capability and the availability of his PO?
• If gaps are to be expected, it is recommended to define what form of support is to be provided. Here, the Proxy PO can be an answer.
• At the start of the project, roles, responsibilities and expectations should be discussed and documented.
• To ensure that the agreements are being fulfilled as expected, they should be checked regularly during the course of the project.

Our teams highly appreciate this approach in our projects and thus ensure the success of our customers. We are committed to the agile way of working and are happy to put together the right team for your technical challenge.