Why if you have implemented or in the process of implementing Scrum and are ...

:

This is not about Scrum vs. Kanban. Both are effective means
to manage the work necessary to deliver value via software. That said; they
each represent in their own right, a very different means to achieve that
delivery. Scrum is rather prescriptive for how teams interact; how work is
carried out, etc. Kanban is not prescriptive in that regard. A mashed up
approach with combined disciplines can work. However, in doing so, you need to
make sure with the combination; you end up something that is greater than the
sum of its parts. In addition, you want to make sure you can retain the best of
each discipline. In the case of your efforts to implement Scrum, you will want
to make sure what you end up with is in fact Scrum.

To illustrate the point, let’s consider what Scrum is in a
nutshell (as codified by Ken Schwaber and Jeff Sutherland, the creators of
Scrum). Scrum Teams are created that are comprised of a Product Owner, Scrum
Master and a Development Team. A Product Owner manages a Product Backlog that
is prioritized in descending order by business value. The Development Team,
which is cross-functional and self-organizing, in conjunction with the Product
Owner and Scrum Master, based on a variety of factors (most often by a
combination of historic velocity + current capacity) in the Sprint Planning
Meeting, select a number of Product Backlog Items to work on during the Sprint
– which may last for at most, 4 weeks. The Development Team, in conjunction
with the Scrum Master and Product Owner (as needed), decides to how to
decompose the selected Product Backlog Items that now comprise the Sprint
Backlog into separate tasks. As the Development Team works during the Sprint,
it meets each day for a maximum of 15 minutes in the Daily Scrum Meeting. At
the end of each Sprint, during the Sprint Review (no more than 4 hours), the
entire Scrum Team meets to discuss/review the Product Increment (what was
completed during the Sprint). Subsequently, a Sprint Retrospective Meeting (no
more than 3 hours) is held to discuss what went well, what did not go so well
and what could be improved as to the Scrum Team. After that, the next Sprint
Planning Meeting is held and the process repeats.  All of this is codified in the Scrum Guide.

As for what Kanban is it first has to be stated that Kanban,  unlike Scrum, originated in a non-software environment. Kanban originated with  Toyota and devised the system as a means of supporting the production of cars.  Over time, Kanban and the Lean Manufacturing concepts have been applied to the  software development discipline. To the degree those concepts map cleanly to  software development remains very much in debate and it’s not a debate I’m going to undertake here. Rather, I’ll focus on the goals and objectives of Kanban and Lean. The origins of Kanban in the software context were codified by David  Anderson in his book Kanban – where he postulated the Kanban Method. There are  5 core principles: workflow visualization (Kanban Board), limited WIP (work in process), managed flow, defined explicit processes and improved collaboration.

For all of the rules codified in the Scrum Guide, in Kanban (in the traditional
manufacturing sense), there are two basic rules: the ability to see the work  flow and limit the WIP. These rules are meant to support the aims and goals of  Lean. The Kanban Method, as codified by David Anderson, there are three basic  principles: Start with what you know, Agree to pursue incremental and  evolutionary change and respect the current process, roles, and responsibilities. With regard to respecting the current process, this is where conflict between Scrum and Kanban can arise. Note that a team’s discipline or the degree to which a team is functional is not a factor in Kanban. Is any of this counter to Scrum? Not necessarily, but it might. For example, Scrum prescribes team makeup, title, roles, and responsibilities. If those roles (Product Owner, Scrum Master, etc.) and the responsibilities ascribed to those roles as promulgated by the Scrum Guide don’t exist, then yes, there will be conflict. Kanban says to respect what’s there. Scrum has a prescriptive mandate. Those are irreconcilable differences in my opinion and if your team is implementing Scrum, those efforts could be derailed if you bring Kanban principles into the mix.

A good way to view this is to look at the goals of each method. If you look at Kanban’s principles and if you already have a functioning Scrum Team, you will find that without implementing Kanban, you will already be achieving Kanban’s objectives. What about the Lean Goals? The main goal is minimizing WIP (i.e. waste). A Development Team does not take on more than what it can handle – which necessarily means that WIP is minimized. As for waste – the Product Owner sees to that by making sure the Product Backlog is well groomed (irrelevant items are removed, those items with the highest business value are
at the top, etc.). So then, if you have implemented Scrum, why would you also try implement Kanban? In my opinion, you wouldn’t for the aforementioned reasons. What about Kanban’s chief way of visualizing work, the Kanban Board? If you are working on a Scrum Team, you are already working with some visual representation of the Product and Sprint Backlog. Further, there is a visual representation of what is being worked on and what is done. Can a Kanban Board do that? Sure – but Kanban is more than just a board. The key is not to get caught up in the tools and devices. Rather, it is important to look at the underlying principles of a given methodology or framework. From that, you can ascertain where there are things in common and conflicts.

Some teams that use Kanban may be under the belief they are practicing Scrum. That may or may not be a valid belief. That practice would have to be assessed and gauged against the Scrum Guide. On the other hand, if you are practicing Scrum, then I would submit that an effort to bring Kanban into the Scrum practice would not present added value and perhaps, would be counterproductive. That’s not a knock against Kanban. Rather, it’s an assertion on my part the good things Kanban brings to the table are already accounted for with your Scrum practices.  Does that mean that Kanban has no value in your organization if you are using Scrum? Absolutely not! There may be other activities where Scrum does not apply or is a good fit for one reason or another.  In those cases, Kanban may be and could be a very productive alternative.  How about those cases where your team practices Scrum…but…<<insert your but here>>.  mplementing Kanban, by itself, is not going to remediate those “Scrum Buts.”

As always, when deciding to implement a new tool or process, have a solid understanding of why you would undertake such an implementation. Make sure the ills you are trying to remedy can be remedied with a combined approach.  Make sure your approaches are compatible such that one approach does not negate/dilute the other approach. When combining approach, you will want to make sure the net value add is at least equal to the sum of the parts.