Tag: scrum

How One Finger Changes the Entire Daily

What’s It All About?

I’ve been introducing this micro-technique for years across different teams, and every time I see the same surprised faces: “Really? It’s that simple?” Yes, it’s that simple. And that simplicity is where all the power lies.

The question: “How confident are we that we’ll deliver the sprint goal?”
The answer: thumbs up 👍 or thumbs down 👎.

Zero discussion, zero nuances – pure binary. After one minute, we know whether we have a green or red light. There’s no “maybe,” “probably,” “it depends on…” There’s certainty or lack thereof. There’s a team that feels comfortable with the current state of affairs, or a team that signals concern.

This isn’t a democratic vote – it’s the team’s temperature. One thumb down in a five-person team is already a signal that it’s worth stopping and talking. Three thumbs down is a signal that the sprint has a serious problem.

Why Does This Work? (Benefits)

Lightning-Fast Team Diagnosis

In 5 seconds, you see the sprint’s temperature – a project thermometer without diving into the Jira labyrinth. You don’t need to analyze burn-down charts, count story points, or check how many tasks are in the “In Progress” column. You look at the thumbs and immediately know whether the team feels confident or has doubts.

This diagnostic speed isn’t just about efficiency – it’s also psychological. From the first second of the Daily, the team knows they’ll have a chance to express their concerns in a safe way. They don’t have to wait until the end, they don’t have to interrupt someone’s story about their tasks.

Psychological Ice-Breaker

Fingers warmed up, tongues too – it’s easier to start concrete conversations after a symbolic gesture. There’s something ritualistic about it, something playful, but also something communal. Everyone makes the same gesture at the same moment. This builds a sense that we’re one team, not a collection of individual performers.

I’ve noticed that after introducing this technique, people smile more often at the beginning of Daily meetings. Maybe it’s because of the gamification element, or maybe because they know – they have a safe space to express doubts.

Shared Responsibility for the Goal

Every thumb is a voice, “we” deliver the goal, not “those backend guys” or “frontend is falling behind again.” This is a very subtle but powerful shift in thinking. When the whole team shows thumbs down, nobody looks for someone to blame – everyone feels responsible for finding a solution.

Early Warning System

The first 👎 often appears several days earlier than the first red graph in Sonar or the first delay in the schedule. It’s like canaries in a coal mine – the team senses problems intuitively before they appear in metrics1.

Through years of observation, I’ve noticed that experienced developers have incredible intuition about whether a sprint will be successful. Often they can’t rationally explain it, but they feel something is wrong. The thumb down is a channel for this intuition.

Cure for “Daily-Sleepy-Syndrome”

Movement and micro-gamification raise the meeting’s pulse. Instead of sleepy mumbling “yesterday I did this, today I’ll do that,” we have a moment of activity, a moment when everyone simultaneously must think about the sprint’s state and express their opinion.

Where Do Thumbs Down Come From? (Reasons)

Unclear Requirements

“We still don’t know what fields the PDF report should have… and we’re already halfway through the sprint.” This is a classic – the user story seemed clear during planning, but during implementation, it turns out to hide dozens of details nobody thought of.

Symptoms: Developers ask more and more questions, the Product Owner responds “I’ll check and get back to you,” and tasks hang in “In Progress” without progress.

Technical Blockers

The test environment got up on the wrong VM side again, the external provider’s API works “sometimes,” and the test database has data from the Stone Age. Technical obstacles that paralyze the team’s work.

Symptoms: People sit in front of screens but can’t do their work. Slack fills up with messages “it’s not working for me either” and “did someone already report this to IT?”

Excessive Scope

Classic: the Product Owner added “just a small fix” the size of Godzilla. Or it turned out that a “simple” task requires refactoring half the application. Scope creep in its purest form.

Symptoms: Tasks that were supposed to be “small” grow like yeast. Estimates turn out to be ridiculously low. The team feels like the sprint is “spilling over.”

Key Person Unavailability

DevOps is on vacation, and we’re without merges like without coffee. The architect got sick at a crucial moment. The Product Owner went to a conference just when we need their decisions.

Symptoms: Decisions aren’t being made, work stops, people improvise solutions that may not be optimal.

Overly Optimistic Estimates

Yesterday’s weather? Yesterday the sun was probably shining on Mars. The team underestimated complexity, didn’t account for all dependencies, forgot about tests, or didn’t anticipate integration complications.

Symptoms: The burn-down chart looks more like “burn-up,” people work overtime, and yet tasks don’t get closed.

Thumb Down? What Next? (Scenarios)

When you see a thumb down – or several thumbs down – don’t panic. This isn’t a verdict. It’s an invitation to conversation.

The first reaction should be simple: “Why?”

Not “who’s to blame,” not “what did we do wrong,” just simply: why do you feel we might not deliver the sprint goal? This question should be asked in a safe atmosphere, without accusations or pressure. Every thumb down is a valuable signal, not a reason for shame.

Phase One: Understanding

Give the team space to express concerns. Sometimes it turns out to be just a vague unease – “something doesn’t feel right, but I don’t know what.” Sometimes it’s a concrete problem – “the API hasn’t been working since yesterday.” Sometimes it’s intuition – “I have a feeling this task is bigger than we thought.”

All these signals are valuable. Even vague unease often turns out to be well-justified when the team analyzes it together.

Phase Two: Seeking Solutions

After understanding the problem comes time for the second key question: “What can we do?”

Not “what should we do” – that sounds like a commandment from above. Not “what must we do” – that sounds like punishment. Only “what can we do” – that sounds like an invitation to collaborate.

In this phase, various solutions may emerge:

• Reducing sprint scope
• Moving some tasks to the next sprint
• Asking other teams for help
• Changing the technical approach
• Escalating the blocker to management
• Clarifying requirements with the Product Owner

Phase Three: Another Thumb

After discussing problems and potential solutions, ask the question again: “How do you feel about the sprint goal now?”

This isn’t a formality – it’s checking whether the team really feels better after the conversation. Sometimes it turns out the discussion helped and thumbs go up. Sometimes it turns out the problems are deeper and we still have thumbs down.

Both scenarios are okay. What’s important is that we have real information about the team’s state, not illusory certainty.

When Thumbs Are Still Down

If after conversation and seeking solutions the team still shows thumbs down, it may mean that:

• The problem is more serious than initially thought
• We need more time to implement the solution
• The sprint goal is indeed threatened

And that’s also valuable information. Better to know this at the beginning of the week than on Friday afternoon.

How to Introduce This Trick Without Getting Fingers Caught in Doors?

1. Tell a Story

People are more convinced by anecdotes than slides2. Instead of theorizing about benefits, tell about a specific team that avoided a sprint catastrophe thanks to this technique. Or about how one developer’s thumb down saved an entire release.

2. Start with Yourself

Be the first to raise your thumb (or lower it, if necessary). Show that it’s normal for a Scrum Master to have doubts too. If the team sees you’re not afraid to show uncertainty, it will be easier for them to do the same.

3. Don’t Interpret Individual Thumbs Publicly

Red finger ≠ red Dev. Don’t say “I see that Michael has doubts.” Focus on the overall picture: “I see several thumbs down, let’s talk about the team’s concerns.”

4. Maintain Psychological Safety

A finger down is a gift, not shame. Emphasize that signaling problems is every team member’s responsibility. Thank them for honesty, don’t criticize for “pessimism.”

5. Track the Trend, Not the Point

Three consecutive green sprints? You can loosen your belt. Three red ones? Time for more serious changes. One thumb down is information, a trend of thumbs down is a signal for action.

6. Adapt to Team Culture

In some teams, five fingers (from 1 to 5) work better, in others colors (green/yellow/red)13. What matters is the idea – quick, visual, safe communication about sprint status.

Summary

In an era of advanced dashboards, AI predictors, and other technological wonders, a small thumb can still work miracles. This isn’t another framework or methodology – it’s simply a tool for quick communication. Simple, effective, human.

Try it tomorrow at your Daily. Ask the question, see the thumbs, talk about what you see. At worst… you’ll show me a thumb down – and that will be good too, because we’ll learn something. 😉

Remember: the goal isn’t green thumbs at all costs. The goal is real information about the sprint’s state and a team that feels comfortable telling the truth. A thumb down isn’t failure – it’s a starting point for a better sprint.

Here’s to healthy sprints – and your fingers!

Have you ever seen a Scrum team proudly presenting their Kanban board with dozens of columns and sticky notes wandering from person to person? I have. And each time I feel like I’m watching a slow-motion disaster – something I call “Kanbanosis Acute.” It’s like watching someone trying to ride a bicycle while playing an accordion – theoretically possible, but why torture yourself like that?

Tech Lead: “I’m afraid you’ve got Kanbanosis Acute.”
Junior Dev: “Is it serious?”
Tech Lead: “You’ve started organizing your unit tests, coffee orders, and emotions into To Do, Doing, and Done.”

Combining Kanban with Scrum is one of those ideas that seems sensible at first glance. After all, both approaches belong to the Agile family, right? The problem is that it often leads to more confusion than benefits, and in extreme cases, can be one of the reasons for the collapse of Scrum teams and the retreat from Agile in organizations.

Why Kanban and Scrum Form a Toxic Marriage?

Scrum was inherently created to deliver value when solving complicated and complex problems. Kanban, on the contrary – for simple and repetitive tasks.

Sprint vs Flow – a Fundamental Conflict

Scrum is based on sprints, which by design start “clean” (no work in progress) and end “clean” (everything planned is completed). It’s like preparing meals for the entire week on Sunday – clean refrigerator at the beginning, full of food containers at the end.

Meanwhile, Kanban is a continuous flow, where tasks flow through the system like water through a pipe. When we try to force Kanban flow into sprint frameworks, we lose the main advantage of Kanban – the ability to measure flow consistency. It’s like trying to measure river flow, but only during specific weeks of the year – the data will be incomplete and not very useful.

Flow Stabilization at the Cost of Inspection and Adaptation

The desire to stabilize flow in Kanban often leads teams to extend sprints. “Hey, maybe let’s do three-week sprints instead of two-week ones to better manage flow?” – I’ve heard this many times. The problem is that longer sprints mean fewer opportunities for inspection and adaptation – fundamental elements of Scrum.

It’s like less frequent doctor visits – you might feel better because you hear bad news less often, but it doesn’t mean you’re healthier.

Team as a Unit vs Individual Columns

In Scrum, the team should be treated as one entity with shared responsibility. Everyone wins or loses together. Meanwhile, Kanban, especially in its traditional form, encourages creating columns corresponding to different stages of work, often assigned to specific people or roles.

“Analysis,” “Development,” “Testing,” “Deployment” – each column is a potential silo, and tasks are passed between them like a hot potato. Handover of work in the context of one team simply makes no sense – it’s like passing a ball between your left and right hand.

Specialization vs Cross-functionality

Building columns and assigning people to them makes it difficult for the entire team to collaborate. When we have a “Testing” column assigned to testers, developers naturally focus only on the “Development” column. This leads to specialization, which is the opposite of cross-functionality that we strive for in Scrum.

It’s like having someone at home responsible solely for vacuuming, and another only for washing dishes. They might be experts in their narrow fields, but what happens when one of them gets sick?

Most Common Mistakes When Using Kanban in Scrum

Too Many Columns

The simplest and most common mistake: creating too many columns. I’ve seen boards with columns such as “To Do,” “Analysis,” “Design,” “Development,” “Code Review,” “Testing,” “Documentation,” “Deployment,” “Done.” This isn’t a Kanban board, it’s a subway map!

In most cases, three columns are enough: “To Do,” “In Progress,” “Done.” Anything beyond that often introduces artificial divisions and encourages handovers instead of collaboration.

Obsession with Flow Metrics

Kanban offers many metrics: lead time, cycle time, throughput… Teams often focus on these metrics at the expense of what really matters – delivering value.

“Our cycle time decreased by 15%!” – great, but are customers happy with the product? Are we solving the right problems? Metrics are like a thermometer – useful for diagnosis, but they don’t cure the disease by themselves.

Push Instead of Pull

In true Kanban, tasks are “pulled” through the system, not “pushed.” However, in practice, I often see developers finishing their task and immediately moving it to the “Testing” column, even if testers are already overloaded with work.

It’s like throwing more dishes into the sink even though it’s already full – instead of helping with washing. Real Kanban requires discipline and respect for work-in-progress (WIP) limits, which are often ignored.

When Not to Use Kanban

Complicated Tasks

Kanban works great in predictable, repetitive processes. Software development is rarely like that. Each task may encounter unexpected problems, require deeper understanding, or a change in approach during implementation.

It’s like using a recipe for experimenting with new dishes – you might have a list of ingredients and steps, but the real magic happens when you deviate from the recipe and improvise.

Tasks Requiring Collaboration of Multiple Specialties

If your team doesn’t consist exclusively of “full stacks” (100% fullstack-QA-SEC-OPS), Kanban can lead to silos and delays in handovers. Modern software development requires close collaboration between different specialties, not sequential handover of work.

Pursuing Goals Instead of Tasks

User Stories, Epics, and Features are not tasks, they are user goals. Kanban is great for managing tasks, but not goals. When we try to force user goals into Kanban frameworks, we often lose sight of the real objective – delivering value.

When to Use Kanban

Repetitive Tasks

Kanban was born in Toyota factories, where processes are repetitive and predictable. It works great in service operations, industrial production, or other scenarios where tasks are similar and well understood.

Simple Tasks in Large Quantities

If you have hundreds of simple, similar tasks (like flipping a coin or assembling boxes), Kanban can help manage flow and identify bottlenecks.

Tasks Executable by Any Team Member

Kanban works best when any task can be taken up by any person on the team. Otherwise, bottlenecks form and tasks wait for specific people, which negates the benefits of smooth flow.

Sum of Compliance with the Above Criteria

Kanban is worth using only when 100% of the tasks meet the above criteria. Otherwise, we risk creating a system that works well for part of the work but hinders the rest.

Additional Reasons to Avoid Kanban in Scrum

Dilution of Team Responsibility

Kanban can lead to thinking “it’s not my task,” where everyone is only responsible for their column. This undermines the fundamental principle of Scrum about the team’s shared responsibility for delivering value.

Loss of Sprint Transparency

Sprints in Scrum provide a clear timeframe and scope of work, which facilitates planning and managing expectations. Caring about flow causes work to be transferred between sprints and final stages to overlap with the beginning of the next sprint. This in turn destroys team predictability and can slowly degrade business trust in development.

How to Avoid Kanbanosis Acute?

The best is… don’t do it, but if you must use elements of Kanban in Scrum, here are a few tips:

1. Keep the board simple – three columns are often all you need.
2. Maintain team collaboration – avoid assigning columns to specific people.
3. Respect WIP limits – this is a fundamental principle of Kanban, without which it loses meaning.
4. Don’t abandon Scrum ceremonies – Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective are still key.
5. Remember the goal – delivering value is more important than beautiful flow charts.

Summary

I am a huge fan of Kanban – really! It’s a powerful tool that revolutionized industrial production and can be extremely effective in appropriate contexts. However, in software development with an Agile approach, where collaboration is required, not handover, Kanban often introduces more problems than solutions.

Instead of blindly combining Kanban with Scrum, consider what you really want to achieve. If your goal is better work visualization, perhaps a simple board with three columns is enough. If you want to improve flow, maybe it’s worth focusing on reducing the size of User Stories and better team collaboration.

Remember that methodologies are tools, not religion. Use them wisely, adapting to your needs, but don’t forget the fundamental principles behind them. For Scrum, these are transparency, inspection, and adaptation. For Kanban – visualization, limiting work in progress, and flow management.

And if you ever notice symptoms of Kanbanosis Acute in yourself or your team – excessive multiplication of columns, obsession with flow at the expense of value, or handover of tasks instead of collaboration – know that there is a cure. Sometimes the best solution is to return to basics and remind yourself why we use these methodologies in the first place.

Because ultimately, it’s not about whether you use Kanban, Scrum, or any other methodology. It’s about whether you effectively deliver value to your customers. And that requires collaboration, adaptation, and continuous learning – regardless of what you call your process.

The speed of gaining experience depends on the possibility of carrying out conscious analysis and reflection on events. From this point, we will quickly come to an interesting conclusion: since reflection gives us experience, analytical skills allow us to build experience even from other people’s experiences. That’s why as Scrum Masters we have to carry out so many additional activities outside of work.

Just to name a few of the most important:

1. participation in meetups

We often discuss real situations there. Common conversation and analysis as well as a variety of ideas allow us a deep understanding of what has happened in the past.

2. mentoring process

The Scrum Master is to be a mentor and coach for the team, but he should accelerate his development of those skills by participating in and leading the mentoring process. Sharing experiences on a high-trust basis including shadowing opportunities are often more valuable than years of experiencing the same mistakes.

3. reading books

Is reading a book important if I already know how to do Scrum? Extremely. Even the basic books recommended for taking PSM I provide us with a different view of an author on the same issues. Sometimes one simple sentence triggers the thought process and something jumps back into the right place. Read on.

4. writing articles

Trying to explain a topic in simple terms is difficult. The written form forces you to think, focus and be precise. “but I do not know how to write!” It’s just an excuse. Write, give it to your Scrum Masters friends for review, they will tell you if it is good. Besides, Courage is important for us, right? 😉

5. conducting training

According to the old rule, “I explained it to others several times and finally I understood it myself” – conducting training forces you to prepare the material in a structured way. The need to explain the prepared material and answer participants’ questions force us to look at the issues from a different perspective. The result is a deeper understanding of the issues.

6. creating exercises, simulations and tools

Just like writing articles, this activity requires the creation and focus on what we want to convey. Creating, checking and improving tools leads to the collection of unique solutions. And what a pleasure it is to test and refine tools…

More about evaluating professional experience you’ll find here:

“Experience measured in years” == bullshit.

Which way of gaining additional experience is the most important? All of them. Don’t limit yourself to a point or two – take as many as you can. They complement each other.

– Sometimes? It seems like always. I even have the impression that as Scrum Masters we are only collectors of other people’s ideas and solutions. Are we competent enough to know better than specialists what is a good solution in their area of expertise?

Today I would like to show you an idea that was once brought up by Paweł Płoneczka, experienced developer (Pawel, again — thank you!).

A common problem of a Scrum Team is poor feedback and little stakeholder involvement during the Sprint Review. There are many reasons for this issue, but the most common is the inability to show stakeholders what changes have occurred in the product. How are they supposed to appreciate a product if not even the team that creates it recognizes them and is able to show them?

The Scrum Team should try to present their Sprint increment as if it was the best job they have ever done:

• with pride
• as an impressive display of their skills and effort
• it should reflect the deep commitment into the product
• it should remain in the viewers memory for a long time
• it should be a small, directed show.

How to do it? A director is needed.

When planning, the team should think about who will be the director, who will be the master of the ceremony, who will prepare the script. Such a person has to have in mind the context of the Review when starting the work on a given functionality. During the Sprint, the content is collected (screenshots, data, ideas, photos), which is then used to create the Review presentation. You can also add to the Definition of Done something like “The team is ready to present the effects of work in an attractive way”.

Such preparation allows the team from the beginning to think of work in the context of showing the results to stakeholders, including the most important ones — the users. The show should be prepared in a way to make the viewers want to use new functionalities.

Additionally, it solves the recurring problem of “How to show bugs?”. It is simple — show the product before and after fixing. This is nothing of key importance, as it does not bring new value, but it is worth showing to maintain the transparency of the product.

What will be the results? I have already checked several times:

• Stakeholders, seeing the team’s commitment and the work put into the product presentation, almost immediately engage in the meeting.
• The product begins to change for the better.
• The dialogue between the team and the business is created.
• Eventually, trust and understanding increase.

Simple? It’s worth it.