#31 The Problem Team Member

Symptom: There is at least one team member that is disruptive to the rest of the team. This could point to performance related issues, non-engagement with the rest of the team or just plain disruptive.

Probable Cause: In most cases there is usually some underlying reasons for the exhibited behaviour. Sometimes, the behaviour can originate from some insecurities about using agile for example, or may be something else completely.

Suggested Resolution: Sometimes teams can over simplify the issues with disruptive people on the team, where they can seem to "gang up" on an individual and seek their removal from the team. This may provide benefits for the project, but what about the individual?

Before any rash decisions are made, it may be worth finding out what if any underlying issues are causing the person to be disruptive. A one on one conversation by the coffee machine or similar can be very revealing and may indicate those underlying reasons.

Try to approach the matter delicately and ask some leading questions about their take on the project and how things are going. Keep the conversation light and focus on listening to the individual and their reponses. The objective here is to really find out what factors may be causing them to be disruptive.

Usually, the underlying reasons can be quite straight forward and look to close the conversation with some objectives to remedy the underlying causes. In the case of insecurities about using agile for example, look to provide extra support and reassurance.

Only when every effort has been made to help the individual align with the team with no visible progress being made, only then, may it be appropriate to consider separating them from the team.

Very rarely would this be a permanent solution, as the individual may well be able to rejoin the team at a later point in time if they are able to participate effectively.

Adopting agile practices can be very difficult for some people, as it requires them to change their behaviour, become more accountable and sometimes they can feel more exposed as a result.

So spare a thought for a struggling team member and help them out.

What you are looking for here is a team that can be self healing and self supporting, and which takes care of its members.

It can be easy to discount under performing members of a team when viewing their actions at face value, but you have to remember that they are only human and may be reacting to any number of underlying factors; and that ultimately, they are still part of your team.

For more agile coaching options, check out agile coaching

#30 Skillset Based Flow

Symptom: Tasks during a sprint are skill set based such as "development" tasks or "testing" tasks for example. Often with large estimates that hide what work is to be done by the task even if placed on a scrum board.

Probable Cause: The team may still be thinking in silos in terms of who can do the tasks and with what skill set; a developer can only do "development" tasks or a tester can only do "testing" tasks for example. Rather than taking a more pragmatic approach and getting the work done by who ever is available in the team regardless of skill set.

Suggested Resolution: Try to use vertical swim lanes on the scrum board to represent "in analysis", "in development", "in testing", "in UAT" and "done" etc.

Fashion the taks to be feature or work based and they can then be placed in the corresponding swim lane to indicate what is happening with that piece of work at that time. A task to add a button on a web page that is currently in development can be placed in the "in development" swim lane for example. When it is being tested it could be moved to the "in testing" swim lane and so on.

Using tasks to represent features rather than skill sets to "flow" through the swim lanes in this way, will help the team to identify them as pieces of work to be completed by the sprint, and that the silo divisions between who is a developer, and who is a tester for example begin to blur and become irrelevant. (There may still be some specialist consultancy going on if some one knows more about testing a feature for example, but they do not necessarily have to do the work if they are busy on something else.)

What you are looking for here is a team that recognised that it is the visibility and completion of the work that is important and not who does it.

For more agile coaching options, check out agile coaching

#29 The One To One Daily Standup

Symptom: During the daily stand up each of the team provide their status to the scrum master rather than to the whole team and the scrum master feels that the team are not talking to each other.

Probable Cause: The team may still feel that they have to report to some senior figure such as a project manager for example. This usually happens in teams new to agile who have been previously exposed to a controlling style of management and mistakenly project the senior figure on to the scrum master role.

Suggested Resolution: As a scrum master try to avoid eye contact during the daily stand ups. It sounds simple, but it can have a dramatic effect when a team member is providing their update.

Most people like to have some sort of connection to others when they talk and breaking the eye contact between the scrum master and the team member providing the update usually encourages that team member to seek another connection, usually from other members of the team.

The net result is that the team member starts to provide their update to other members of the team. Done on a daily basis and the team will begin to learn that they can talk to each other in meetings rather than just to the facilitator.

What you are looking for here is a daily stand up that has everyone engaged and sharing relevant information.

For more agile coaching options, check out agile coaching