4

I'm in the process of comparing scrum teams to kanban teams and I wanted to answer the following questions:

What scrum processes/tools promote continuous improvement?

What kanban processes/tools promote continuous improvement?

Is there a fundamentally different approach in how scrum and kanban achieve continuous improvement?

  • Depending on your team all you really need is a white board and some sticky notes and people who are willing to collaborate and talk on a daily basis :) More information is needed to answer this properly. – ashga Sep 18 '15 at 10:45
  • Please clarify what additional information is needed to answer this properly. – WBW Sep 18 '15 at 16:00
  • For clarification on process/tools question above... For instance, in scrum, we have the retrospective as part of the iterative process that commonly promotes CI. Tools used during the retrospective often include white boards and sticky notes. I'm looking to understand what other common and not so common tools/processes people employ on Agile teams to promote CI. – WBW Sep 18 '15 at 16:04
3

No, there is no fundamental difference. Both have at their roots the concept of continuous review. As we've progressed along the agile history path, the two have shared back and forth techniques so that the two share much.

Demos: At regular intervals you should be demonstrating completed work to your stakeholders (founder and even your VC backers).

Retrospectives: At regular intervals you need to review how work is getting done.

Value Chain or Flow Analysis: Trace a path through your process to see where bottlenecks are.

  • It could be worth noting that Scrum says you should, but the guide itself has very little on how. On the other hand, Kanban follows the "Kaizen" approach. On the other hand, that's not strictly a difference because you can follow the exact same approach inside of Scrum. – Daniel Sep 21 '15 at 14:48
1

I view continuous improvement as being outside of any flavor of agile, or methodology in general. It's more a mix of org-level values, and local visibility and culture. Some typical things I've used:

  • Retros at the team level and org level (less frequent, bigger patterns)
  • Improvement roadmaps, created by the team for each aspect they want to improve, i.e. "What is our realistic end-goal for domain expertise, and where are we now by comparison?" then simply visualize middle steps and review/follow as you progress.
  • Metrics that matter - cycle times, bug counts, amount of rework from each review, response time of the product, etc.
  • "That sucked/that was awesome" boards where team members can put up stickies for any reason throughout an iteration (also good fodder for retros!)

The key point as others have touched on here is high visibility - out of sight, out of mind, even with things that are highly valued; people just get too busy to keep it in mind. :)

0

Depending on your team all you really need is a white board and some sticky notes and people who are willing to collaborate and talk on a daily basis :)

Don't get bogged down in the terminology all you really need is to inspect what you did was it good or bad and adapt to continue with the good and remove the bad good luck on your journey :)

I would say try Scrum if it works great if not try Kanban! the main thing is to get started let your team know its acceptable to fail as long as you learn something :)

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.