Dive into Kanban (6) - Scrum vs Kanban | Thinking in Crowd / 鹄思乱想

Contents

1. Timebox
1. 1.1. Pressure & Goal
2. 1.2. Evil of endless item splitting
2. Roles
3. Work Item Restriction
4. Afterword
1. 4.1. Series

As a Kanban fan, I attended a Scrum-Master training organized by the company. This is a good chance for me to know Scrum more from an experienced person beside reading books, blogs or other documentations.

Here I will try to compare some core concept in Scrum with the same or similar idea in Kanban.

Timebox

Timebox is important in Scrum. Sprint is the crucial one which is normally 2 ~ 4 weeks. It’s used to control pacing for delivering usable feature instead of mockup or prototype.

There is NO prescribed Timebox in Kanban. Kanban can have different Cadence for Replenishment and Delivery. What is more, it can be on demand like release whenever there is something useful for users.

Pressure & Goal

From my perspective, the most important benefit or purpose of the Timebox is the pressure & goal it imposed. The whole team is driven by a hard deadline limitation & commitment to plan & deliver. This can provide a shared goal & understanding to the whole team.

This sounds like deadline driven and many people don’t like it. But I think what we hate is that the deadline is unreasonably set by some managers regardless of the task difficulty and reality. The Scrum Timebox is not that kind of a thing. It’s fixed for steady pacing and the team control what items are included in one Sprint. Commitment is made by the team together.

In Kanban, The steady pacing is controlled by WIP. It makes sure everyone can try to focus on one item at at time and reduce multi-tasking. For the pressure & goal, there is no explicit thing imposed in Kanban. It’s not so obvious but it exists when you really pay attention on the flow effeciency of the item. This can be a good thing or bad depending on the preference & maturity of the team.

Evil of endless item splitting

Many people don’t quite agree on such rude approach when fitting an item in a box, because cases happen that some team end up splitting the backlog item into finest level as technical items because it is too big to fit into a desired sprint Timebox. Hence, they argue that the Timebox approach causes the undesired consequence.

However, before blaming on it, we should know that:

Reducing the length of Timebox is NOT the goal of agility

We should not merely pursue the goal of reducing length of Timebox in order to prove that we are more agile than before. There is always a boundary or limitation for your business. Too short Timebox can also introduce overhead. Length of the Timebox should be chosen depending on how often we want and actually can deliver belancing the cost it takes. It’s not by merely using item splitting to reduce the timebox while it might need some other technical breakthrough, like introducing the automatic testing.

No matter use Scrum or Kanban, to be agile, we always want to split the item as small as possible but still should be a usable unit for user to perform testing.

The purpose for this is to let user validate the output as soon as possible and get feedback. Make the item to be small shorten the feedback loop. Don’t split just for fitting into something. Also, item splitting is not purely development team’s decision and it also need PO’s contribution.

In an ERP system, to implement a form containing 1000 fields in 5 tabs, is it acceptable to incrementally implement tab by tab or even section by section in one tab? The strategy might also be different between developing a new product and doing a migration project. For migration project, to the user, only when the new system that fully provide what old system has, the new system can be regarded as usable and can replace the old one. During development phase, PO needs to align with user to accept “incrementally growing” version and do UAT gradually as well. Of course, how development team guarantee that the new feature doesn’t break the old one is also a huge challenge.

Just let it be if the item really cannot be further broken down.

It happens and also some workable units are still not releasable from business perspective. Then we have to disable the function or rollback the change. The process is the same when things go wrong that originally planned item cannot be completed within Sprint. The challenge here is not using Scrum or Kanban. It’s whether and how the Source Code Management, Testing & Release process supports these kinds of scenarios. If we have technical level support here, we can more easily balance the Timebox length and item size or take the more flexible and on-demand delivery approach without the restriction of Timebox.

Roles

Roles are defined in Scrum and not particularly mentioned in Kanban. And one of opinion in the Kanban is that because no role or job title changed or external role introduced, resistance of change from management or employees should be minimal. But is that means that Kanban doesn’t have any of the role defined in Scrum?

Product Owner

No matter what agile methodology or old-fashion water-fall, we always want and need to have PO. This role is very important and makes final decision on Product, including requirement, priority, scope, etc. Especially when a Kanban board serves multiple Product, it even requires to involve multiple PO to have alignment on item priority as well.

Team

In Scrum, it emphasizes that the team is cross-functional and should be responsible for development, testing, release and anything required for delivering the usable features after each Sprint. When all things are controlled within one team, for sure life is easier.

However, traditional organization structure might breakdown the team by speicialty, like development team, testing team, UI/UX team, Release team, Infrastructure team, etc. When this kind of company need to introduce Scrum into their development process, it requires to do structural change. Without structure change, it does not work.

How does Kanban Team looks like then? How to define starting & ending stage in a Kanban board? How many team or different parties involved?

One of the selling point in Kanban is that it doesn’t require the company to do structural change. The essence of Kanban is to change as little as possible, visualize the existing development process and map the value stream instead of introducing any imaginary ideal process or borrowing one from external success story. Sounds very promising, right?

There are pros and cons of it.

To define the start and end point for the Kanban board, David mentioned in his book:

Successful teams have tended to stick to adopting workflow visualization with cards and limiting WIP within their own political sphere of control, and negotiating a new way of interacting with immediate upstream and downstream partners.

For example, when initially adopt Kanban within development team, the start and end point can only cover the development stages, because upstream who provides requirement and downstream who provides testing services are not in control. So in this case, there is just one team involved here.

Because the team doing Kanban might not necessary controls the item flow from end to end, it might be more difficult to become real agile from the considering from the whole business flow. For example, when controlling the WIP at the first stage of Kanban board, the development manager must have agreement with PO. What is more, chance of the improvement area is to block PO from sending urgent requests from time to time which interrupts the normal development flow and affects quality. If development manager has less political power than PO and PO doesn’t realize the agility of the company needs his own improvement, it’s difficult for the whole company to become agile. Power from higher level’s is required then.

The structure of the team in Kanban depends on the flow visualized in Kanban. It can be as narrowed as only one development team, or cross department. Hence, this requires full cooperation from upstream and downstream and the person who introduces Kanban need to have great ability to influence them. The other side, the person who introduces Scrum most likely has political power and ambition to do the structure change to break down the barriers already.

Hence, knowing what is in front is important before choosing the radical way of Scrum to reorganize the company structure or the incremental way of Kanban to influence upstream and downstream.

No matter which way to choose, management must have the ability to drive change among teams or departments. It’s not just simply adopting a process by following rules and then hoping the company becomes agile one day. The training on Kanban and Scrum actually should be more on the management level to understand the prerequisite instead of the team to understand the process concept. It’s more like the growing a culture.

Scrum Master

I heard a special saying that “Actively doing nothing”. A Scrum Master should be just like a Sheep Dog or Coach who actively do nothing on the team.

In Kanban, there is no such role because it encourages that everyone involved in the Kanban process looks for the bottleneck and area to improve because everything is transparent and reflected on the board.

One question may arise that if one day the team can do Scrum very well and nothing needs Scrum Master to coach, will the Scrum Master role be redundant?

I think the existence of this role depends on whether you think a dedicated facilitator, coach, issue spotter or change driver is required. To be honest, I think the Kanban way is the ideal situation to pursue because to stay agile, everyone in the team must have agile thinking and culture. But that is really not easy and sometimes an outsider can more easily facilitate necessary Kanban activities, spot out the problems in the process. Sometimes we need a neutral judge on the conflict or need a coach because we don’t know the unknown.

Lately, I am more inclined to have a dedicated “Kanban Master”.

Work Item Restriction

Scrum limits total items committed by the team at the beginning of the Sprint. When there is a change requested from PO, normally it should be planned on next Sprint.

Kanban limits the WIP per workflow state. When upstream wants to introduce urgent item, it’s OK to accept but required to pull out another one if the WIP limit is reached. And there must be consensus that the lead time of that item will be enlarged.

Different business model might be suited for different methods or use both in a combination way. For purely new product development, Scrum and Kanban should be both fine. But if the team is both developing new product or feature and also need to handle urgent production support, Kanban might be more suitable. Taking the Scrum approach requires you to consider how the urgent issue should be handled because production urgent issue normally is not accepable to wait until next Sprint.

Afterword

There is a good mini-book about the difference between Scrum and Kanban in InfoQ and I suggest you to take a look on it. I like one statement in the foreword very much.

these are just tools, and what you really want to do is have a full toolkit, understand the strengths and limitations of each tool and how to use them all.