Practice knowledge base
Agile (Kanban/Scrum)
Agile through Kanban or Scrum helps the team see the flow of tasks, limit overload, and regularly align priorities, commitments, and results.
Documentation sections
What it is
Agile in this card refers to a set of working rules for managing team tasks. Kanban makes the workflow visible and limits work-in-progress, while Scrum adds regular planning, syncs, results review, and retrospectives. This practice helps when the team loses rhythm, takes on too much parallel work, or argues about priorities during execution.
When it helps
- The team often starts new tasks but takes a long time to get them to a completed state.
- Priorities change in chats, and team members don't understand which commitments have already been made.
- Status is discussed at meetings, but afterward it's unclear who removes blockers and what comes next.
- People are overloaded with parallel work, and the manager sees the problem only after a deadline is missed.
- The team wants to spot bottlenecks faster without manually collecting reports from each member.
How to start
- 1 Choose one shared task board: a board with columns like "To Do", "In Progress", "In Review", "Done".
- 2 Assign a flow owner who monitors board rules, blockers, and column overflow.
- 3 Set WIP limits for key columns so the team doesn't take on new tasks when clearly overloaded.
- 4 Conduct a brief planning session: select upcoming tasks, clarify completion criteria, and dependencies.
- 5 After a week, check where tasks got stuck, and at the retrospective choose one change to the working rules.
Expected effect
The team gets a single source of truth for tasks and commitments. It's easier for the manager to spot overload and blockers earlier, and for team members to agree on priorities before work fragments into disconnected personal lists.
Common pitfalls
- The board is maintained for reporting, but decisions and blockers continue to live only in chats.
- WIP limits are announced, but the manager still adds urgent tasks on top of commitments already made.
- Scrum rituals are copied formally, without a clear outcome for each meeting.
- The team argues about the method instead of agreeing on simple flow rules and regularly reviewing them.
- The practice works worse if the team lacks a stable priority owner or if tasks constantly arrive without prior selection.
Further reading
- Book: David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business
- Book: Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time
- Documentation: Scrum Guide, Ken Schwaber and Jeff Sutherland
- Book: Mike Burrows, Kanban from the Inside
- Book: Henrik Kniberg, Scrum and XP from the Trenches
FAQ
Do you have to choose between Kanban and Scrum right away?
No. You can start with a shared board, work-in-progress limits, and a weekly flow review. If the team needs a tighter planning rhythm and results review, add Scrum elements.
Who should own this practice?
Typically, the team lead or the operational leader starts it. It's important to assign someone who monitors board rules, helps remove blockers, and brings the discussion back to priorities.
Can you start without a consultant?
Yes. To start, a single board, clear columns, brief planning, and regular retrospectives are enough. External help may be needed later if priority conflicts extend above the team level.
How can you tell the practice is working?
Look at whether there are fewer unfinished tasks, whether blockers are spotted sooner, and whether the team has a clearer idea of what a completed result means. Don't judge only by the number of meetings or how full the board is.