Kanban principles - Trello Tutorial

- [Instructor] Now that we've covered the basics of lean thinking, we can get into Kanban principles and core practices. Like lean thinking, Kanban is not a methodology or a project management how-to guide. It's a set of practices and principles that can be applied to an existing development process. It can be applied piecemeal which is called a shallow application or all out. The four principles of Kanban are start with what you do now, agree to pursue incremental, evolutionary change, initially, respect current roles, responsibilities, and job titles, and finally, encourage acts of leadership at every level. Because Kanban is an evolving process rather than a change right this instant by doing X, Y, and Z, there needs to be a defined starting point. This is where the first Kanban principle comes in. Start with what you do now. You need to take a good look at how you and your team develop software right now and get it down on paper. In Kanban, we call these established ways of doing things, policies and if you think your team doesn't have them, look again. The most unorganized fly by the seat of their pants development team has policies even if they're unspoken. If you can't identify how your team builds software now, how can you expect to change it in the future? From a defined starting point, your team can begin making incremental changes to the process. Kanban is very much a team sport and teams don't improve their overall performance overnight. They improve by each individual recognizing their responsibilities to the team and to the project as a whole. If that sounds familiar, it should because it's related to the lean value of amplifying learning and feedback iteration. The idea of respecting existing roles and titles falls into how you currently develop software. It's important to keep these structures at least at first in order to understand the big picture as it is now. After all, development isn't just made up of policies, it's also made up of people and those people fit into a management structure and division of labor that a team follows. Finally, encouraging acts of leadership at every level is basically what you'd expect, empowering the team just like in lean thinking. Everyone needs to have the opportunity to be valued and lead when appropriate. At this point, the natural question to ask is why do I even need Kanban in the first place? If it can't tell me how to development software or even manage my project? The answer is usually another set of questions starting with how much value your products are really delivering? Is the delivered value what was asked for? Are they delivered on time? Are they delivered at a pace that's sustainable for your development team? If you answered yes to all of these, then congratulations, you're the first team in history to have a perfect development process. If you answered no or I don't know to any of these, that's where Kanban steps in.