DAKI
Drop, add, keep, improve—action-oriented vocabulary for change.
Drop
Practices or obligations to remove.
Add
Missing elements to introduce—skills, rituals, or tools.
Keep
What is working and should stay.
Improve
What exists but needs tuning or clearer standards.
This board is for demo purposes only. Your responses are not saved. Close or refresh the page to clear all cards. Do not add any sensitive information.
What is DAKI?
DAKI stands for Drop, Add, Keep, and Improve—a retrospective format designed to produce immediate, actionable outcomes. The framework was developed by agile practitioners who wanted a format that spoke the language of change management directly, without metaphor or emotional framing. Each column is a verb that maps to a specific type of decision the team can make right now.
"Drop" asks what the team should eliminate entirely—ceremonies, tools, reports, or practices that no longer serve value. "Add" identifies missing elements to introduce. "Keep" preserves what is working. "Improve" targets existing practices that have potential but need refinement. The four categories cover the complete spectrum of process change: removal, addition, preservation, and enhancement.
DAKI is popular among teams with engineering mindsets because it is direct and actionable. There is no interpretive layer between the observation and the action. When someone writes "drop the weekly status report" in the Drop column, the implication is clear and immediate. This directness accelerates decision-making and reduces the ambiguity that sometimes plagues more open-ended retrospective formats.
When to use DAKI
DAKI is most powerful during periods of process optimization—when the team has established ways of working but suspects they are carrying unnecessary weight. It is the ideal format for a "spring cleaning" retro where the explicit goal is to simplify and streamline. Use it quarterly or after a team has run the same processes for three to four months without review.
The format works well for teams of four to ten people and fits into a 45 to 60 minute session. It is particularly valuable for teams that have accumulated process debt—layers of ceremonies, reports, and approvals that were each added for good reason but collectively create overhead that nobody has questioned. The "Drop" column gives explicit permission to challenge the status quo.
Avoid DAKI when the team needs to explore feelings or when the problems are interpersonal rather than procedural. DAKI is a process-engineering tool, not an emotional health tool. If morale is low and you run DAKI, you may get technically accurate action items that miss the deeper human issues. Pair DAKI with an emotional format in alternate sprints for balanced coverage.
How to facilitate DAKI
Begin by framing the session explicitly: "Today we are reviewing our ways of working to decide what to drop, add, keep, or improve. Nothing is sacred—every practice should earn its place." This framing gives permission to challenge norms. Then provide six to eight minutes of silent writing time for all four columns.
Process the columns in a deliberate order. Start with "Keep" to establish what the team values and wants to protect. Move to "Drop" next—this is the highest-energy column and benefits from the safety established by the Keep discussion. Then address "Improve" for existing practices that need refinement. End with "Add" to introduce new ideas on a positive, forward-looking note.
For each column, group related items and use dot-voting to prioritize. The key facilitation skill for DAKI is challenging the Drop column constructively. When someone proposes dropping something, ask: "What problem did this originally solve? Is that problem still relevant?" Sometimes the answer reveals that the practice needs improvement rather than elimination. Convert the top-voted items into commitments: one drop, one add, one improvement, and one keep to explicitly protect.
Tips for getting the most out of DAKI
The "Drop" column is where DAKI delivers unique value, so protect it. Teams often self-censor in the Drop column because proposing to eliminate something feels confrontational—especially if someone else created it. Normalize dropping by sharing examples from your own experience: "Last quarter we dropped our Friday demo meeting and replaced it with async Loom videos, which saved four hours per week." Showing that dropping is positive, not destructive, unlocks honest contributions.
The "Improve" column needs specificity to be useful. "Improve code reviews" is too vague. Push for: "Improve code reviews by adding a checklist of five items that every reviewer should verify, and set a 24-hour SLA for first review." Specific improvements are measurable and accountable. Vague improvements become chronic complaints that reappear every retro.
Watch for the balance between Drop and Add. If the team is adding three things and only dropping one, net complexity increases. Aim for at least a one-to-one ratio between drops and adds. Some experienced teams enforce a "drop before you add" rule—every new practice requires retiring an existing one. This constraint forces creative thinking about simplification.
Variations and adaptations
For remote teams, DAKI translates naturally to digital boards because each column is a clear action category. Use color coding: red for Drop, green for Add, blue for Keep, yellow for Improve. Consider anonymous submissions for the Drop column to reduce social pressure. Remote DAKI sessions often benefit from pre-populating the Keep column with a list of current team practices so people can more easily identify what to challenge.
For async teams, create a shared board with the four columns and a list of current team practices, ceremonies, and tools. Ask each team member to categorize each item: keep as-is, improve, or drop. Then in the synchronous session, focus on items where there is disagreement—some people want to keep what others want to drop. These disagreements are the most valuable discussions because they reveal different experiences and priorities.
A useful variation for technical teams adds an "Automate" column alongside the four standard ones. This captures practices that should continue but could be automated to reduce manual effort—things like deployment steps, test data setup, or environment configuration. Another adaptation for teams managing multiple projects uses DAKI at the portfolio level: which projects to drop, add, keep investing in, or improve the approach to.
Run Retrospectives in CodeKudu
CodeKudu includes dozens of retrospective board templates, anonymous feedback, AI summaries, and action items that sync to GitHub Issues, Jira, and Linear.
