TL;DR
While Kanban practices can be used successfully for discrete projects, the Kanban framework is best suited to ongoing, queue-based processes. To be used properly in iterative development, you need to implement effective feedback loops for your processes and raise the visibility of your project's input queue.
Kanban in Manufacturing
Kanban has its roots in manufacturing, which by nature is primarily focused on repeatable process. For example, a production line might build a Model Q car in 2013 and a Model Z car in 2014; it generally wouldn't be expected to build a single car, declare victory, and then make single yacht before moving on to something else entirely.
That doesn't mean Kanban can't be used for iterative development. It simply requires an adjustment in one's perspective.
Feedback Loops
[O]nce a task was done, there were 3 tasks to replace it so no matter what we achieved, we still felt like we were going backwards.
One of the core practices of Kanban is implementing effective feedback loops. Part of the development cadence is to periodically take stock of where you were, where you are, and where you want to go next. In other words, the agile inspect-and-adapt process (implemented as Sprint Reviews and Sprint Retrospectives in Scrum) should also be an integral part of Kanban.
If this aspect of the framework is missing from your Kanban implementation, the ability to observe progress on the project will likely be missing, too. That certainly sounds like the sentiment you're expressing in the quote above.
Manage Queue Length and Number of Queues
On a related note, if your queue is actually growing continuously at three times the rate of your sustainable cadence, you need to determine the source of the process problem. Some potential areas to consider are:
- Improper filtering or queue management of incoming items.
- Inadequate team capacity.
- Not having enough queues, or not having the right kind of queues.
- Not enough resources to process the queues within the expected cycle time.
- Invisible roadblocks or process issues in hand-offs from one queue to the next.
This isn't an exhaustive list, but it's a place to start. Feeling like you're not making progress is very different from actually not making progress. It's up to your team to determine which situation you're in.
Evaluating Progress in Kanban Projects
If you're running an agile project, as opposed to a continuous process such as making cars, then your project should have a finite number of user stories and a set of defined milestones. Part of your feedback loop ought to include an assessment of team progress against this finite book of work.
The project input queue (called the Product Backlog in Scrum) should be visible to the entire team. The team's progress in drawing down work remaining ought to be visible to the team, too. If the team is feeling discouraged, then raising the visibility and transparency of the input queue may help.
However, note that if your input queue is not finite, then you either have:
- A continuous process, rather than a project.
- Changing scope or requirements for the project that may have gotten out of hand.
Visibility will help here, too. It exposes a process problem that the team can address. Being able to address process problems empowers a team, and empowered teams rarely feel an ongoing sense of futility.
