![]() ![]() With a lightweight activity like this, where the other participants are providing most of the data and discussing the groupings, it’s not too much of a burden. Like many distributed retro techniques, this relies on one person driving the shared screen. Once you’ve aligned the Sticky Notes around the boat, colouring them also helps. The team can identify what went right, what went wrong, and what impediments they are facing. The template provides a fun, interactive, and easy way for your team to reflect. It sounds simple, and for this technique, it worked really well. Retrospective: We are sailing The purpose of a retrospective is to inspect and adapt concerning individuals, interactions, processes, tools, and quality. Using the Sticky Notes application, I would capture each idea as it was raised on a new note, then locate it appropriately over the image on my desktop. We’re in a Windows 7 environment, so I ran a screen-sharing session with the Sailboat as my background (and a nice clean desktop). I flexed my Paint skills to the max and sketched out the boat below, feel free to use it yourselves.įirst off, we all dial into a conference line. Rocks ahead – what risks/dangers are coming up?.Anchors – what is slowing down/dragging on the project ?.Sails – what is making the project faster/better ?.It’s essentially a visual collaboration game where you place issues around it to signify: It is also fairly simple to understand, requires minimal preparation, and overall is a great introductory technique for teams unfamiliar with regular retrospectives.įor those of you unfamiliar with this retro technique, there is a picture of a Sailboat. I like the Sailboat retro technique as it’s very good at gathering data and quickly grouping it. Some of these things worked well and I’d like to share them. Why? Well I’ve been working on distributed Agile teams almost exclusively for the last 5 years and have tried many things to make the team feel more inclusive, work better together, and ultimately be more effective at delivering software. It’s not an in-depth study of the retro techniques, rather notes and observations on how well they worked with a distributed team (and what changes can be made to help). I’m hoping to catalog some techniques I’ve used to run distributed retrospectives (and possibly other activities like stand-ups, planning, pair programming, etc) in a series of posts under “Distributed Team”. However, sometimes, for reasons outwith our control, you end up with a distributed team. Co-location just makes things easier and distributing people makes it all much, much harder. I think that the same applies to distributed teams. Martin Fowler states that the first law of distributed objects is: don’t distribute your object. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |