Objective Thoughts

When people ask “can Kanban be done under SAFe at the team level?” they are typically referring to Kanban practices. The starting point to answering this question, however, must be to look at the mindset underneath these approaches. This is a bit more complicated, but provides more power because mindsets create the context for practices

What is Kanban?

Before proceeding, however, we must be clear what we mean by ‘Kanban’. Kanban is an overloaded term meaning three distinct things:

This blog was written by Scott Bain, one of our instructors. However, it's a strong statement from all of us. Our combined experience of more than a century and a half bears out Scott's well-crafted message ushering in a new paradigm for design.

I have heard several proponents of popular frameworks and methods excuse the lack of some key concept as "well that's orthogonal to the framework/method, but we expect you to put it in if you think it has value." In this case the word "orthogonal" means independent or de-coupled from the framework/method in question. The challenge with this is threefold:

Kanban is a widely used method for process management, scheduling, and transition management with deep roots in Lean. As early as 2007, a group of software developers – David Anderson, Jim Benson, Corey Ladas, Darren Davis, and others – applied kanban to the process of software development, calling it Kanban for Software Engineering.

One of the most powerful tools for improving software development is to create more effective teams. Every method and every framework – Agile, Scrum, XP, waterfall, the various flavors of Kanban[1] – depend on it. This short series of blog posts address the importance of effective teams for fully functioning lean software development. The series looks at: