In theory it is simple. You form a cross-functional team, you set it up with a visual, prioritized backlog, and away you go on your journey towards agile.
In theory, your team can handle anything you throw into the backlog. The team is a software factory that churns out quality code with regular intervals and everybody in the team is happy with their new role as a team member.
Theory – meet Reality. Reality – this is Theory, that I’ve told you so much about.
In reality, all team members cannot – because of skill set or experience or role (or even, in some cases, their long term career plan) – handle (and not even contribute to the completion of) the work items that goes into the backlog. Regardless of the reason, I call this the Backlog-Team-Incompatibility (BTI).
There might be several causes for the BTI to occur – perhaps the team was originally formed for some other purpose, or the team has members with some competence that is no longer required – but it does not matter. Somehow, the BTI must be handled, and sooner rather than later.
The short time span
Depending on the team, it might be the scrum master or the team members themselves that becomes aware of the BTI. A team member suddenly has no more suitable tasks, and the new tasks on the board are simply not a good fit. Do not worry! This happens to all teams, all the time. Take this as an opportunity to pair program, learn new things, share knowledge, work on that system documentation, set up a build server or test routine or something else that the team will benefit from.
The average time span
If a team member consistenly is suffering from BTI, and the team feel that they have exhausted their possibilities of resolving this situation, the product owner must be notified. Perhaps there might be suitable tasks with currently a lower priority that could be worked on? It is in the best interest of both the team and the product owner to keep the team both intact and productive, and if that means that the team temporarily does not completely work on the highest priority items, the trade-off might be worth it.
The slightly longer time span
If the BTI persists over time, the issue must be brought to the team member’s manager. Remember, it is not because the team member lacks
competence he or she lacks suitable tasks – it is just a ”case of BTI”. Again, it is usually preferrably if a solution can be found without making changes to the team. Perhaps the team member can use training or coaching to find suitable tasks.
The longer time span
If the BTI still exists over a longer period of time, the team member’s manager must take action, and remove the team member from the team. Again, it is not anyone’s fault – it is just an incompatibility.
A final word
It is important that the issue is discussed early with the product owner and the manager – exactly when depends on your situation, the severity of the BTI and the economy of the project (for how long can you afford to not utilize every team member?). The team or the scrum master can and should try to solve a BTI by themselves, but this might prove to be very difficult. And if the BTI is not resolved, the delivery, the team, and the team member will all suffer.