Agile Zone is brought to you in partnership with:

Michael is a founder of TargetProcess (agile project management software). His Mission is to provide solutions to real problems in agile projects. He wrote several books about web development and many articles related to almost all aspects of software development. Michael is a DZone MVB and is not an employee of DZone and has posted 48 posts at DZone. You can read more from them at their website. View Full User Profile

Development practice: Retrospectives in Kanban

11.29.2010
| 2870 views |
  • submit to reddit

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!

References
Published at DZone with permission of Michael Dubakov, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Emma Watson replied on Fri, 2012/03/30 - 3:56am

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.

JDBC

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.