Split resources into Agile teams

Agile principles ask organizations to assign team members 100% of the time to one team. Ideally. This is not easy especially at the beginning of Agile transformations.

There are some roles that are not economically easy to have in every agile team even it makes sense to have such a role in the team.

And that might be a key. The question is if you need a role or capability in the team. The capability can be built by knowledge share increase. Such capability can be provided by any role in the team, whoever wants to help with it. Organizations used to even establish communities, chapters to support knowledge sharing.

Anyway, shared people is reality. Typically we see in companies people like architects, user experience designers, business analysts.

Capacity split approach

The first approach is to let them specify % of capacity they will invest into particular teams and let them check that %, adapt it based on plans and reality of teams they support. This approach has its cons as well. Shared team members will be asked to join multiple planning sessions, daily standups, reviews, and retrospectives.

Let people adapt how much and when they are really necessary. For example, they can join your daily standup once they started to work on the item from your sprint backlog. Of course, full transparency is expected from everybody.

scrumdesk capacity planner team leveling selforganization calculator agile scrum project management tool

Capacity Planer in ScrumDesk

In the case of shared people is even more important. Who assigns work to those people? Well, they pull a work based on priorities. Priorities that are agreed upon by product owners upfront, which are transparent after the release planning sessions.

ScrumDesk tool can help you manage capacities and level the team members capacities even in the case of multiple teams.

Team of Experts approach

Another approach is to organize such a team per expertise (UX design team), and let them manage their own sprint backlog, do standups, etc. This will require some product ownership and it will increase dependencies within the product development.

Choose your approach wisely

Which approach is better? It depends on your vision of the transformed organization, the current problems, and blockers. There is no easy answer to that question. Try some, inspect the results and adapt!