A working multi-level Kanban framework

Agile and lean are supposed to transform your company by promising faster time-to-market, happier developers and greater productivity. Yet the devil is in the details, and a lot of companies fail to achieve this. How do you manage to let developers organize teams and pick tasks, while still having a strategic process for what to work on? How can you handle cross-team work without lengthy handoffs and ensure everyone buys into the process? At Rubrikk we run a highly customized Kanban process as our agile framework. This post aims to explain how it works for new employees and anyone else interested.

For teams, their Kanban boards are central to their workflow. Team leads are responsible for ensuring the shortlisted[1] column contains an appropriate amount of work. Unless team members have other instructions, they should be picking tasks from the shortlisted column whenever they are free for new assignments. For the team, the goal is to move anything on the board to the end column as quickly as possible. We use filters/highlights on tasks stuck in a column and work in progress limits on columns to assist us in this. The team lead is responsible for ensuring that everything on the board flows smoothly and escalating any issues.

At a strategic level, we use epics[2] to coordinate and plan chunks of work across teams, and we have a separate board for epics in progress. Each epic has a goal which includes an impact for the company, as well as an owner which could be anyone who can take responsibility for delivering the impact. Almost all epics involve multiple people from different teams.

Epic owners are responsible for organizing the epic; the scope of the epic, who should be in it, what tasks need to be done and who should do what, from planning to release. They are the facilitators of the epic, so they do not decide this on their own, but need to work with all the people involved in the epic to find a plan that works for everyone. They will receive guidance from the epic process manager (myself) to manage this. Epics need approvals from the team leads of the developers they require, and the owner must plan the epic according to available resources. Before any epic can start, the owner must make a time estimation and get approval from team leads and other stakeholders. The epic owner is responsible for delivering the goal by the deadline and pushing out status updates in a timely manner to the epic’s chat room. If the deadline slips, the owner will have to explain why in the chat room and make sure everybody understands why. A significant number of epics finish on time :)

Team members may receive approval from their team lead to focus exclusively on an epic and to move tasks from the epic into the shortlist on their own when they have capacity to work on them. The team lead should ensure that all tasks on the Kanban board are from epics in progress.

Teams also have maintenance epics. These are ongoing background epics for those tasks that don’t fit into a larger scheme, but still need to be done. Team leads may shortlist these tasks whenever it makes sense. For instance there may often be some slack for these tasks after a large epic finishes, while the next one is being planned. Other special epics also exist, e.g. repeatable release epics, or epics for collecting any broken tests which should be fixed with priority. Critical tasks may bypass the epic flow and go straight to the Kanban board. Team leads should know how much time maintenance takes for a team and consider this when approving requests for developers working on new epics.

Above epics we have another level called elephants[3]. These are collections of epics that cross multiple teams for a larger strategic goal. Elephants will have an elephant master to coordinate the epics in it. Only one elephant may be in progress at a time, and elephant epics have priority over other epics. There may also be series of related epics, e.g. adapting one component at a time to a new architecture, these typically have the same owner to coordinate them.

We are continuously working to improve the process, and automating as many steps as we can in it. Checklists for epic owners are automated, so is the approval process and bot updates and instructions in various chat rooms.

How we relate to some other common agile concepts

Retrospectives: The epic owner is responsible for organizing this as required, typically after an epic is complete.
Backlog review: We organize individual tasks by epics and then we review the epics for which ones we want to do. When deciding to do a new epic, we may sometimes look through related epics in the backlog to see if any other tasks make sense to do at the same time. We do not do backlog reviews for tasks, which means tasks filed without an epic may get lost in the backlog.
Story points: The epic owner plans the deadline, this may involve some parallel work between team members on multiple teams and some serial work (e.g. testing, release, waiting a few days for enough data points, etc). The use case for story points is relatively small and since epic owners are responsible for translating story points to man-days and calendar days anyway, they prefer to use time estimations all the way.
Standups: All teams have this. An epic owner may call for this for the epic group if there is a need. Elephant masters may use this at various points in the process.
Scrum: Our focus is on one piece of related work at a time, the time taken is secondary, this is the opposite of Scrum.
Scrum master: The role of an epic owner is similar in many ways to a scrum master, but for one epic at a time.
Kanban: We use Kanban at multiple levels, having independent just-in-time flow for tasks, epics and elephants.
Sprint planning: Epic owners typically discuss one-to-one with other epic members to plan the epic, but sometimes host meetings when discussions are required.

Rule of thumb for estimations

An hour: Just do it
A day: A task
A week: An epic
A month: An elephant
Typical epic estimation time is up to two weeks, but 3 weeks sometimes happens. At 4 weeks estimate the epic owner will be asked to split the epic into smaller pieces.

Update: Statistics for epics done in 2018 available here

[1] What we call shortlisted is often referred to as selected for development in other agile frameworks.
[2] We call them epics because JIRA’s epic ticket type fits well for our workflows. Many of our epics have a lot in common with stories in other agile frameworks.
[3] Elephants are often referred to as themes in other agile frameworks.

Photo by Simon Saw on Unsplash