Kanban Methodology in a Kotlin Project (Continuous Development of Four Features)

Vocabulary

• Kanban is a workflow management method inspired by lean manufacturing (originating from the Toyota Production System).
• Work-in-Progress (WIP) Limit: Maximum number of tasks allowed at any given stage.
• Pull System: Tasks are pulled by team members based on capacity, rather than being pushed.

Activity Diagram

flowchart TD
    Backlog --> To_Do
    To_Do --> In_Progress
    In_Progress --> Review
    Review --> Done

    In_Progress -- Blocked --> Analysis
    Analysis --> In_Progress

Overview of Kanban and Where It Fits

Kanban is a workflow management method inspired by lean manufacturing (originating from the Toyota Production System). In software development, Kanban is used to visualize work, limit work-in-progress (WIP), and improve the flow of value to customers. Unlike Scrum or XP, Kanban does not use fixed iterations or sprints – it’s a continuous flow approach. Work items (features, tasks, bugs, etc.) progress through stages on a Kanban board, which typically has columns like “Backlog”, “Analysis/Design”, “Development”, “Testing/QA”, “Done”, etc., tailored to the team’s process.

Where Kanban fits in: Kanban is often chosen by teams that need flexibility to handle incoming work or frequent reprioritization. For example, if our Kotlin project team expects requirements to change often or support requests to come in alongside feature development, Kanban allows mixing and handling those without the overhead of re-planning time-boxed iterations. It can also be used in tandem with Scrum (sometimes called “Scrumban”) or on its own as an alternative Agile method. Kanban aligns with Agile principles (like delivering value continuously and embracing change), but it differs in practice:

• No Time-Boxed Sprints: Work is continuous. There’s no concept of “commitment for a sprint”; instead, the team pulls new work as soon as they have capacity. Planning is on-demand rather than on a fixed schedule.
• No Prescribed Roles: Kanban doesn’t require specific roles (no Scrum Master or Product Owner mandated by the framework, though roles can still exist in the team as needed). The emphasis is on the process and workflow rather than who does what, but typically you still have someone managing priorities (like a product owner) informally.
• Focus on WIP Limits: The team sets explicit limits on how many items can be in progress at each stage of the workflow. This prevents overloading the team and highlights bottlenecks (e.g., if “Testing” WIP limit is 2 and there are 2 items there, no new items should enter testing until one leaves).
• Continuous Delivery: Each feature can be released as soon as it’s finished (if that makes sense for the business), rather than waiting for an “end of sprint.” Kanban doesn’t prescribe when to release; it decouples deployment from development cadence.
• Evolutionary Change: Kanban encourages continuous improvement (Kaizen) by making the process policies explicit and then tweaking them as needed. There are no required ceremonies, but teams often still have regular check-ins or retrospectives to discuss flow and how to improve it. Metrics like cycle time (how long it takes an item to go from start to finish) and throughput are used to find improvement opportunities.

In our Kotlin project with four features, we’ll see how Kanban manages the development of each feature in a flowing pipeline. Each feature is represented as a card on the board and will move from backlog to completion at its own pace. We’ll examine:

1. Feature 1: When the scope is discovered to be incorrect and needs further analysis (causing it to be blocked in the workflow).
2. Feature 2: When the customer changes requirements while the feature is mid-development.
3. Feature 3: When another team’s change or delay impacts the feature’s progress (an external dependency issue).
4. Feature 4: When a feature goes through smoothly from start to release without any problems.

flowchart LR
    Backlog --> Analysis["Analysis/Design"]
    Analysis --> Development["Development"]
    Development --> Testing["Testing/Review"]
    Testing --> Done["Done (Released)"]
    Analysis --> |Scope unclear (Feature 1)| Clarify{{Needs Clarification}}
    Clarify --> Backlog
    Development --> |Requirement change (Feature 2)| ChangeReq{{Change Request}}
    ChangeReq --> Backlog["Backlog (New/Updated Item)"]
    Development --> |Dependency blocked (Feature 3)| Waiting{{Blocked (Waiting)}}
    Waiting --> Development

In the Kanban flow above, work moves from Backlog → Analysis → Development → Testing → Done continuously. Feature 1’s scenario (scope unclear) is shown by the card going into Analysis but then needing clarification, so it goes back to Backlog (to be refined before starting again). Feature 2’s scenario (requirement change) is shown by a card in Development encountering a change request and essentially returning to backlog as a new or updated item (the old work is stopped). Feature 3’s scenario (external dependency) shows a card in Development being marked as blocked (“Waiting”) until the dependency is resolved, after which work continues in Development. Feature 4 would simply move straight through Analysis → Development → Testing → Done without any detours, representing the normal case. The board visualizes each feature’s status and any issues (blocked status or moving backwards) in real-time.

Feature 1: Blocked by Incorrect Scope in Kanban

Situation: Feature 1 is pulled from the Backlog into the workflow (say into an “Analysis” column for refinement, or directly into “Development” if the team starts implementation immediately). As the team starts to analyze or implement it, they realize the feature’s story is unclear or the scope is wrong. It requires going back to the customer for clarification, effectively blocking progress on Feature 1.

Kanban’s Approach:

• Just-In-Time Elaboration: Kanban doesn’t prescribe upfront planning for a time-box, but it benefits from refining backlog items before starting them. If Feature 1 made it into Development with incorrect scope, it means the refinement wasn’t sufficient. The team likely has a policy to do an “Analysis” step for each feature before full development. Upon hitting the unclear requirements, they stop forward progress on Feature 1 because working on it further would be wasteful.
• Visualizing Blockage: On the Kanban board, the card for Feature 1 is marked as Blocked or moved to a designated “On Hold/Blocked” area. Teams often use colored stickers or tags on Kanban cards to indicate a blocker. This visual cue is immediately visible to all team members and stakeholders. For example, the card might get a red label that says “Blocked – awaiting scope clarification.” Additionally, if the team has an “Analysis” column, they might move Feature 1’s card back there (or keep it in Analysis with a blocked tag) rather than in Development.
• Swarm to Resolve: Kanban encourages swarming on bottlenecks and blockers. If Feature 1 is blocked due to unclear scope, whoever pulled it might immediately involve others to resolve it. Perhaps the developer, the product manager (or PO), and a tech lead huddle to pinpoint what’s missing. They reach out to the customer or stakeholder for details. The idea is to remove the blocker as soon as possible. If the customer is not immediately available, they make it a priority to get a meeting or call scheduled. The Scrum Master role doesn’t exist in Kanban by default, but often a team lead or project manager will help facilitate getting answers from external parties.
• Requeue if needed: If the clarification needs significant time (say the customer needs to rethink the requirement, or additional research is required), the team will move Feature 1 out of the active workflow. This often means moving the card back to the Backlog or a “Waiting” column. Essentially, they un-commit it from active work. By doing so, it no longer occupies a WIP slot in Development (or Analysis). This frees the team to pull in other work. Importantly, the blocked work is not forgotten – it’s just not clogging the active pipeline. The Kanban board might have a visual indicator (like a Blocked lane or an icon on the card) to remind everyone that Feature 1 is waiting on something external (in this case, clarity from the customer).
• WIP Limits enforce focus: Suppose the team’s WIP limit for “Development” is 2 items and Feature 1 was one of them. With Feature 1 blocked, they have a choice: keep it in Development (which would occupy one of the 2 WIP slots, leaving only one slot for other work) or remove it from that column. Many teams would temporarily remove it (as described) so that it doesn’t count against WIP and another item can proceed. If for some reason they kept it in the column as blocked, the WIP limit would prevent them from pulling a new item until Feature 1 is unblocked or explicitly moved. Either way, WIP limits ensure the team doesn’t just start a bunch of new work without addressing the blocked issue. It creates a pressure to resolve the blockage or consciously decide to put it on hold.
• Clarify and re-prioritize: The Product Owner or customer provides the needed clarification (maybe through an email or a quick meeting). Now the feature is better understood. The team updates the card or writes a new user story for Feature 1 with the corrected scope. That card goes back into the backlog or into the “Analysis” queue, to be pulled again when ready. If the clarification came quickly, the same feature might resume soon; if it revealed that the feature is larger or less urgent, the customer might choose to re-prioritize it relative to other work. Kanban easily accommodates this change of priority – the backlog order can be updated any time, since there’s no commitment locking it in.
• Continuing the flow: Once Feature 1 is clarified, a team member will pull it from Backlog/Analysis into Development at the next opportunity (when current WIP allows). The feature then progresses: coding, testing, etc., and moves to Done. The earlier block is now just part of that feature’s history (it might have a longer cycle time due to the wait). The team might add a note in their retrospective or Kaizen board about this incident, like “Feature 1 was blocked due to unclear requirements – action: improve our story-writing process or involve customer more in grooming.”

Lifecycle until Release: Feature 1’s card had a detour on the Kanban board due to the scope issue. It was pulled, then blocked, moved back to backlog, then pulled again later and completed. This added to its lead time (total time from initiation to completion). The team will likely examine the lead time and see a portion of it was “waiting time.” From a process improvement perspective, they might say: “How do we reduce situations where cards go back to backlog? Did we accept it too early? Maybe we need a policy that all acceptance criteria are reviewed by the dev who will implement before pulling the card.” Implementing such a policy (like a Definition of Ready) could be a Kaizen action. Overall, Kanban allowed the team to handle Feature 1’s issue by pausing it without derailing other work. Once clarified, Feature 1 was delivered and moved to Done (and presumably released). The Kanban system made the issue visible and ensured the team addressed it without thrashing the whole plan – they simply adjusted the flow.

Feature 2: Handling a Mid-Development Change Request

Situation: Feature 2 is in progress (let’s say a developer is midway through coding it in the “Development” column) when the customer requests a significant change in requirements. Perhaps a new business rule was discovered or they want to change the feature’s scope based on recent feedback. The change request arrives while Feature 2’s card is actively being worked.

Kanban’s Approach:

• Immediate Reprioritization: Kanban’s process is highly adaptable to changing priorities. There’s no “sprint backlog” that’s locked; the Product Owner (or whoever manages the backlog) can reprioritize the backlog at any time. When the customer’s new requirement for Feature 2 comes in, the first step is to decide if this change is critical enough to implement right away or if it can be scheduled later. Assuming it’s important, the team addresses it immediately.
• Option 1 – Adjust the current item: If the change is not too drastic, the developer currently working on Feature 2 can incorporate it into the ongoing work. They update the card’s details (e.g., modify the acceptance criteria or description) to reflect the new requirements and continue. This might extend the time the card spends in Development, but that’s acceptable as long as it remains within WIP and the board reflects reality. The developer might loop back to do some additional analysis for the new requirement (possibly moving the card briefly to “Analysis” if needed, or just doing the analysis themselves while in Development).
• Option 2 – Create a new item (if drastic): If the change is fundamental – for example, Feature 2 needs to be completely redesigned – the better approach might be to stop the current work and treat the changed Feature 2 as a new piece of work. In Kanban, it’s perfectly fine to abandon or pause a card. The team could mark the current Feature 2 card as “Changed” or “Cancelled” and move it to Done (or a separate “Removed” column) to record that it’s not going forward. Then they create a new card like “Feature 2 (Revised)” with the new requirements and put that in the backlog (likely at the top position if it’s now the highest priority). The developer can then pull that new card immediately (since they freed a WIP slot by removing the old card) and begin work on the revised feature.
• Consider Work-in-Progress and Waste: Stopping an in-progress item means some work was wasted. However, Kanban and Lean thinking teach that it’s better to stop processing a defective item (in this case, a feature built to outdated requirements) than to finish it and throw it away later. By embracing the change now, the team minimizes waste—only the partially done work is lost, rather than a fully completed feature that’s wrong. Also, because Kanban typically encourages small batch sizes (small features or stories), the amount of work discarded is likely not huge.
• Communication: The team updates the board so that anyone looking at it knows Feature 2’s status. If a stakeholder saw that Feature 2 card moved backward or got replaced, they might ask why, and the team would explain the requirements changed. Often teams have a daily stand-up even in Kanban, where they mention: “Feature 2 was changed due to new requirements, so we stopped the old one and started a new card with the updated scope.” This keeps everyone in sync. Importantly, because Kanban is flexible, this doesn’t feel like a “failure” (whereas in Scrum it might be seen as not fulfilling a sprint commitment)—it’s just flow adjusting to new information.
• Implementing the change: The team works on the new scope of Feature 2. Given Kanban’s emphasis on finishing work in progress, they likely focus on getting this revised Feature 2 done before pulling other new work (unless something else is of even higher priority). They will design, code, and test the new requirements. Perhaps the original partially done code can be reused or modified, which is fine because they never left that context—no sprint boundary to cross means continuity is maintained. If the team practices continuous integration and testing, they probably have tests from the old version that now either get modified or thrown out, similar to how it would happen in XP or Scrum.
• Verify and complete: Once the revised Feature 2 is done, it moves to Testing/Review. The customer (or QA) will test it according to the new acceptance criteria. Since the change was implemented immediately, the customer can see the result quickly (maybe even the same day or week the change was proposed). After passing tests, the card moves to Done, indicating Feature 2 is finished as per the new requirements.
• Release and feedback: Kanban doesn’t dictate release timing, but if Feature 2 is valuable, the team might release it as soon as it’s done. Alternatively, they might bundle it with other features depending on release policy. Either way, the customer sees their change realized rapidly, which builds trust in the process. If the new version of Feature 2 triggers further ideas or tweaks, those simply become new backlog items, to be prioritized in turn.
• Continuous improvement: The team will note this incident in their metrics. They might see that Feature 2’s original card had some effort then got cancelled, and a new card was created. In a retrospective or service delivery review, they might discuss how to avoid in-progress changes. Perhaps the conclusion is “We should involve the customer a bit more during development to catch changes even earlier” or “maybe our backlog grooming needs to be improved so that by the time we start a card, it’s less likely requirements change mid-stream.” They might not always prevent it (business environments change fast), but they can reflect if anything in their control could be improved. On the flip side, they’ll also recognize that thanks to Kanban, they adapted swiftly and delivered what the customer needed without waiting for a formal cycle to complete.

Lifecycle until Release: Feature 2 essentially had two lifecycles on the Kanban board: one that got aborted (the original card) and a new one under revised requirements that completed. In practice, the timeline might be: Day 1 – started Feature 2, Day 2 – change requested, Day 2 (later) – started revised Feature 2, Day 4 – completed revised Feature 2 and released. The exact days are just illustrative, but the point is the interruption was handled within the flow. Kanban’s strength here is making this as simple as updating the board and continuing work, with no additional process overhead. The team’s throughput might show an extra card (cancelled) that didn’t yield a delivered feature, but that’s just part of the data they use to improve. What matters is the customer’s priority was met as soon as possible. This demonstrates Kanban’s ability to handle changing requirements at any time ( Kanban vs Scrum | Atlassian ) by simply reprioritizing work, unlike time-boxed approaches which might defer changes to the next cycle.

Feature 3: Delays from External Dependency in Kanban

Situation: Feature 3 depends on work by another team or an external service. As the team works on Feature 3, they hit a point where they cannot proceed until the other team delivers their component or fixes an issue. This is an external dependency causing a delay (for example, waiting on an API from another team, or a UX design from an external designer, etc.).

Kanban’s Approach:

• Mark as Blocked: Similar to Feature 1’s case, the moment it’s clear that progress on Feature 3 is halted due to an external dependency, the team marks the Feature 3 card as Blocked. On the physical board, they might put a big red blocker sticker on it with a note “Waiting for Team B API” or move it into a special “Blocked” column or swimlane. In electronic boards, there’s usually a blocker flag you can toggle. This visual indication ensures everyone (developers, PO, management) sees that Feature 3 is not moving right now because of an outside issue.
• Don’t let it hog WIP (if possible): If the team’s policy allows, they will remove Feature 3 from counting against WIP. This can be done by moving it to a clearly designated “Blocked/Waiting” area of the board. Some Kanban implementations have a separate horizontal swimlane for “blocked” items – they stay in their column but move to a swimlane that indicates they’re waiting. This way, the item is sort of taken out of the active flow. Alternatively, the team might keep it in the same column but since it’s marked blocked, they temporarily allow an extra item to be pulled (some teams allow an exception to WIP limits for blocked items). The idea is to not stall the entire development pipeline due to one blocked item. Kanban is about flow, so if one item stops flowing, the team looks to continue delivering other work.
• Follow up externally: Even though they continue with other tasks, the blocked card isn’t forgotten. A common Kanban practice is to review all blocked items daily (maybe during the stand-up or a separate forum) to check on their status. For Feature 3, the team assigns someone (often the person who was working on it, or a manager/lead) to chase the external dependency. They might contact the other team’s lead: “Hey, we really need that API. When will it be ready? Is there a workaround?” If the delay is indefinite, the Product Owner might decide to drop the priority of Feature 3 for now (move it to the bottom of the backlog until the dependency is resolved) and focus on other features.
• Use downtime wisely: If the developer who was working on Feature 3 can’t progress, they will switch to another task (because Kanban flow encourages not idling). Perhaps they pull the next item from Backlog into Development (assuming WIP allows or was extended due to the block). However, context-switching too much can be inefficient, so teams balance this. If the dependency is expected in a short time, maybe the developer does some code cleanup or writes some test cases around Feature 3’s area while waiting. If it’s going to be a longer wait, fully moving to a new feature (like Feature 4) is justified.
• Workaround if feasible: The team considers if they can create a stub or mock for the missing dependency (similar to how we described in XP). Kanban doesn’t dictate technical practice, but many teams borrowing XP/Agile techniques would do this to keep moving. For instance, if Feature 3 waits on an authentication service from another team, maybe they hard-code a dummy token for now to continue development, clearly marking that the code needs update when the real service is available. This can shorten the eventual integration time once unblocked.
• Resume when ready: When the external team delivers the dependency (say after 3 days, the API is up in a test environment), the team immediately picks up Feature 3 again. If they moved it out of WIP, they bring the card back into the active flow (e.g., back into “Development” if that’s where it left off). The developer integrates the external component and tests Feature 3 thoroughly. The card then proceeds to Testing and to Done as usual.
• Flow metrics and improvement: In the team’s metrics, Feature 3 will have a longer cycle time than other features. Kanban teams often track cycle time (from start to finish for each item) and can break it down into “active time” vs “waiting time.” They might note that Feature 3 spent 3 out of 7 days in a blocked state. During a retrospective or operations review, they’ll discuss this: “Feature 3 was blocked for 3 days waiting on Team B. How can we reduce such wait times? Could we coordinate earlier or have done something differently?” Perhaps the action is for POs of both teams to sync backlog priorities better, or to have started Feature 3 a bit later to align with the dependency’s readiness. It could also lead to exploring if parts of that dependency could be delivered earlier next time. Kanban’s data-driven approach will highlight this dependency delay as a source of process inefficiency, prompting efforts to address it in the future.
• Transparency to stakeholders: If stakeholders ask “Why is Feature 3 taking so long?”, the Kanban board provides an answer – it’s visibly blocked with a reason. The Product Owner can communicate that “Feature 3 is delayed because we depend on Team B’s component, which is due next week. In the meantime, we’ve pulled forward Feature 4 to keep progress going.” This kind of responsiveness is valued in Kanban: you don’t just sit idle; you adapt and keep delivering other value.

Lifecycle until Release: Feature 3’s card moved across the board with a stall in the middle. Let’s say it started on Monday in Development, blocked Tue–Thu waiting, resumed Fri and finished by the next Monday. It got released once done (or could even be immediately if continuous deployment is in place). During the waiting period, Feature 4 or other tasks might have been completed and released, demonstrating Kanban’s ability to handle parallel flows and reordering of work. The external delay impacted Feature 3’s completion date but did not necessarily impact the delivery of Feature 4. Kanban handled the dependency by explicitly acknowledging the wait (with the blocker flag) and adjusting workflow around it (by allowing other work to continue and then coming back to it when possible). This flexibility ensures that an external holdup doesn’t bring the whole team to a halt.

Feature 4: Smooth Flow to Completion

Situation: Feature 4 is executed without any problems or changes. The team takes it from idea to implementation to release without blockers or interruptions. It’s the ideal smooth case on a Kanban board.

Kanban’s Approach:

• Pull from Backlog: Once developers have capacity (a free slot in WIP), they pull Feature 4’s card from the Backlog into the first active column (perhaps “Analysis” or directly into “Development” depending on their process). Let’s assume their process has an “Analysis/Design” step to flesh out details. A team member (or pair) takes Feature 4 into Analysis, ensures they understand the requirements, maybe breaks it into tasks or notes on the card, and then moves it to Development.
• Steady progress through stages: The developer(s) work on Feature 4, writing code, and then move the card to “Testing/Review”. Another team member (or a QA) picks it up in Testing, runs tests, does code review or acceptance testing. Since no issues arise, it passes quickly. Then the card moves to “Done”. Throughout this journey, the card has been visible on the board, and anyone could see it move steadily to the right each day.
• Quality checks and Definition of Done: Even though Kanban doesn’t mandate a “Definition of Done” document like Scrum, most Kanban teams have explicit policies for each column. For example, “Development done means code is written and unit tests passed; Testing done means code is reviewed and acceptance tests passed.” Feature 4 adheres to all these policies at each step, ensuring quality. If it didn’t, it wouldn’t move to the next column. Because Feature 4 had clear requirements and no dependencies, it likely flows without returning backward.
• WIP and focus: The team ensures they didn’t start too many things alongside Feature 4. If WIP limits are, say, 2 in Dev and 2 in Test, and if there were already items in those columns, they either waited or finished those first. This means when Feature 4 was in Development, the team could focus on it appropriately. By respecting WIP limits, they avoid diluting their effort and can get Feature 4 done faster (ironically, limiting WIP often increases throughput).
• Throughput and cycle time metrics: Feature 4, being smooth, will likely have a short cycle time (perhaps a few days from start to finish). Kanban teams track this and can use it as a benchmark. If the average cycle time for a feature is, say, 5 days and Feature 4 took 5, it’s on target. They also count it towards throughput (e.g., 3 features delivered this month). Over time, these metrics help the team predict how quickly they can deliver similar features. Stakeholders appreciate this predictability for planning.
• Continuous deployment: If the team practices continuous deployment, Feature 4 might be deployed as soon as it passes testing and is marked Done. In some setups, moving to “Done” could even trigger an automated pipeline that deploys to production. If not, the Product Owner might bundle it with other completed features in a weekly or bi-weekly release. Kanban itself doesn’t dictate when releases happen, but the capability to release at any time is there.
• Feedback loop: Even outside of a formal sprint system, Kanban teams still get feedback. Perhaps after release, they demo Feature 4 in a review meeting to stakeholders (some Kanban teams have a cadence like a bi-weekly demo, similar to Scrum’s sprint review but not tied to sprints). The customer confirms that Feature 4 meets their needs. If everything is good, it’s just part of the product now. If there are ideas for enhancements, new cards are added to the backlog. The team continuously refines the backlog with input from these feedback moments.
• No idle time: Once Feature 4’s card is Done, the developers look at the board: what’s next? Kanban ensures there’s a continuous pull of work. They might immediately pull the next feature or perhaps a maintenance task. This means the team’s utilization is smooth as well – they’re always delivering value, rather than having to wait for the next sprint cycle to start something new.

Lifecycle until Release: Feature 4 simply traveled across the Kanban board from Backlog to Done without interruption. It might have been started on Monday and finished by Wednesday, for example, and then deployed. This showcases Kanban’s ideal: a smooth, continuous flow with minimal waiting. The team delivered Feature 4 as soon as it was ready, which in a business sense means users got the new feature at the earliest possible time. There was no artificial delay (like “we’ll wait until end of sprint to release”) – if the team/project allowed immediate release, they did it. The process overhead was minimal: no lengthy planning meetings, just picking the top card; no separate sprint review, just maybe a quick sign-off that it works; no retrospective solely for that item, though the team might collectively analyze flow periodically. The focus remained on moving valuable work through the pipeline efficiently.

Kanban’s Unique Practices and How It Tackles Challenges

• Visualization of Workflow: One of Kanban’s fundamental practices is making the work visible. In our scenarios, the Kanban board made it obvious when Feature 1 and Feature 3 were blocked and why (notes on the cards). This visibility triggers fast response: team members see a blocker and swarm to resolve it, and stakeholders see where things stand without needing a detailed report. It also showed the progress of each feature clearly, which helps in coordinating (for example, seeing Feature 4 nearly done might prompt the PO to prepare release notes).
• WIP Limits and Flow Management: By limiting work-in-progress, Kanban ensures the team addresses issues rather than ignoring them. For example, Feature 2’s scenario: with WIP limits, the team couldn’t just start Feature 5 and ignore the fact that Feature 2 was in flux. They had to make a conscious decision to handle the change or remove the item, or else their WIP would be blocked. Similarly, Feature 3 being blocked meant either leave it (consuming WIP and thus pressuring to unblock) or move it out (free WIP to do something else). Either way, WIP limits prevent the team from stretching too thin or piling up half-done work. Instead, it promotes finishing work (or explicitly pausing it) before taking new work. This leads to higher throughput and faster detection of problems.
• Continuous Delivery and Deployment: Kanban fits environments where deployment can be very frequent. Each feature is released when ready (if the business chooses to). This reduces the time customers wait for value. In our case, Feature 4 was available immediately upon completion. In contrast, Scrum might have waited until the end of the sprint to bundle a release. This continuous approach can delight customers with faster updates, and it also lowers risk because changes are smaller and easier to monitor. It does require good DevOps practices (automated deploys, etc.), which many Kanban teams invest in.
• No Fixed Roles, but Strong Collaboration: Kanban doesn’t define roles, but it implicitly requires collaboration. For example, there’s no official “Scrum Master” but someone needs to ensure the process flows—often a team lead or just the team collectively. There’s no mandated “Product Owner,” but usually someone (product manager/business analyst) curates the backlog and prioritizes (as we saw when changes came in or when deciding what to pull next). Because roles are not prescribed, teams have flexibility in who does what: e.g., developers might do more testing work if QA is backed up (swarming to help in Testing column to meet WIP limits) – this cross-functional behavior is encouraged. The lack of formal titles can flatten hierarchies and focus everyone on just getting cards to Done.
• Continuous Improvement (Kaizen): Kanban is built on the idea of continuously improving your process. The team uses metrics (like how long items stay blocked, or average cycle time, or how many items get reworked) to identify improvement areas. In our scenarios, they would reflect on Feature 1’s initial readiness, Feature 2’s mid-flight change, Feature 3’s dependency wait. Each of those can spark process changes: maybe introduce a “ready for development” checklist to avoid unclear stories, maybe better stakeholder communication to prevent surprise changes, maybe better integration testing with other teams. Unlike Scrum, Kanban doesn’t require a retrospective event, but teams often schedule regular Kaizen meetings or incorporate reflection into daily work. They might have a Kanban meeting once a month to review their cumulative flow diagram or cycle time distribution and discuss changes. This could result in tweaking WIP limits, changing how they do backlog refinement, adding a policy (like “limit how many high priority items can be in progress to avoid constant preemption”). Over time, these small changes lead to a more efficient and responsive process.
• Differences from Scrum/XP: Kanban’s approach is flow-based rather than iteration-based. Where Scrum timeboxes and waits for a sprint to end before major adjustments, Kanban adjusts on the fly. For example, Scrum would typically not swap a story mid-sprint (to avoid churn), whereas Kanban did exactly that for Feature 2 because it values flow and immediate response. XP has short iterations and technical excellence but still has iteration planning; Kanban just continuously pulls from backlog as needed. Kanban’s lack of prescribed ceremonies makes it lighter-weight in terms of meetings: no sprint planning (though you might have backlog grooming), no fixed retrospectives (but you do Kaizen when needed), no sprint review (but you might still demo work periodically). It can feel more ad hoc, but it’s actually very disciplined in terms of WIP and policies. Another difference: measurement focus. Scrum might measure velocity per sprint; Kanban measures cycle time per item and throughput. These metrics help in forecasting: e.g., “Based on our throughput, we complete about 4 features a month and 95% of features finish within 8 days of starting.” This is valuable data for project planning.
• When to use Kanban: Kanban is well-suited for teams with a steady stream of incoming work or high variability. If priorities shift frequently (like Feature 2 scenario), Kanban handles it gracefully. If the team is in a maintenance or operations context (handling production issues alongside development), Kanban allows intermixing those tasks. It’s also a good fit culturally for teams that prefer a less formal structure. On the other hand, Scrum might be chosen if a team wants more structure or has clear sprint-by-sprint goals. Some teams actually transition to Kanban after mastering Scrum, to gain more flexibility. In our four features example, if such changes and external factors are common, Kanban likely offers a smoother way to manage them than constantly resetting sprints.

Conclusion: Kanban provides a flexible, efficient way to manage the development of multiple features in a Kotlin project. It fits in an Agile environment by complementing the values of customer collaboration and responsiveness to change, but it does so without the structure of fixed iterations. The result is a system that handled Feature 1’s unclear scope by pausing and reprioritizing without fuss, Feature 2’s requirement change by seamlessly adjusting the workflow, Feature 3’s dependency by visualizing the block and refocusing efforts temporarily, and Feature 4’s straightforward development by simply pulling it, working, and delivering. Kanban’s continuous flow and focus on visualizing and eliminating bottlenecks make it a powerful methodology for teams that require adaptability and continuous delivery. It differs from Scrum and XP by foregoing timeboxes and formal roles, instead relying on work-in-progress control and constant improvement to drive efficiency. For our team, Kanban means we always work on the most important thing at the right time, and we deliver features to the customer as soon as they are ready, ensuring a responsive and lean development process.