Tweeting retrospective
There are many ways how to run a retrospective, not only the classic circle of what was good, bad and what can we improve, which from my experience gets doesn’t provide lots of call to actions. Also, it has it flaws as it tends to influence people into complaining about things that are really not that important to them. And it gets super boring over time.
The goal of a retrospective is to have a constant improvement process in the small iterations. For that you need to extract a few simple goals for the next sprint and make people accountable for getting them done. So how does the tweeting retrospective works?
Firstly, prepare your post-it notes and sharpies. There is a lot of action going on in agile process with those funny things so stock your office first. There is a few rounds in this retro so you need to have a facilitator who explains them and runs them.
Tweet
Spend 5-10 minutes writing at least 3 tweets (140 characters long message to the team) on the post-it notes about last sprint. You can use hashtags or tag people, just like you would do when using Twitter.
Code reviews went well thanks to @john
Had to reverted all the X changes #fml
Getting requirements for Y was hard cause nobody knew about it
After five minutes place the “tweets” on the board approximately in the timeline manner.
Give the team another 5 minutes to have a chance to reply to some of the tweets and stick them to relevant boards.
Code reviews took a lot of my time
@bill but we found that issue that would be disaster in prod
Finding common themes
When you have all your tweets on the board, get the whole team in front of the board and try to find common themes and group the tweets accordingly. A good example of the theme could be process, code quality, testing or communication.
You can put them into large circles and when you done with grouping let the team vote about two major themes they would like to discuss.
Call to actions
Now you have the two most important groups to the theme so the theme should first understand whether they were good or bad and try to find reasons for that. Maybe there is a lot of overhead in your development process that the team thinks is unnecessary or a change went well because of a good communication with certain business people.
When you identify those things, try to come up with calls to actions. A call to action should be reasonable small and well defined — improve the process is a vague call to action, but
After you have at least 2 calls to actions, find people that will be accountable for them for the next sprint and reflect on them in the future retrospective.
Conclusion
Running a retro is tricky and getting the feedback from the team is hard. Those meetings can get really repetitive and boring so experimenting with different formats is a perfect way to improve it. The important thing is to get a constant improvement in the team no matter how small it will be. Tweeting retrospective is fun and provides loads of useful information and it doesn’t take too much time. The whole process could be done in just 30 minutes in a reasonably sized team. It’s harder to do it in the distributed team, but only to the extent of having a electronic whiteboard.