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.

If you work on a Scrum team, you’ve probably heard of a daily scrum, sometimes called a daily stand-up. It’s one of the key events in scrum.

The “daily” usually takes place around the same time every day, and it should last around 15 minutes.

At first glance, it seems straightforward. When it’s your turn, you answer three basic questions. Job’s done, right?

Well, without a structure and someone to enforce that structure, a 15 minute daily meeting can turn in to a 45 minute chat.

What Is the Daily Scrum?

Scrum teams use the daily scrum to align and share their efforts.

Each person usually answers three questions:

1. What did I do yesterday to help the team meet its goal?

2. What do I plan to do today to help the team meet its goal?

3. Are there any obstacles in my way?

I call these the “classic three.” Yesterday, Today, Blockers.

From this explanation, if you’ve never attended a daily scrum, you might assume it’s just a trivial and pretty pointless meeting. But it can highlight important issues in real time.

For instance, if someone says, “I’m stuck waiting for a database script to finish,” the rest of the team can suggest a workaround.

Or if the product owner says, “We need to shift a feature’s priority,” everyone learns about it immediately.

Why Keep the Scrum Short?

In theory, the daily scrum lasts 15 minutes, give or take. Yet, many teams allow it to stretch to half an hour or more.

That’s risky.

When these meetings grow too long, people lose interest. Also, they might skip the next one, feeling like it’s a waste of time.

Beyond this, brevity encourages people to share only what matters most.

If someone dives into intricate details, it might derail the conversation.

This is not the space for describing every table in your database schema. It’s a moment to share your progress, highlight your plan, and let your teammates know if you’re blocked.

The Three Essential Questions

The daily scrum usually follows the same pattern. It’s predictable, and that’s a good thing.

Let’s expand on each question:

1. Yesterday’s Tasks: This is an update on what you finished. For instance, I might say, “I set up the new testing environment for our user login feature.” That helps the rest of the team see how tasks are progressing and whether I’m finishing my part of the sprint goal.

2. Today’s Plans: Next, we share what we’re about to tackle. For example, “Today, I’m going to fix a bug in the payment service.” That piece of information helps everyone see how the day’s work lines up with the sprint backlog.

3. Blockers: This is a crucial point. If something is stopping me from completing my tasks, I mention it here. Let’s say, “I need access to the staging environment, but I’m waiting on a permissions update to give me access.” This means if anyone on the team can fix that, we speed up progress.

In my teams, we usually have the Jira board open and associate each person’s update with the related story. This gives people a little more context. You don’t have to do this though – my teams just find it helpful.

How to Prevent the Scrum from Turning into a Status Meeting

A daily scrum is not just a status report. It’s a chance for the team to realign quickly.

But some managers treat it as a time to see who is on track. That can shift the focus away from cooperation. On the other hand, a team might treat it like a casual hangout without any structure. These extremes usually lead to frustration.

What’s the sweet spot?

It’s where the team focuses on tasks that lead to the sprint goal while also offering quick help when people get stuck.

The meeting should be about collaboration and the scrum team’s needs, not about pleasing a manager.

Also, if something requires a deeper talk, schedule a follow-up. For instance, you might say, “Let’s finish the stand-up, then we can chat about the modeling question after”.

If you find that your stand ups are getting too long, you as a team need to discuss why this is happening in the sprint retro and adjust.

A Typical Example of a Smooth Daily Scrum

Let’s paint a quick picture.

The team is working on a feature that handles user registration and payment processing. Each day, the daily scrum goes like this:

1. Developer A:

   • Yesterday, I cleaned up the user registration form.

   • Today, I’ll add form validation for email.

   • I’m blocked by a missing API key, so if someone can share that, I can move forward.

2. Developer B:

   • Yesterday, I tested the payment integration.

   • Today, I’ll fix a bug I found during testing.

   • No blockers.

3. QA Engineer:

   • Yesterday, I automated tests for the cart service.

   • Today, I’ll check the new user registration form.

   • No blockers, but I want to set up a quick chat about test coverage soon.

The entire process finishes in around 10 minutes. After the scrum, Developer A and Developer B might stay behind to swap that missing API key. Everyone else dives into their day. That’s it—short, sweet, and useful.

Common Problems That Disrupt the Daily Scrum

Let’s discuss a few pitfalls I’ve seen crop up over the years:

1. Going off on tangents: For instance, a developer might begin describing the entire architecture of a new microservice. The rest of the team is left wondering how that affects them.

2. Trying to solve every issue in real time: The daily scrum is not the place to debug code or solve other issues as a group. If something complex needs discussion, note it and talk after the stand-up with the interested parties.

3. Waiting for latecomers: Starting late can quickly become a habit. If people learn that the meeting really begins at 9:05, they start arriving at 9:10. The easiest fix is to start on time. People usually adapt once they see you’re serious.

4. No one mentions blockers: Sometimes, folks feel uncomfortable admitting a problem in front of the team. If that happens, the daily scrum loses its value. This meeting is precisely where you should feel safe to say, “I’m stuck here.”

5. Too many people in the meeting: In certain organizations, multiple teams join one daily scrum. That can lead to confusion. It’s better to keep each daily scrum small and focused. If you have a big project, you might break out into smaller Scrum teams.

Tips for Keeping the Meeting on Track

There are various ways you can help keep a daily scrum from devolving into a long, drawn-out meeting.

First, make sure you stick to 15 minutes (or shorter). A timer can really help. Some teams use an actual countdown on a screen, which can be fun. If you find that it’s consistently longer, it may be a sign that you have too many people, your team members need reminding about the format, and so on.

Second, make sure you have a capable leader who understands how to manage the scrum. Often, the scrum master or team lead can step in if the conversation strays. They might say, “Good point. Let’s park that for later.” This ensures the scrum doesn’t balloon into a brainstorming session.

You should also make sure the team is focusing on its sprint goals during the meeting. In addition to sharing tasks, remember why you’re doing them. For instance, if you know the sprint goal is to launch a new checkout flow, keep that in mind. This will help streamline everyone’s three questions.

Next, make sure you promote a culture of help. If someone mentions a blocker, invite the group to see who can help. This is a practical approach that fosters teamwork.

And finally, it can be helpful to use the scrum board. This board—whether physical or digital—helps people visualize progress. If your tasks are on sticky notes or in a tool like Jira, you can quickly show which tasks are done, in progress, or awaiting review.

Practical Ways Managers Can Support the Daily Scrum

Some folks ask if managers should attend the scrum every day. There’s no strict rule, but if you do join, here are some things to keep in mind to help your team stay on track.

First, make sure you let the team speak. The daily scrum is for the development team to share their plan and blockers. You as a manager should avoid turning it into a performance check.

Next, try to observe any ongoing or developing patterns. The manager can spot trends. For instance, if a certain issue keeps popping up, they might escalate it or allocate more resources toward solving it.

And try to offer help without dominating the meeting. The moment you sense a roadblock your position can solve—like a missing budget approval—step in. Otherwise, let the team own the meeting.

Frequently Asked Questions

1. How strict is the 15-minute rule?

   Pretty strict if you can help it. If your team is small, you may finish in even less time.

2. Do we need to stand physically?
   Some say it keeps the meeting short. Others aren’t able to stand, or prefer to sit. In my teams, the goal is brevity, so sitting or standing doesn’t matter as much. We also usually have a hybrid stand up where some people are in the office and some aren’t. For this, we all attend virtually.

3. What if we have nothing new to say?
   That’s fine. A quick “No updates, no blockers” is perfectly acceptable. The meeting might take only five minutes. Great—everyone can get back to work sooner.

4. Do we ever skip the daily scrum?
   Some teams do skip if everything is stable. I never do though, because it confirms that no new blockers have emerged. It’s like a brief pulse check. If there’s nothing to share, the meeting won’t last long anyway.

5. Who speaks first?
   Some teams pass a “talking stick” around in a circle. Others follow the order of tasks on the board. I’ve even seen teams do it alphabetically. I also like to mix it up by playing the “nomination game” where the person speaking nominates the next person. The method doesn’t matter, as long as everyone gets a turn. I do like to mix the ordering up though as it keeps the meeting a little “fresh”.

Conclusion

The daily scrum can be one of the most helpful parts of Scrum if it’s done right. It helps with open communication, early detection of blockers, and a sense of shared ownership.

Also, it reminds us what we’re aiming to achieve as a team (the sprint goal), which is easy to forget when everyone’s heads are down coding or testing.

Above all, keep it simple. Focus on yesterday’s progress, today’s plan, and any obstacles in your path.

If you need deeper conversations, schedule them right after the scrum with the people who care most about the topic. That way, you respect everyone else’s time.

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.