SaharaHex

While exploring Agile frameworks, I put together a diagram to highlight the differences between Scrum and Kanban. That process led me to think more deeply about reducing friction within development teams, and the illustration evolved to focus on team alignment, workflow clarity, and technical decision‑making.

I’ve created a short video to walk through the diagram and explain the thinking behind it. The commentary notes are included below.

Welcome to my Developer Blog. In this quick video, we’ll break down the Agile mindset and take a look at the Scrum and Kanban frameworks.

It’s a wide topic, and there’s no single “right” way to apply it—only the approach that best suits your project and your team’s strengths.

We’ll also touch on practical ways to handle conflict within development environments.

Key principles to consider when defining your project approach: Agile centres on iterative development, ongoing feedback, and the ability to adapt quickly.

• Deliver value early and often.
• Embrace evolving requirements.
• Work closely with customers.
• Keep processes simple and lightweight.
• Continuously reflect and improve.

Effective communication is essential—whether you’re sharing project ideas or outlining how development will progress. A well‑organised team, where everyone understands their responsibilities, is crucial for maintaining momentum when problems appear. Review plans as requirements evolve. Adapt direction based on user feedback. Allow space for change in every sprint.

Together, these practices strengthen communication and keep the project on track. They apply equally to Scrum and Kanban.

A comparison of the two methodologies makes it clear that each excels in different situations. You can even blend them and apply whichever parts best suit your project.

Scrum is a structured, sprint‑driven Agile framework that supports predictable delivery, clear roles, and strong accountability—ideal for complex product development. Its downside is that it can feel rigid and requires consistent ceremony discipline, making it less effective for teams that operate in a continuous‑flow model.

Where Kanban is a flexible, flow‑driven Agile framework that suits teams needing adaptability and continuous delivery. It’s ideal for support or maintenance work and can be introduced gradually. Its downside is the lighter structure—teams must enforce WIP limits and clear policies to prevent the workflow from becoming disorganised.

Strong teamwork is vital, and the ability to address friction effectively is a major strength. Management must understand that the people closest to the work often have the best insights into how things should be done. When leadership listens and stays open to the team’s expertise, issues are resolved more smoothly and the project moves forward with less disruption.

There are several ways to capture these decisions. An Architecture Decision Record (ADRs) is one effective method, and it can be kept lightweight or expanded with detail as required.

Simple example could be like this:

• Title: A short, descriptive name for the decision.
• Status: Current state of the decision (Proposed, Accepted, Rejected, Deprecated, Superseded by ADR‑XXX).
• Context: Explain the background and why this decision is needed. Include relevant constraints, requirements, or problems.
• Decision: State the decision clearly and concisely.
• Options Considered: List the alternatives evaluated, with brief pros/cons.
• Rationale: Explain why this option was chosen over others.
• Consequences: Describe the impact of this decision. Positive / Negative consequences (trade‑offs).
• Implementation Plan: Outline how the decision will be applied.
• Related ADRs: Link to other ADRs that connect to or influence this decision.
• References: Any supporting documents, benchmarks, discussions, or external resources.

Another option is a Technical Spike, where you turn disagreement into experimentation by creating small prototypes and evaluating the outcomes.

Pair programming for alignment, clear code review guidelines, a shared definition of “done,” and consistent coding standards all play a role in reducing friction and defusing conflict within the team.

Whichever method you use, it should help make conflict visible early. Follow a “no surprises” rule — if something feels off, flag it immediately. Separate people from problems by shifting the conversation from “my approach vs yours” to “what problem are we solving?”. And rely on data, not opinions — use benchmarks, metrics, and evidence to guide decisions.

This subject is endless.

Developers need to feel safe expressing concerns such as:

“I don’t understand this.”

“This approach feels risky.”

“I disagree.”

When that safety is missing, conflict doesn’t disappear-it becomes quiet resentment.