Kanban is a method for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. So when we think of Kanban, we are trying to:
• Visualize what we are doing now (workflow): seeing all the items in context of each other can be very useful
• Limit the amount of work in progress (WIP): this helps balance the flow so teams don’t start and commit to too much work at once
• Enhance the overall flow: when something is finished, the next highest thing from the backlog is pulled into play
Is your organization thinking of going with Kanban for PM or a software development processes? Kanban is an overall development methodology that can get you where you need to be – but it isn’t necessarily for everyone.
When we think Kanban in terms of project management and developing products and software we think of creating a function or functionality as it’s needed and dropping it in a bucket for when it’s actually needed. When the next phase is ready, it’s pulled by that function, team, or team member and utilized for the next phase of the product development process or project initiative you are working on.
Scrum and Kanban are similar practices and both fall under the Agile development methodology. With Scrum, of course, we create function or functionality fully for a project or product and roll out an entirely usable final product in a two week or whatever time-frame. There is less to verify and test, less chance for errors, less chance for misinterpreted requirements, and faster functionality rolled out to the customer to begin using.
With Kanban you are building complete modules or parts of the final product or system to be pulled out and used as needed or when the next phase or group is ready for it or needs it. Think of a car part. You take a piece of metal and drill some holes into it and shape it. Then drop it into a bucket for the door guys to create the passenger side door out of it when they are ready. Finally you have the assembly team who needs that door for the final car product. This is an appropriate analogy since Kanban was actually created by Toyota in 1953 for automobile assembly and production.
In terms of a software development project this could be modules of a CRM or accounting system. Develop the module then drop it in the testing folder. When the test team is ready they will pull it out and test it thoroughly. Once it’s passed testing it gets dropped in the ready for implementation folder where it will be pulled prior to final system go-live.
Kanban or Scrum?
Kanban and Scrum are very similar and compliment each other – and both fall under the Agile methodology for project / product development. But there are a few differences. Both Scrum and Kanban allow for large and complex tasks to be broken down and completed efficiently. Both place a high value on continual improvement, optimization of the work and the process. And both share the very similar focus on a highly visible work flow that keeps all team members in the loop on work in progress and what’s to come.
The differences basically fall into 3 areas…
• Scheduling / iterations. Scrum processes place heavy emphasis on schedule. The scrum team is provided with a prioritized list of story points that need to be completed to deliver a shippable product. Kanban is iterative in nature, but there are no required time boxes or iterations.
• Team roles and responsibilities. On Scrum teams, there are at least three roles that must be assigned in order to effectively process the work: the Product Owner, the Scrum Master, and Team Members. Under Kanban, there are really no set roles though it does make sense for someone to serve as a project manager or supervisor, especially for larger more complex Kanban projects. However, the roles generally evolve with the needs of the project.
• The board. On a Scrum board, the columns are labeled to reflect periods in the work flow beginning with the sprint backlog and ending with whatever fulfills the team’s definition of done. On a Kanban board, the columns are likewise labeled to show work flow states, but with one key difference: they also publish the maximum number of stories allowed in each column at any one time. This enforces the team-determined limitations Kanban prescribes for each condition.
Some Kanban pros:
• Works well for tight, cohesive teams that collaborate well and freely
• Great for team members and individuals who can see the project as a whole – good vision for how the pieces fit together.
• Meant for teams that work well self-directed and self-motivated. Can work with minimal input and direction – no daily stand ups.
Some cons associated with Kanban:
• Must be more careful in assigning work as with less structure deadlines can be difficult to enforce, but not impossible
• Kanban is best for teams with overlapping skills among the team members. If only one team member has a particular needed skill, that can hold up progress.
• Best for when deadlines aren’t as critical as on typical projects.
The best of both worlds?
There is something else… Scrumban. Scrumban is an Agile management methodology that basically combines the two. It was originally designed as a way to transition from Scrum to Kanban. Scrumban Use the prescriptive nature of Scrum to be Agile. Use the process improvement of Kanban to allow the team to continually improve its process. Scrumban is a management framework that emerges when teams employ Scrum as their chosen way of working and use the Kanban Method as a lens through which to view, understand and continuously improve how they work.
Summary / call for input
Whatever works best for you – only you can decide. It’s going to depend on a few things: your processes, you industry, your customer, and probably even your skill sets on your projects and development teams.
Latest posts by Brad Egeland (see all)
- Is Kanban Right for Your Organization? - September 21, 2017
- When Difficulties Arise with Project Team Members - August 13, 2017
- Why Keeping Scope Creep at Bay is Critical to Your Project - August 8, 2017
