When you know you aren’t aligned, resolve early.

When you notice you aren't aligned and realise that will cause problems in the future, resolve them with the team early.

Lack of alignment does not disappear or resolve itself automatically, it takes communication. The longer it takes for that communication to happen, the more conflict is created and the slower the team runs.

Why?

We handle disagreements early because it's more expensive to resolve issues later, both in time, the energy required to resolve and team happiness is reduced if there is more conflict.

When to apply?

• When you know or feel that the team may object to your implementation.
• When you don't know how others are thinking. You haven't fully understood what your team members may think.

When not to apply?

If you haven't developed a good understanding of what you think or haven't developed ideas far enough, or if your proposal isn't compelling/valuable enough versus the alternatives. For example, you may feel that you will be unaligned on something you are building but aren't clear about what it might look like, yet. You'll know this to be true when you can't articulate the what and the why of what you are doing.

Rules of engagement as a leader:

• Not everyone must be 100% aligned, but an overall majority is important. It is helpful to use principles to back up decision-making so others can fully understand and help convince them. If the rejecting parties do not have rational counter principles, they will be unlikely to be able to change minds. Allow the rejecting party to go away and gather their thoughts if time allows.
• If the lack of alignment tends to be the same group of people each time, a leader should find out the reasons for this to help them find a solution. There are many reasons this could be the case; some include: A need isn't being met, the dynamics in the group have split and team-building efforts are required.
• If someone is not spending time to align and uses a process - such as code review - to force their views. You can always use a secondary story to correct the problem and/or attempt to open more engaging lines of communication, such as getting on a call with them. Whilst it will be more work, team cohesion will break down rapidly if someone is enforcing their will upon everyone and is allowed to continue the behaviour.

Examples:

• Concerns noticed in grooming sessions - Bring them to the team in the conversation.
• Concerns noticed when examining the story - Bring it to the team in chat.
• Concerns spotted whilst doing the story - Bring it to the team in chat or with tech lead/ba/manager, who will bring it back to the team if necessary.
• Concerns spotted in draft PRs - Have the team look at draft PRs.
• Big design problems spotted in code review - Not ideal. Code reviews are meant to capture slight mistakes or make small adjustments, not overall design decisions or omissions in functionality. It is often better to create a corrective story to fix.
• Concerns spotted in implementation - too late; it will require much rework.