Scheduling work in Kanban

Size: px

Start display at page:

Download "Scheduling work in Kanban"

Mildred Armstrong
8 years ago
Views:

1 Scheduling work in Kanban 1 Background The need for scheduling arose, in our context, from several separate stakeholders wanting to know when we, software development, will be working on features that are of interest to them. Their underlying need was coordination of other aspects linked to our work, such as marketing, legalities and resource reservations. Initially having a schedule linked to calendar time seemed like a really bad idea. We feared it would lead to stakeholders seeing it as a commitment. We feared that the schedule would start pushing work to the developers, which would lead to poor quality. We managed to mitigate those risks and create a scheduling system that was considered successful by developers and stakeholders. This paper explains what we did. 2 The schedule The schedule is a week-by-week calendar that captures our current understanding on when we re going to work on a certain work item. Work items are plotted on to the schedule collaboratively with stakeholders. Their size is based on estimates done by developers. With collaborative and transparent scheduling we respond to stakeholders need for predictability and certainty. We make decisions transparent and improve their understanding of the process and work items. Figure 1: Illustrated example of a schedule

Initially having a schedule linked to calendar time seemed like a really bad idea. We feared it would lead to stakeholders seeing it as a commitment.

2 Scheduling work in Kanban 2 The schedule has two primary goals: 1. To create a mutual mutual understanding of priorities and their reasoning with stakeholders 2. To communicate the plan to those interested (e.g. developers) Physically the schedule is a board with post-it s (or equivalents), located close to your Kanban board, visible to all those interested, updated weekly through weekly meetings. The schedule is not a commitment. It s a best guess created collaboratively with all stakeholders. The schedule can, will and should change as events occur. Figure 2: A schedule in action 3 Principles The principles to apply when scheduling work are collaboration transparency pessimism Collaboration Collaboration creates ownership. All stakeholders value the schedule more when they ve been involved in creating it. Having all the relevant people present also enables us to deal with conflicts, dependencies and other issues immediately on the spot.

developers) Physically the schedule is a board with post-it s (or equivalents), located close to your Kanban board, visible to all those interested, updated weekly through weekly meetings.

3 Scheduling work in Kanban 3 Collaboration is key in communicating the reasoning behind the schedule. Previously, explaining to a stakeholder why a certain work item would be worked on only after 1,5 months was difficult, time-consuming and hardly ever reached a common understanding. When we create the schedule collaboratively, the reasoning is communicated in the process. The collaborative sessions are also great for explaning the ideas behind the schedule and emphasizing that schedule is not a commitment. Transparency Since we plot the schedule collaboratively, all the decisions are transparent. The resulting schedule, its reasoning, and the items on it are understood and accepted by everyone involved. Having the schedule visible allows people to spend time investigating the schedule by themselves. People might spot things that went unnoticed earlier. A visible schedule also creates a sense of direction. Pessimism In general, I m all for optimism, but when scheduling work I recommend pessimism. Pessimistic scheduling means scheduling work according to the upper boundary of the estimate. If you have an estimate that says the work will take 2-3 weeks, you schedule it for 3 weeks. If you happen to finish early, most stakeholders will be delighted. It s the delays that tend to cause problems. All the teams I ve worked with have had the tendency to estimate optimistically. When we schedule pessimistically, we re nulling out optimimism in the estimates and the result is, hopefully, realism. However, even pessimistic scheduling will not make your schedule stick. As humans we are very bad at estimation. With some pessimism, the schedule will hopefully be a little more accurate, but it s still a guess. When communicating with stakeholders make sure to stress that the schedule is a guess based on estimates and that some surprises or changes in priorities are bound to spring up. Pessimistic scheduling will also reduce the pressure to overburden the Kanban system. Instead of overburdening, with pessimistic scheduling, we should either get more pull or slightly more slack. 4 Coordination with Kanban system Pulling work on to the Kanban board becomes fast and easy since we already know what should be pulled - the items that are next on the schedule. The schedule is not suppose to push work on to the Kanban board. The Kanban board s WIP-limits should prevent this from happening. If work has not been finished as scheduled, it s the schedule that changes. In fact, the schedule should create pull. When you move on to a new week, a week becomes available in the end of the scheduling window. This means we have a slot available to which we can pull work. One way of looking at the schedule is to see it as a ready queue.

When we create the schedule collaboratively, the reasoning is communicated in the process.

4 Scheduling work in Kanban 4 5 Getting started Agree on window of scheduling Window of scheduling is the window of time that you want to schedule for. My guess is that sensible windows range from two weeks to 5 months. If you can live with a less than two week schedule, doing scheduling like this is probably just overhead. Having a week-by-week schedule for more than 6 months means way too much work upfront. A good default value to start with is two months. This means that we have a fairly good sense of direction, but we don t spend too much time on things in the distant future. Estimate items Estimate work items with developers. I recommend using T-shirt sizes (XS, S, M, L, XL) which map to calendar time. We ve used the following mapping: T-shirt size XS S M L XL Calendar time 0-2 days 1 week 2-3 weeks 4-6 weeks, split? > 6 weeks, split! Estimation is a topic of its own. However, here s a few things to consider: How many items do you need to estimate? Estimating everything seldom makes sense. How much time do you want to spend on a single item? Using more time seldom creates better results. How many people need to be present? Having everyone present creates common understanding, but takes more time and effort. Plot items to schedule Plot the items on to the schedule based on your best guess and invite the stakeholders to have a look. Collaboratively revise the schedule together with the stakeholders to fit their needs. Ask developers whether the schedule looks feasible. 6 Weekly meetings I recommend having two weekly meetings, the stakeholder meeting and the developer meeting, each lasting a maximum of 15 minutes. I ve listed the agendas here to give a sense of things to look for in the meetings. They might not be applicable to your context so feel free to customize them.

Having a week-by-week schedule for more than 6 months means way too much work upfront. A good default value to start with is two months.

5 Scheduling work in Kanban 5 Stakeholder meeting Goal: collaboratively update schedule according to latest available information Maximum length: 15 minutes Participants: stakeholders, representative from development teams, facilitator Agenda: 1. Status of on going work? Any surprises? (Any details are to be discussed only after the weekly meeting with those interested.) 2. Any changes in priorities? Do they reflect on the schedule? If yes, agree on people who will update the schedule accordingly. (Do not update it during the weekly meeting.) 3. If week slots are available at the end of the schedule, decide on a time to figure out the next most important item, preferably immediately after the weekly meeting. 4. Are there any preparations that need to be finished before an upcoming work item is ready for development? If yes, talk about details after weekly meeting. Developer meeting Goal: communicate future plans to developers, minesweep upcoming work Maximum length: 15 minutes Participants: developers, representative from stakeholders, facilitator Agenda: 1. Any changes in the schedule since last week? 2. Are there any preparations that need to be finished before an upcoming work item is ready for development? If yes, talk about details after weekly meeting.

Any changes in priorities? Do they reflect on the schedule? If yes, agree on people who will update the schedule accordingly. (Do not update it during the weekly meeting.) 3.

6 Scheduling work in Kanban 6 7 About the author Sami Honkonen is a software development coach working for Reaktor in Helsinki, Finland. Reaktor works with customers who see IT as a vital part of their business. Reaktor is known for their expertise and for being fun to work with. Sami speaks at conferences frequently and blogs about software development and productivity. Blog: Twitter: Reaktor: Thanks to David Anderson and Hermanni Hyytiälä for their comments on the paper. Last updated: November 2, 2011

Sami speaks at conferences frequently and blogs about software development and productivity. Blog: http://www.samihonkonen.fi/ Twitter: http://www.

DESCRIBING OUR COMPETENCIES. new thinking at work

DESCRIBING OUR COMPETENCIES. new thinking at work DESCRIBING OUR COMPETENCIES new thinking at work OUR COMPETENCIES - AT A GLANCE 2 PERSONAL EFFECTIVENESS Influencing Communicating Self-development Decision-making PROVIDING EXCELLENT CUSTOMER SERVICE