Kanban - Project Process

Introduction

At Appetiser we use two project development methods: Scrum and Kanban. Whilst these methodologies usually refer to project management only, they also impact how we work with clients and even their billing. 

Kanban has an emphasis on continual delivery whilst not overburdening the development team. Features are not developed in batches, but instead on a feature by feature basis sorted by priority. Cards are pulled from a backlog, for continuous improvement. Kanban allows more flexibility, as we can pivot instantly. This makes it a great fit for post-launch products, or tight deadlines. 

Scrum projects will often become Kanban projects once they are launched.

Difference Between Scrum and Kanban:

  1. In Scrum, the Project Manager will create a roadmap and breakdown the projects into Sprints. In Kanban, we don’t use Sprints but instead we continuously select tasks for development on a bi-weekly basis. 
  1. In Scrum, changes are not allowed mid-Sprint while in Kanban changes can be made anytime. This means Kanban priorities can shift daily. 
  1. In Scrum, clients are billed per Sprint while in Kanban they are billed per month. 

For a general overview of Scrum vs Kanban that is not 100% aligned with how we work, but can help you get started, you can review this: https://www.youtube.com/watch?v=rIaz-l1Kf8w

Start of the Project:

  1. The project manager will create epic cards and assign each to the developer
  1. The developers will unpack the project per Epic.
  1. After the development team is formed, the Sprint Master will schedule a kickoff with development team.

Development of the Project:

  1. User stories will be moved in batches to the Kanban board based on priority during standups.
  1. The development team will work on the highest priority item first, then to the next one according to the level of priority.
  1. On the first day or first standup of the week, the development team will move cards to TODO list. This will be the team’s focus for that specific week.
  1. In case the team finished all the task under TODO, they can just pull the top card under Backlog and start working on it.
  1. At the end of the week or the second standup of the week, the development team will discuss about what’s remaining in the TODO.
  1. If will or will they be not able to finish the cards during that week. 
  1. If not, explain why and discuss any impediments so the team can work out on how to solve them.
  1. If we are simultaneously running a marketing campaign, the Sprint Master should stay on the same page as the growth team to ensure that priorities are aligned. 
  1. If there are cards still left in Doing, the team should swarm on them. If you have run out of cards before the bi-weekly schedule, please let your Project Manager know. 
  1. Platforms don’t have to wait for each other. The web development team for example can work ahead.

Trivia

  1. The Sprint Master should make sure that all developers are constantly working on the project. No one must be idling. Since there’s no roadmap for the whole project and developers will only be working on the list of the tasks given, they should be proactive in asking for their next task.
  1. Given that clients are billed for time, developers should avoid working on other projects at any costs. If a developer gets assigned to other tasks, please let your Sprint Master know about the issue.
  1. Unlike Sprint based projects, kanban’s timeline is continuous. If the first invoice date is January 9 -  February 9, then month 2 will be February 10-March 10 so on and so forth. It’s important you use your time wisely, otherwise you are using resources that the company(all of us) will pay for.