I'm a huge fan of retrospectives. When consulting I found retrospectives to be absolutely required. An enormous amount of value was derived from expressing concerns and discussing the expected and actual impacts. However, I've also worked on a few highly functioning teams that never seemed to get the same value from retrospectives.
Highly functioning teams tend to address issues as soon as they are discovered, which is far better, but removes some of the value that is usually derived from retrospectives.
I don't like ad-hoc retrospectives, I prefer a routinely scheduled meeting. I favor the scheduled version because often it doesn't seem like a retrospective is needed and it's delayed too long. Delaying valuable meetings definitely doesn't seem like a good plan.
The problem is, on highly functioning teams we'd often end up in the retrospective with only 1 or 2 issues to talk about. Eventually the retrospectives would seem superfluous and be removed from the calendar. I've always been uneasy with disregarding something that's proven so valuable in the past, but you can't argue with removing waste. (where waste = loss of time)
On highly functioning teams, I've always worried that smaller issues were falling through the cracks and costing us efficiency. But, retrospectives seemed too expensive a tool to identify the smaller issues.
A few years ago I worked on a team that had an "issues" white board. Anything that annoyed you could be put on the issues board. Any time you ran into an issue, you would add a new issue, or put a + next to the existing issue if the issue had already been recorded.
The issues board gave us great visibility into things that bothered the team. Adding plusses gave us a good gauge to see which issues were the most annoying. If something was annoying and encountered often, it would quickly gather severals plusses. However, if something was annoying, but extremely rarely encountered, it might not make sense to invest the effort necessary to address the issue.
As an example, if a test has a race condition that causes the build to fail 5 times a week, it's probably going attract plusses quickly and signal the team that the race condition needs to be addressed. Conversely, if the race condition causes the build to fail once a year, and it would take substantial effort to fix, it's not likely to get '+ support'. And, any issue without + support is probably not worth addressing. Usually, issues with little + support are removed after it appears that the ROI isn't positive on addressing the issue. If the issue pops back up it can easily be added back to the issues board.
The first time I used the issues board it was in conjunction with retrospectives; however, these days I find the issues board to be a great replacement for retrospectives on highly functioning teams. I view the issues board as a continual retrospective that can be modified at any time. You also get the added benefit of providing a real time view into what currently slows or stops progress on the team.
Replacing retrospectives with a continual retrospective isn't something I'd recommend under normal circumstances. Like I originally said, I find retrospectives to usually be extremely valuable. However, if the value of retrospectives seems to be negative when compared with the value of time, then a continual retrospective is probably better than no retrospective at all.
Jay,
ReplyDeleteAnother technique I've seen work very well for both new and high-functioning teams is a "tip jar" for problems as well. Line up as many as you need (broken build, environment issue, code smell, etc.) or consolidate them into one jar.
Once you have your labeled jars, place them in an easy to reach and visible spot like your whiteboard example and put a "tip" into them. Once the jar is full enough (the team decides when that is), take it out and have a meeting/drink about how to fix it.
Depending on the team, you could make these either positive or negative reinforcement. A team member that breaks the build might need to add in a dollar every time they break it. The key in that case is not to punish each individual case too much so people won't be afraid to do good activities like checking in often, but become significant enough to see over time.
Positive reinforcement could take the form of everyone else on the team contributing a quarter every time a critical bug is found before pushing to production for the QA team.
The possibilities are endless, it just matters what you want to measure. Remembering the rule that whatever gets measured, gets managed.
The tip jar method usually satisfies the "waste" crowd and gives everybody a nice information radiator to talk about.
Joe Homs,
ReplyDeleteThat's a VERY interesting idea. What do you think about this combination of your idea and Jay's: There's a tip jar for every problem that annoys you. Everyone that's annoyed by the issue puts into the jar they care most about (or they have to put in every time they break a build, etc). The person who fixes the annoyance gets the money in the jar.
This would add big incentive to FIX really annoying issues and less incentive for less annoying issues.
Hey Joe,
ReplyDeleteThanks for the idea. I'll have to try that sometime.
Cheers, Jay
@tieTYT - I've used that very idea with a client and they loved it, but I found that I had to up the dollar amount put into some jars because they were "hard" problems.
ReplyDeleteMy focus is really on the team solving problems, but calling out individuals can work too. It just depends on the makeup of your team.
Arlo Belshee talks about having a jar where people throw "Glad", "Sad", "Mad" cards. Throughout the week, whenever someone has an emotional reaction to something they write it down on the card and put it in the jar.
ReplyDeleteEmotions are an indicator that it is "retroworthy".
I could imagine the team writing it on an appropriately colored sticky, and putting it on your board.
Dig it.