Show all posts
5 years ago

Development practice: Retrospectives in Kanban

There are various ways to support agile team retrospectives. We’ve used all of them, so let me share our experience.

issues board

Cadence (usual retrospectives)

If you have iterative development like Scrum or XP, it is very convenient to run usual retrospectives meetings. For example, with 2-week iterations you have such meetings every other week, discuss issues, what worked, what not, brainstorm solutions and new things. We’ve tried mood boards, various formats for issues gathering and for action items tracking. We’ve tried a whole lot of things in 2 years. In general, it worked. But then we switched to Kanban and somehow retrospective meetings faded out…

Is there a better way to improve development process?


We tried to apply stop-the-line practice. It states that as a mistake or malpractice is discovered all responsible people should immediately hold a meeting to resolve/prevent this specific problem. There were several stop-the-line events, but this practice did not survive. Why? There are two main reasons.

  1. It is very disruptive. People are working on various unrelated tasks and are in the flow. Suddenly they should switch to a problem resolution brainstorming. Many people don’t like to do that.
  2. It may take too long. Sometimes the problem is very hard and it takes much time to find a good solution. People impatiently drink coffee and want to get back to work.

So we dropped stop-the-line practice and replaced it with a pure pull system.

Pull / Issues Board

Issue Board is a very simple concept with 3 basic rules:

  1. Every person in a development team can write a problem or a new idea he wants to discuss on a whiteboard (Issues Board).
  2. There is a limit of 3 problems on the board.
  3. When there are 3 problems on the board, we have a retrospective meeting right after a daily meeting.

We have been using this approach over the last several months and I like it most. It leaves off some problems both of the stop-the-line approach and the cadence approach. First, if there are no issues or ideas, there’s no need to have a meeting :) Second, no interruptions, since daily meeting is interruptive by itself, so it is just natural to have a retrospective meeting right away.

If you have other approaches to retrospectives, go ahead and share them!

Create a free account
Over 6 000 teams in 80+ countries
start their day with us. Welcome on board.
  • Pawel Brodzinski

    We use small, single-issue, informal, on-demand retrospectives. Well, maybe you can consider it as a kind of stop the line approach but it isn't that disruptive.

    Since we all sit in one room and we have” rel=”nofollow”>no-meeting culture every time someone sees an issue he starts a short on-the-fly discussion over the issue. People join the discussion either when they're interested or we need their involvement and we ask them to join.

    We're discussing just one thing so these retros are very short – usually about 5 minutes, hardly any of them lasts longer than 10 minutes. We always try to come into some conclusion/action point, even when it is “we keep things as they are,” which sometimes happens.

    But the best part is this: when someone is on the flow they rarely put any attention to those retros unless they're directly asked. I'm not sure whether we learned that working with each other in the same room for a longer time or it is a typical behavior, but in our case it works great.

  • Diana Larsen

    Hi Michael,
    This sounds pretty cool for addressing (sets of) individual issues/ideas. How does it work for identifying and addressing ongoing patterns of impediments or for finding ways to sustain beneficial factors?

  • Michael Dubakov

    Well, different people write down different problems. Developers can write something quite specific, I can write something company-wide. We discuss and resolve various problems with different size. Sometimes it may be 30 mins meeting, sometimes it takes 2 hours.

    If you are asking about how we re-think whole company, then it is out of scope of Issues Board.

  • Diana Larsen

    I wasn't thinking you would take on organizational transformations. :) More about things that happen during the work of the team that affect process, quality or outcomes. Do you sometimes notice that an issue re-occurs in a particular way? Does that get written up as a new issue or…? Also, do you only discuss problem issues, or do you sometimes add things to the board that helped and you want to ensure continue? Next time we're both at the same conference, I'd love to talk more about how this works for you. As you can tell, I have lots of questions. :)

  • Michael Dubakov

    I can give you an example of items that were mentioned (as I remember them) on the board recently:
    1. Let's organize a mini-conference in our company. Dedicate 1 full day to sessions and workshops
    2. Last build took too much time to release. WTF?
    3. Stories sometimes are too large
    4. Ideas about our next company event
    5. Automated functional tests responsibility.
    6. Everybody should maintain automated functional tests, not only one dedicated person.

  • Andy Roberts

    That's interesting … it's got similarities to our process. Here’s how we do it.

    At our daily ’standup’ one of the steps (after we’ve reviewed the Kanban board) is that I ask if we’ve got any ‘wishlist’ items. This is the shorthand we’ve adopted for anything we wish would happen to make things better or anything that regularly gives us pain that needs to be addressed. Anything we come up with goes on the ‘wishlist’ which in our case is an AgileZen board with columns for each team member.

    Also, if anything arises during normal work that’s an issue that can’t be resolved without deep discussion, that too goes on the wishlist.

    Each team member looks after their own wishlist column and keeps the most important stuff at the top.

    Then once a week at our regular team meeting we review the top items from each list. We have a small team so there’s no defined process for item selection. Sometimes I pick one that looks important to me, often I ask the team (since we’re all looking at the same board) what’s the next most important item. The ‘product owner’ is part of this meeting, and as a result if we come up with an item that needs a fair amount of work, he can decide if it’s something that goes straight onto our Kanban board, or whether it’s an item that is put back to the product backlog to compete for priority with other work items.

    We address ‘wishlist’ items in under a week typically, and if items do get passed over in the team meeting, that’s fine, there was obviously more important stuff to be done. We don’t use the wishlist for true impediments or blockages, those are treated in a stop-the-line fashion, either fix on the spot or at the very least, escalate to the product owner during the daily standup. And any issues that come up during the week that we can resolve within the team with a few minutes chat or perhaps up to an hours action obviously don’t make it to the wishlist board either.

    This is working fine for us in our context, closing the loop in a week usually.

  • Bruce Onder

    I'd challenge you and the team to reduce cycle time on stories to 1 day. Use the Feature Toggle design approach if you need several stories to ship a feature.

    For #6 – definitely! On my new team, the whole team is responsible for the quality of the product and will maintain the unit tests, integration tests, and acceptance tests as a team.

    Great list!

  • Samantha Laing

    Thanks – I was just looking for a “fresh” approach to our Kanban Retrospective.
    Do you ever look at what is going well?
    If you only address problems – does this not lead to only noticing problems?

  • Michael Dubakov

    Yes, we are focusing on problems. I don't think it is bad :)

  • Mikalai Alimenkou

    Very interesting technique. From my experience retrospectives are more than just problems solving. Team members should appreciate each others work and discuss well done things too. Also there may be some introverts in the team and it is not easy for them to publish their problems. Special retrospective techniques help them to express their thoughts and open their mind. That is why I personally don't like “on demand” retrospectives. Rhythm is very good thing and it is helpful in most of cases. Only when your team is very experienced and team members feel free to discuss any questions then you really can use this technique. I want to add that not all retrospective participants may be available on demand. Team may be distributed, some team members may be outside for one day, etc. Rhythm provides everyone reliable schedule and they can plan according to it. Kanban doesn't suppress retrospectives and other useful practices so bring everything helpful from other methodologies and adapt for your team.

  • Ivan Font

    nice practice… but how would you do that with offshore teams….

  • Michael Dubakov

    I don't think it can be applied to distributed teams easily, neither any other retrospective practice. Live video session may help with big TV as a connection between offices.

  • Michael Dubakov

    No-meeting culture sounds great :) I like it.

  • Barry O'Reilly

    The project I’m involved in uses a risk wall. It is intended to make risk visible to the team and external project stakeholders. It aims to drive discussion on issues on a regular basis to ensure that action is been taken to mitigate future problems. The risk wall is a simple concept with two axis of impact and probability ranging from low to high.

    The wall has the following rules;
    • Anyone on the project team can write a problem or concern on a card to add to the wall
    • Before placing the card on the wall, a small huddle (2-3 people) should take place to define where the card should be placed on the wall relative to other cards currently there
    • During stand up the two highest risks will be discussed in terms of action that has taken place to mitigate the problem
    • As risks are dealt with the cards are moved to the approach position on the wall

    The wall then becomes a living artefact, highlighting areas of unpredictability that can be focused on and eradicated

  • Barry O'Reilly


  • Michael Dubakov

    Interesting visualization.
    How often you discuss risks on standup meetings?

  • Barry O'Reilly

    Daily. This drives out the resolution.

    We also assign the risk to individuals to ensure they are actively followed up and include completion dates if required.

  • Ilja Preuss

    I once worked in a team where we had a similar board. We still also did regular retrospectives and got value out of it.

Request a demo
Our product specialists will show you the beauty and power of Targetprocess 3 and help you to customize it for your process and business requirements
Request a demo