Over a million developers have joined DZone.

Development practice: Retrospectives in Kanban

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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?

Stop-the-Line

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!

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

Published at DZone with permission of Michael Dubakov, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}