5

I manage a development team using Scrum extremely successfully. When I started there was no organization to development, so we implemented Kanban as a stepping stone to provide visibility into the work we do.

Although Kanban did improve things, after a short period of time the team got a feeling of achieving nothing and was losing motivation. This was because once a task was done, there were 3 tasks to replace it; no matter what we achieved, we still felt like we were going backwards.

The main benefit I see to Scrum is having success at the end of each sprint and a real sense of achievement for the team. I suppose Scrum also shelters the team from the upcoming work more as well, so this might be partly answering my own question.

What can I do to improve my team's motivation and provide a sense of achievement using Kanban?

7

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:

  1. Improper filtering or queue management of incoming items.
  2. Inadequate team capacity.
  3. Not having enough queues, or not having the right kind of queues.
  4. Not enough resources to process the queues within the expected cycle time.
  5. 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:

  1. A continuous process, rather than a project.
  2. 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.

  • Thank you - basically your TLDR is exactly the problem I saw, and moving the team to Scrum was effectively the solution. I have a thorough knowledge of Scrum, but don't have a huge understanding of Kanban. This explains that what I saw as a disadvantage is simply a lack of understanding of where in a process Kanban can fit. I also did not make it clear my team effectively do have an endless projects; we are responsible for all development on a range of products, which are always requiring enhancement. – SpoonerNZ Aug 28 '13 at 18:28
  • this was a great read btw .. even tho it's bit out of time back in 2013 , but this is exactly the same thing i am facing right now. I think all i need is to sit down and think for a better way and seek input from the team – LArcenCiel Oct 11 '15 at 6:03
0

What can I do to improve my team's motivation and provide a sense of achievement using Kanban?

One way is to reserve the last column the kanban board for tasks done.

Let the completed tasks column fill up and then have a minor celebration when you clean it up. (Announce the major achievement of finishing n tasks, make a big deal of clearing the column. Some cheering and a good punch line. And food, if that's in line with team practices.)

This can be done every n tasks completed, or every few weeks, or even randomly whenever you need a break, or just feel like it.

Doesn't really take time, but gives a feeling that you care about their accomplishments.

Another easy win, is to visibly keep track of who was the biggest mover & shaker this week. Should be defined in such a way that everybody has a fair chance at it. Or keep the formula secret and announce a winner weekly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.