Island: what functional requirements are most important - they should be positioned closer to the ‘shore’ to create priorities.Īnchor: what issues could delay the project. Rocks: what risks does the product face in terms of competitors, technical issues, user error? Once you know enough about your users, you can use Sailboat to plan the overall product or project. Instead, you need to do research and ensure that your product can solve a genuine need. You can’t, for example, just go into a planning session with ‘general ideas’ of what your customers want. We’ve written about this sort of thinking many times - but it’s so important we thought we’d mention it again here in the context of the Sailboat exercise. What solutions are most important in terms of priority. The sailboat system can also be used at the beginning of a project to help map out your strengths and weaknesses. While the Sailboat method is so often used in a retrospective fashion, we believe it has great value as an onboarding process for new projects and why it features as the first activity in our innovation workshop process. For an agency/client relationship, sailboating also helps both sides of the relationship feel they are aligned and heading in the right direction. It aligns the team and quite literally puts everyone in the same boat. The sailboat exercise is great because it’s a visual metaphor that is easy to understand. Outlining the ‘rock’ or future risk also helps you spot potential obstacles that should be dealt with before they become a problem and ‘sink’ the ship. For example, if there’s an anchor problem holding your team back, prioritise a way to remove it. Just like you would in an Agile sprint, you can use this information to pivot and enact change. Then see if there’s a common theme being suggested by multiple people as a delay. Once the team has had a chance to place their sticky notes, go through as a group and see if you agree on the placements. Rocks: the risks your project faces in the future as it reaches the goal.Īnchor: the problems and challenges which delayed the sprint/project. Wind in your sails: what propels your team/project forward. It can be the specific features designed in a sprint or a more operational-level goal. Once your team have created their answers as Sticky Notes, ask them to stick them to a graphic you’ve drawn or printed that includes the following elements:Īn island - this is the goal you’re working towards. The Sailboat in action at a KOMODO Innovation Workshop. Ask your team the following questions (adjusting based on whether you’re running this as a sprint exercise or at an operational level.) You can use a digital board such as Miro for this, or Sticky notes will do the trick if you’re doing it in person. It’s a visual metaphor and an exercise that focuses on the team and future direction.Ī sailboat workshop involves two main processes: the team writing down answers to a few questions and then mapping these answers against the ‘sailboat’ metaphor. If you’re planning to work in an Agile system, or working with an agency that utilises Agile methodology (hint hint, it’s us), then you’ll probably encounter the term sailboating.Įven if you’re NOT an agile organisation, the sailboating exercise can still be a great way to help rethink your projects and prioritise the production journey. One of the most powerful forms of retrospectives comes in the form of the ‘sailboat exercise’. It also ties into a Lean methodology in that a retrospective helps cut future waste. These are exercises performed after a sprint or project to determine efficiency and spot problems or issues so a team can avoid them in the future. This is often called an Agile retrospective. It’s a flexible way of working - hence the name ‘agile’, but it also encourages the concept of taking stock after a sprint to see what worked and what didn’t. An added bonus is that clients can deliver feedback after sprints rather than at the end of the ‘completed’ project.Īgile is a system of working, but it’s also a mindset based on promoting better interaction between the people involved in the project, the flexibility to change things when required, and focusing on working, functional product over bureaucracy. Then Agile came around and changed everything, decreasing the time it took to deliver working software and reducing the need for front-loaded documentation.īy working in ‘sprints’, development teams can focus on core requirements to build a product, while allowing for the ups and downs that come with developing complex technology. When developing a digital product, the classic process involved documenting requirements, designing solutions, and building and testing in a waterfall approach.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |