Then I joined a real team.

Suddenly, I was introduced to this thing called Kanban – and I realized I’d been treating software like a solo art project, not a process.

If that sounds familiar, you’re in the right place.

This guide will walk you through how Kanban actually works, how developers use it to track and prioritize work, and how it can help you stay sane when juggling bugs, features, and real-world deadlines.

Without further delay, lets get into it.

Here’s what we’ll cover:

• So… What Is Kanban?

• The Classic Kanban Board: Three Simple Columns

• How Developers Use Kanban in Real Life

• Kanban vs Scrum: What’s the Difference?

• So which one should you use Scrum or Kanban?

• What Tools Do Teams Use for Kanban?

• How to Use Kanban to Manage Your Own Coding Projects

• Final Thoughts: Why Kanban Isn’t Just a Board

So… What Is Kanban?

At its core, Kanban is a visual way to manage work. It helps teams (or team members) see:

• What needs to get done

• What’s in progress

• What’s finished

• Where things are getting stuck

The concept comes from lean manufacturing, but in tech, it’s often used in Agile teams that need flexibility without the structure of Scrum sprints.

Think of Kanban like a whiteboard that tells a story. Not just what’s done, but how work flows.

The Classic Kanban Board: Three Simple Columns

So what exactly is a Kanban board? At its core, it’s a visual representation of your workflow – a board that shows all the work your team (or you, solo warrior) are juggling, and where each task stands.

It can be physical, like an actual whiteboard with sticky notes that move from one column to the next. Or digital, using tools like Trello, Jira, GitHub Projects, or Notion. The key is that it’s visual and up-to-date. You can walk into a room or open a tab and instantly understand: What’s being worked on? What’s ready to go? Where are things stuck?

It’s like having your brain on a wall, but organized. And slightly less chaotic.

The beauty of Kanban is how dead simple it is to get started. At minimum, your board has three columns:

Each task – or card – moves from left to right as it gets worked on.

Let’s say your team is building a blog platform. Your Kanban board might have cards like:

• “Create signup form”

• “Fix image upload bug”

• “Deploy staging build”

Now, while Kanban is flexible, it can absolutely be taken too far.

I’ve seen boards with more columns than a Greek temple: “Needs Review,” “Pending Client Feedback,” “QA Rework Round 2,” “Blocked but Still Hopeful,” “In Existential Limbo,” and so on. Every card had six tags, three owners, two checklists, and one migraine.

The lesson? Don’t turn your board into a bureaucratic jungle.

You don’t need to account for every edge case. Start simple: “To Do,” “In Progress,” “Review,” “Done.” These basic stages cover most workflows. If you discover a real need for something more – like a dedicated “QA” column or “Blocked” column – add it intentionally, not because you feel like your board needs to look fancy.

Remember: A Kanban board should be helpful, not overwhelming. If you spend more time managing the board than doing the work on it… it’s doing the opposite of what it’s meant to do.

How Developers Use Kanban in Real Life

Here’s how you might interact with a Kanban board on a dev team:

1. You pick up a card from “To Do” – let’s say, “Add dark mode toggle.”

2. You move it to “In Progress.”

3. When it’s ready for review, you might move it to a temporary “Review” or “Testing” column.

4. Once it’s merged, tested, and deployed, you move it to “Done.”

5. You smile, drink some coffee, and grab the next card.

That’s it. But over time, this process helps the whole team:

• Spot bottlenecks

• Prevent duplicate work

• Reduce context switching

• Keep everyone aligned

What’s a WIP Limit — And Why Should You Care?

WIP = Work In Progress. This is the most important concept to keep us in check.

One of Kanban’s key principles is limiting how many things you’re working on at once. Because guess what? Multitasking kills momentum.

A typical WIP limit might look like:

• No more than 2–3 cards per person in “In Progress” Again this is best practice, but folks do pick up a lot and then they end up being the bottleneck.

• No more than 5 tasks waiting on QA.

Why? Because when everything’s urgent, nothing gets done. WIP limits force you to finish one thing before you start more – and that’s how real velocity happens.

If there are more than 5 tasks in the “To Do” column, the team doesn’t take up new ones. Instead, everyone chips in to see how they can help unclog the bottleneck. A bottleneck is your worst enemy in Kanban, and you want to resolve it so items move smoothly on time and on target.

Here’s a video recapping key concepts.

Kanban vs Scrum: What’s the Difference?

You’ve probably heard Scrum and Kanban mentioned in the same breath – and both are popular Agile frameworks. But they’re not interchangeable.

Scrum is structured, with roles like Product Owner and Scrum Master, and work gets organized into time-boxed sprints. It’s perfect for teams that benefit from rhythm and rituals – like sprint planning, daily standups, and retrospectives.

Kanban, on the other hand, is a little looser. No official roles, no set sprint timelines. Work flows continuously, and change can happen anytime. It’s perfect for teams who need more flexibility and fewer ceremonies.

So how do they compare in practice? Let’s break it down:

Bottom line:

• Scrum is a scheduled loop. Kanban is a living flow.

• One’s a playbook. The other’s a status window.

Here’s a video on the main differences between Scrum and Kanban you can watch if you want more detail.

So which one should you use Scrum or Kanban?

So… which one should you use?

It really depends on your team, your product, and your pain points.

✔️ If you’re working on a brand-new product where requirements shift a lot, and your team thrives with structure and routines – Scrum is likely the better fit. Sprints give you a sense of pacing, and ceremonies help ensure alignment.

✔️ If you’re managing ongoing work like bug triage, tech debt, infrastructure tasks, or anything that’s more “whenever it comes in” than “we need to ship this in two weeks” – Kanban gives you flexibility and visibility without the overhead.

And yes, there’s such a thing as Scrumban – a hybrid approach where teams use visual boards and WIP limits from Kanban, but keep some of Scrum’s structure like standups and retros. It’s like Agile tapas: you get the flavors that work best for your appetite.

Here is a detailed video that’'ll teach you more about how Scrumban works in practice.

Watch the Scrumban video only when you are familiar and comfortable with both Scrum and Kanban – otherwise, you might get confused from the cross-pollination of ideas and frameworks.

I personally have never seen a Scrumban implementation thats scaled well – too many folks trying too many things and none of them work. But thats just based on my experience – it may work for you and your team. I’ll let you be the judge.

What Tools Do Teams Use for Kanban?

You’ve probably seen (or used) one already:

• Trello – Simple and great for solo or small teams

• Jira – Enterprise-level, customizable workflows

• GitHub Projects – Lightweight but powerful for devs

• ClickUp / Asana / Notion – Integrated with docs/tasks

Kanban isn’t tied to any one tool – you can use an app, a browser tab, or a whiteboard and a pack of sticky notes from the office supply closet. What matters is how you use it. But let’s walk through some of the most common tools and what they offer in a Kanban context:

🟩 Trello

Trello is probably the easiest way to start with Kanban. It gives you a simple digital board with columns and cards you can drag and drop. It’s great for devs or small teams who don’t need tons of automation – just a clean place to track work visually.

🟨 Jira

Jira is a heavyweight – and while it’s built for Scrum, it also supports robust Kanban boards. You can define custom workflows, use built-in reports like cumulative flow diagrams, enforce WIP limits, and manage team velocity. Ideal for large teams that need traceability, integrations, and permissions.

🟦 GitHub Projects

If your code lives in GitHub, GitHub Projects is a clean way to stay close to your codebase. It lets you create Kanban-style boards with issues and pull requests as cards, so you’re never toggling between tools just to track what’s in progress.

🟧 ClickUp / Asana / Notion

These are all-in-one productivity platforms. They combine Kanban boards with documentation, team chat, calendars, and reporting. If your team needs more than just “move card left to right,” these tools let you manage projects, meetings, notes, and workflows in one place.

🟪 Whiteboard + Sticky Notes

Don’t underestimate the analog approach. It’s fast. It’s visible. It’s tactile. Physically moving a task from “Doing” to “Done” gives you a sense of progress no digital tool can match. And when something’s blocked? Slap a red sticky on it and call it a day.

Bottom line: The best tool is the one your team will actually use. Fancy doesn’t beat consistent. And the actual tool doesn’t matter as much as the discipline your team has to actually use it.

How to Use Kanban to Manage Your Own Coding Projects

Even if you're not on a team yet, Kanban is great for your own workflow. Here’s how you can use it to help yourself out:

1. Create a basic 3-column board (To Do, In Progress, Done)

2. Write out every task, big or small

3. Set a WIP limit (for example, no more than 2 tasks at once)

4. Update it daily. Make it a ritual.

5. Review your flow weekly – What got stuck? What moved fast?

Example:

You’ll be shocked how much clearer your thinking gets when you can see your work. It’s simple but super powerful to visualize your work it in this way.

Final Thoughts: Why Kanban Isn’t Just a Board

Kanban isn’t just a tool – it’s a mindset.

It helps you focus. It helps your team collaborate. And it gives everyone – even non-technical folks – visibility into what’s going on.

If you’re learning to code and want to feel more confident working with others, learning Kanban is low-effort, high-impact.

So don’t wait until your first job. Start using it now – and show up to that standup with confidence.

I hope this small 101 Guide to Kanban was helpful to you all. My sole purpose to write this was to help beginner developers understand Kanban as a practical workflow system – especially for those transitioning from solo coding to collaborative, real-world development environments. It aims to demystify the methodology in a casual, beginner-friendly tone while still offering actionable guidance.

I hope you enjoyed my beginners guide to Kanban.

Until next time, keep Learning, Unlearning and Relearning, folks….

I’ve been participating and running Sprint Retrospectives now for 15 years and I truly believe that when done well, they are the best way to make a team more effective and more closely bonded.

What is a Sprint Retrospective?

A sprint retrospective is one of the key events in an Agile Sprint. The retrospective occurs at the end of each sprint and it is the meeting where the scrum team gets together to talk openly and honestly about the sprint that has just finished.

The purpose of the Sprint Retrospective is to find out things that went well in the previous sprint and things that didn’t.

Agile promotes iteration and improvement. The retrospective is a way to continuously improve the team and the team’s practices by regularly (at the end of each sprint) dissecting your working practices and trying to improve upon them.

Building the Foundation for Effective Retrospectives

Before diving into methodology, let's address three critical factors that determine how successful your sprint retrospective might be:

1. Team size matters: I've discovered that scrum teams larger than 6-7 people struggle with meaningful retrospectives. The dynamics change, people speak less freely, and you lose the intimate environment needed for honest feedback. If your team has grown too large, consider splitting it.

2. Trust is non-negotiable: I've seen brilliant retrospective frameworks fail in environments where team members don't feel safe sharing honest feedback. This foundation must be established first.

3. Actions speak louder than words: Teams quickly recognize empty exercises. If retrospective outcomes aren't implemented, people will lose faith and stop participating. Make sure you follow through.

The Mechanics of Start, Stop, Continue

The beauty of this approach is due to its simplicity.

Start, Stop, Continue is a framework that tries to get you and your team to categorize all of the aspects of work in the team (planning, execution, reviews, communication, and so on) into three simple categories:

• Things we should start doing (before starting a new code change, see if there are open pull requests to review),

• Things we should stop doing (submitting pull requests that are longer than X lines), and

• Things we should continue doing (keep the stand up to 15 minutes).

Here's how I structure these sessions:

Gathering "Start" Items

I ask: "What practices should we begin implementing that we currently don't do?"

Common themes I've seen across teams include:

• Earlier stakeholder demos

• More rigorous code review practices

• Better preparation before refinement meetings

• Cross-functional pairing opportunities

• More well-defined tasks

Finding the "Stop" Items

Next question: "What's currently slowing down our productivity or quality?"

Frequently mentioned items include:

• Context switching between multiple stories

• Late-sprint testing bottlenecks

• Inconsistent documentation practices

• Meeting overload

• Changing priorities mid sprint

Recognizing "Continue" Items

Finally: "What positive practices have we recently adopted that require reinforcement?"

This category functions as a temporary holding area. Once practices become second nature, they graduate from the list.

The Decision Framework

After generating ideas, decision-making becomes critical.

You now need to decide which items on the board (across all categories) you want to talk about.

There may be some retrospectives where you decide as a team that the most important items to talk about are all In the “start” category, there may be some meetings where you talk about items from the Start, Stop, and Continue categories. It really depends on what is deemed by the team to be the most important items that need addressing.

Here’s my preferred approach to picking the most important topics to discuss:

1. Group similar items for clarity. Are there three items on the board that are to do with different aspects of stability? Group them into one.

2. Allocate three votes per team member. Giving people limited options means that their votes truly matter. If you ask people to tag any items they see as important, you’ll more than likely get an overwhelming number of action items.

3. Select the top 2-3 items for action. It’s not possible to make too many changes in one go or in one sprint. Choosing 2-3 means that you are likely to be able to achieve them. Starting each retro by highlighting missed action items can be demoralizing. Limiting your action items hopefully mitigates this.

4. Assign clear ownership for each item. One person needs to lead each action item. Without clear ownership, the bystander effect is likely to happen.

The key insight: changing too many things simultaneously dilutes focus. A few well-implemented changes outperform numerous half-hearted attempts.

Avoiding Retrospective Monotony

Repetitive formats lead to diminishing returns.

There are various ways that you can “spice up” the Start, Stop, Continue framework to make sure that people don’t get bored and just go through the motions.

Some of the processes below augment the Start, Stop, Continue process changing it slightly to keep it interesting.

I've developed several variations to keep the process engaging:

• Silent brainstorming: Everyone writes ideas on sticky notes before sharing

• Theme-focused: Concentrate on specific areas (for example, "testing practices" or "collaboration"). Only do Start, Stop, and Continue on the chosen topic.

• Data-driven: Begin by examining sprint metrics, then discuss implications. Look at the sprint burndown, the velocity, the story breakdown and do Start, Stop Continue based on the data that you see. For instance, “Start breaking stories down to smaller chunks so that each story can be delivered quicker giving us a more smooth burndown”

• Rotating facilitation: Have different team members lead each retrospective. People engage more if they are actively leading a meeting. They will find ways to keep the others engages as well as they want to do a good job of running the meeting.

• Talking stick: Use a physical stick (yes, I’m serious) as a talking stick and only the person holding can talk. They are allowed to talk about whatever they want, good, bad, or indifferent. You can have one person taking the notes of what the person with the talking stick is saying. For instance, the person with the talking stick might say "I’d like to reduce the number of project meetings within the Sprint”. The meeting facilitator could then translate this to “Stop having so many project meetings in the sprint” and put it on the board.

The Mathematics of Team Improvement

Here's something rarely discussed in Agile circles but frequently mentioned in finance: the power of compounding. Just as compound interest transforms modest savings into significant wealth, small team improvements compound over time.

Consider this: A team implementing just one meaningful improvement per sprint will see huge results after a year. If each improvement increases efficiency by just 2%, the compounding effect after 26 two-week sprints is remarkable.

Teams that understand this principle outperform those making sporadic large changes.

Maintaining Continuity Between Retrospectives

I maintain a living document tracking all retrospective outcomes.

Before each new session, I review:

• Which items were successfully implemented

• Which items need continued attention

• Which items were dropped and why

This creates an improvement narrative that demonstrates the team's evolution.

Why This Framework Delivers in Real-World Scenarios

Having implemented this across multiple organizations, from startups to established enterprises, I've found the Start, Stop, Continue model succeeds because:

1. It creates immediate clarity on what requires action

2. It balances recognition of successes with acknowledgment of challenges

3. It creates a sustainable improvement cycle without overwhelming the team

4. It focuses on behavioral changes rather than vague aspirations

The best retrospectives I've facilitated didn't just improve processes—they transformed team cultures by establishing continuous improvement as a fundamental value.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site creating forever-free online calaculators at CalculatorLord.com.