Tag Archives: stand-up

Daily Stand-up is About the Future not the Past

In the last couple of weeks, I was thinking a lot about daily stand-up meetings for two particular reasons: first of all, the meeting I was attending was inefficient, and second, something bugged me with the whole concept. We were following the structure introduced by the Scrum framework: every member talks about what she did yesterday, what she’ll do today and what is blocking her from achieving her plans.
What really bothered me was the first question: “what did you do yesterday?“. If one works with a co-located small sized team why should one talk about the past? Talking about the past is a waste of time, or if it is necessary then something is wrong with the organization: people work together and they have no idea what the others are doing. Unfortunately, we talked a lot about the past. Management was interested in the past, so during the last months the whole meeting turned into a sync meeting, where we gave a report about our activities.

The sad thing is that we are always one day behind. Quite recently during a stand-up, a colleague of mine talked about an interesting database change. He implemented a workaround and gave us the highlights during the daily stand-up. I remember clearly that he got very good and usable feedback on a real implementation, not a workaround, but since the change happened in the past and it would have taken too much time to change it back, nothing happened and the workaround stayed. If he had mentioned this before, we wouldn’t have had to live with a workaround which will cause a lot of trouble later. This is the price we’ll pay later for living in the past. Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (7 votes cast)

Kanban on Organisational Level

A couple of days ago, I talked to the head of an organisation, who was having a hard time to get an overview of the current work of her organisation, and struggling to have enough manpower in order to deliver products in time. This is a common problem, I had talked to other leaders who had the same issue, and in fact I was in a similar situation before myself. As a solution, we introduced Kanban on the organisation level.

The Problems

Before jumping into the middle, let’s have a look at the problems which triggered this introduction in my case:

  • Missing overview of the ongoing work items
  • Not enough manpower to deliver

Why is it hard to get an overview? It is a very good question indeed. Usually the head of an organisation – later on in this article I’m going to refer to her as leader -, has to deal with several things during the day, and it is very easy to lose track of the recent events, which may change on hourly or daily basis. Usually she only gets back into the picture when something turns south, but usually by then it is already too late.

In a healthy organisation, everybody is working on something, but for how long, when will it be finished, how much effort has been spent on it? These are also very good questions, and usually one has to dig quite deep in the organisation to find the answers. These answers are crucial for acquiring new work items into the organisation. Unfortunately, they are very often incorrect, and takes time to get them, so leaders take new work items based on inaccurate data, and then the organisation becomes overburden.

I truly believe that using a Kanban system can help solve such problems. Let’s see how.

Read more »

VN:F [1.9.17_1161]
Rating: 9.0/10 (1 vote cast)

Daily Stand-up Variations

During the last few years I did different kinds of stand-up meetings in Scrum and in Kanban teams. In this post, I’m going summarize the pros and cons I found in them.

The most common stand-up meeting style is the daily scrum. In this meeting, the ball or a stick goes around round-robin style. The participant holding the token tells the team what she did yesterday, what she will do today and what blocks her from continuing her work.

  • Pros:
    • Well documented methodology
    • Works fine for beginner teams
    • Works fine for small teams (4-6 people)
  • Cons:
    • Gets boring after a while, people may pay less attention after a couple of months
    • The information content of the tiny monologues decreases over time
    • The blocking issues are usually forgotten, or handled with less priority
    • Usually, the scrum master has to ask about blocking issues directly in order for them to be discussed
    • The three questions give the possibility to talk about activities outside of the team, which aren’t relevant in 4 cases out of 5

A less common variant is when people talk about the tasks, not about themselves. Go task by task from right to left, top to bottom – this is the priority order. First, talk very shortly about finished the items, then about the ongoing ones, and if there is some time left, talk about the upcoming items.

  • Pros:
    • More focused discussions
    • People pay more attention to the task details
    • Less unnecessary discussion
    • Works fine for large teams (7-10 people) as well as for small teams
    • No more round-robin style
    • If someone has nothing to say, that means that she did work outside the team, which is a waste from the team’s respective. If this happens regularly, it must be handled.
  • Cons:
    • The blocking items still get less focus
    • If someone from the team has lots of duties outside of the team, she will feel frustrated because she cannot tell the others what she is doing
    • Needs more time to learn and adapt to

Kanban teams tend to talk about only those tasks which are blocking the flow of the value stream.

  • Pros:
    • Real focus on the blocking items
    • Works with very large team setups (10-40 people)
  • Cons:
    • Does not favour team work. If one does not talk about the ongoing tasks no one can join in on that particular task
    • Requires a lot of experience, not recommended for beginner teams

Based on the pros and cons, I finally found the setup which works quite well for one of my current teams and for me:

  • Start with the blocking tasks from the parking lot, tasks with stop signs and tasks from the impediments column
  • The team should try to solve them on their own, and immediately escalate when the issue has gone out of the team’s reach
  • Continue with the tasks from right to left, top to bottom
  • Talk about activities outside the team, and about general issues
  • Optional design or task related discussion after the stand-up meeting

This kind of setup needs a one or two week long learning curve, because although most of the blocking issues can be solved by the team, the discussion takes some time and, by the book, we have 15 minutes for the whole thing. This method works well for middle sized teams with 7-11 people, too.

VN:F [1.9.17_1161]
Rating: 6.7/10 (3 votes cast)

Never Move Items Back on a Kanban Board

I’ve been doing Kanban for a while now, and I get the following question almost on a daily basis: Zsolt, can I move this item back on the board? My answer always starts with “No”, and continues with “why would you like to do that?” In this post, I’m going to describe a couple of cases you may find familiar. A common rule applies in every case: never move an item back, but examine why a particular item is selected, and how to avoid such situations in the future.

In most common cases, the question is asked when a column on the Kanban board is full, and a colleague intends to put a new item in the column, but due to the WIP limit, he can not. After realizing that the column is full, he looks through the current content and finds some items he would like to move back. He finds abandoned items in which the team invested only a small amount of work, and are now just there and taking up valuable space from other items. In the ageing items post, I talked about items which were left on the whiteboard for similar reasons.

Let’s have two different teams. The first team has a 8-10 days long lead time, but their priorities are changing almost on a daily basis, and the second team has a 2-3 days long lead time, and a quite stable priority list. In the case of the first team, the appearance of the abandoned items will be more frequent due to priority changes and resource reallocation. I would recommend them to find a way to shorten the lead time. If an item can leave the system before the priority changes again, it won’t be left on the board. In comparison, this team needs to solve the situation faster than the second team, because the abandoned item was once important for someone, who won’t be happy to get his item quite late or in the worst case, never. However, when it turns out that the item has become obsolete, just throw it away, do not waste effort on finishing it.

Read more »

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)