Running Scrum or Kanban Doesn’t Mean You Are Doing Agile

Aaron Fan
Oct 8, 2018 · 9 min read

Looking back at the beginning of my web development journey, I have enjoyed programming, and have enjoyed creating everything about UI/UX. However, I have also hated the project managers, I blamed they are ones to make web development ugly, making users and the whole development team sad…

Until I got the chance to join CNNGo (former CNNTravel) as a contract developer, my views have changed completely. That is the first time I came across the concept about Scrum, the whole process is much more organised and makes a lot more sense to a technical person. Then I know that it was Waterfall making web development a nightmare, and of course, I became a Scrum believer since then.

After my CNNGo contract completed, I joined SCMP, a Hong Kong English media company. I formed a new web development team in this company and applied Scrum process. In the first few years, my role was a Scrum Master, and I thought I have been doing a good job. I did my best to ensure everybody is following the Scrum rules; training project managers to become a proper Product Owner; convincing senior management (leaders) to believe in Scrum, and such.

Unfortunately, it is not as smooth as I expected or would like it to be as we have more and more new projects in the pipeline. . It is then I realised there were some problems.

After reviewing the process many times, finally, I realised I have forgotten the most important principle of Agile. Agile is not only about breaking down stories into smaller pieces, that is just part of the process, the principle should be

start from basic, and focus on the highest priority issues


Just a basic concept of what is waterfall…. Normally we start with an idea of the project, then we will try to define all the project details from the beginning to the end. Then, we would divide task into different phases, estimate the development time, then complete the project and deliver.

This process sounds like it completely make sense. In fact, that is what we have been taught since we were kids. However, when we are talking about software development, it is very difficult to follow the plan. That could be due to hidden technical roadblocks, and most importantly, the market and people change rapidly. What we have designed may not be in-line with the user’s current need.


In Agile concept, the market or the users would drive the whole project, and we usually start with a rough idea only. First of all, we should quickly find out what is the most important feature that we should deliver.

Imagine the circle is our rough idea, and the yellow dot is the feature that we defined as the most important feature we should deliver first.

Let say, we are going to build an e-commerce website for selling clothes. We all know what a basic e-commerce website needs, therefore we already have a rough idea.

So now, what is the most important feature that we should deliver? One may suggest we need to build the shopping cart and payment mechanism. That sounds alright to an engineer, however, from users’ point of view, not matter being the customers or the shop owner, they would suggest the clothing catalog. With an online catalog, we can start promoting online, the owner can start selling and accept offline payment in the first stage. That’s pretty much enough to get the project started.

Just a reminder, we should not define all of the features in the beginning (as we do not need to). It is fine to just have a big picture and the framework of what the expected outcome of the project is, a general concept of everything. Trust me, details at the early stage is a waste of time.

The catalog should start as a simple one with a single image with some text description only. We can build enhancement features like photo zooming, changing colour or slideshow in the later stages.. This way, we can make sure the engineers can stay focus on the task, and the task can be done within a short period of time. The key of starting any new projects, is to start with something simple.

Blue: Done, Yellow: In Progress, Grey: Planned

Imagine the first blue dot is our first simple task: the catalog. The team will focus on this development, and get the task done first. We will release the initial product out, and collect feedback from users and stakeholders.

What the next step is would be determine by the users. For example, the next step could be users want to see more photos of the products; in that case, we could consider implementing multi-images with slider, and a zoom function. Perhaps, it is possible the users are already satisfied with a simple catalog. On the other hand, the user may find the payment method is not convenient. hence, we might start the shopping cart and payment development. Always remember, each new feature should start with a basic version. We would release each feature upon development completion. We would get feedback from the users, and then development enhancement would be based on feedback collected.

Forget About Prediction

Forget about prediction and brainstorming, we will never be able to predict things accurately. What we brainstormed in the beginning, may be totally different to the final product.

It sounds like I am saying there should not be any plan; No! The key is you don’t need a detailed long term plan, as things and people change very rapidly. A framework and a rough long term timeline for the project is enough to make sure everyone involved know what is expected.

So what’s next? With a good Agile mindset, you should pick your favourite Agile Framework. I personally have only experienced Scrum and Kanban, so I cannot comment the others, but I would like to give my opinions about Scrum VS Kanban.

Why Did I Give Up Scrum

I assume you have some basic knowledge of Scrum. If you have no clue what Scrum is, perhaps you can check out some short videos on YouTube.

In Scrum, we have the daily standup meeting, sprint planning meeting, sprint review meeting, and retrospective meeting. These meetings are all useful and meaningful, but there are two fundamental problem with Scrum.

First of all, in a Scrum project, it is about story points and sprint planning. Story points will become meaningless when the team is more and more familiar with their capacity and the project. However, if Everybody just sit there and give points to stories without even thinking in detail. It then comes to another problem with Sprint concept itself…

Say we have a 2-weeks sprint, and our scheduled deployment is at the end of each sprint cycle. Imagine just right after the start of a sprint cycle, the Product Owner discovers there is an urgent task that reflects the current market and needs to be launch immediately, what can he do? According to the Scrum rule, he will have to wait until next sprint cycle, and get that task deployed at the end of next sprint, which is almost four weeks. This timeline would not be acceptable to the users, so his only choice is to throw in a new story in the middle of the sprint. This action will upset the engineers for sure.

In the sprint planning, we need the full team to be there, otherwise it would only be the Product Owner and the senior engineers discussing the user stories. The others would need to understand the stories afterwards, and possible message gets lost in translation. Another critical problem would be about the product quality. Most of the stories’ development will finish near the end of the sprint cycle, QA engineers does not have enough time to conduct detail testing. Plus there could be some planned stories that has not been done yet, and engineers will use the dirty way to get it done. In that case, there could be even more pressure adding up for QA engineers. Since they will need to spend more effort, time and resources to test the rushed work. Even worse is that this will stack up more and more technical debt.

Therefore, I know it’s time to get rid of the sprint concept, and we switched to Kanban.

Why Kanban, and How

Kanban is basically a first come first serve concept with a “work in progress” (WIP) limit rule. Imagine if you go to a sushi restaurant with 2 sushi chefs; your sushi order would be a task on the Kanban board, and the 2 chefs are the developer, and they can probably make 2 to 4 sushi at a time, and that is the WIP limit.

A simple Kanban Board, the green cards are in progress tasks.

To put this up together, we can come up with this simple Kanban board. Don’t forget the cards in the Backlog column has to be prioritised as well, so that engineers will know what should be done next.

A Kanban team focuses on the WIP items only. Once an item is completed, then they will pick up a new item from the backlog. In this case, the product owner is always free to reprioritise the backlog items without disrupting the team because anything out of WIP will not impact the team.

There is still a problem, the chefs probably know how to make any sushi, but in software development, probably most tasks need some studying, research or even some POC.

In Scrum, we have a sprint planning meeting, where all the team members get a chance to understand each of the user stories. In Kanban, there is no such meeting, so what I did to replace this is I created one more stage, and we called it “Analyse”.

The structure of our Kanban board.

We further enhanced our board a little bit more. We added a To Do column with 2 sub columns, Analyse and Done. Whenever there is available resource, this person can either pick a task from the Done column, and start development, or pick a task from Backlog to Analyse.

The Analysing process is one of the most critical step, once a card entered this stage, the person responsible will need to find out all the details with the Product Owner, probably with the QA and some of the other team members as well.

We do not mind spending more time on this staging, the goal is to make sure we know exactly what to deliver and how. Please note that a card in Analyse stage also count as WIP.

Another important task during the Analysis stage, it is to break down tasks if it is too big. We need to make sure each card can be done within 1 or 2 days in order to make sure it can easily track and test each function.

We still allow Product Owner to prioritise the tickets from Backlog and To Do -> Done column. In this case, it can be more or agile and dynamic compare to Scrum.

We actually inherit some culture and meetings from Scrum. Our Kanban teams remains self autonomy, and flat style. We still keeps review and retrospective meetings, but we don’t do it regularly, only when the team feels that there is a need.

How do we tell when the product be delivered?

No, there is not such “to deliver a product” concept in Agile. Keep in mind that we need to deliver this first basic solution as soon as possible. We then keep enhancing and keep deploying frequently. It depends on your technology, if you are using PHP, it could be safer to have a scheduled deployment date, but if you are using compile language such as Go, it might be much safer to do deployment frequently, even few times a day, so CI/CD tools is needed.

I’m not saying that we are not going to tell the stakeholders when things are going to deliver, but only after the analysing process. We can then estimate by counting numbers to cards.

So far, we have been using this methodology for almost a year, and we don’t think we made a wrong decision. There are of course a lot of detail refinement , but it is fun. I hope my story could help.

Aaron Fan

Written by

Aaron Fan

Senior manager, Engineer @ SCMP

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade