Edinburgh Hacklab

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== How to Meeting ======

This page is intended to develop a guide for how to have better meetings in the hacklab. Contributions are welcome.

===== Meeting facilitation training =====

Would you like to learn how to run better meetings? I (river) have been to a training session on this and found it worthwhile. It was run by someone who understands community organisations and was not unpleasantly corporate. If you would like to attend one please add your name below and if there are enough people I will organise it.

  * River
  * Marcin

===== Actual content follows =====

  * Consider that meetings and discussion have a cost in time and energy. What is the value of the point you are making compared to people's time? Could you use your and other people's time on something more important?
  * Worse is better. Consider the 80/20 rule. 80% good enough is good enough. It's not worth another 80% effort on the same thing when you could use the time for something else.
  * Appoint a meeting facilitator.
  * Develop your skills in meeting facilitation, and participation.
  * Try to see the bigger picture.
  * Meetings should have a purpose.
  * Send out an agenda ahead of time, so that the purpose of the meeting is clear to all attendees and they can come prepared if necessary. Ideally this should include a quick background paragraph/links on the topics.
  * Create a list of actions during the meeting and distribute to attendees afterwards.
  * Discuss this action list at the start of the next meeting if there is one.
  * Agree on a time limit in advance (eg an hour max) and try and stick to it: Better to have two shorter meetings with fresh people than one enormous mega-meeting that burns everyone out.
  * If someone starts discussing something unrelated, keep note of it, and politely ask to discuss it after the current discussion is finished. Make sure to actually do so though! (even if its just to get more information and add to the agenda for next meeting).
  * If you're presenting something, spend some time preparing in advance rather than going in "rambling". I actually found making myself write brief sets of slides (yes, //I know, slides, yuck//) made me much better. It forces you to consider the way you are communicating your point to others, as well as helping spot and answer common questions in advance. They also give a single place for people to refer back to later, esp if you've provided useful links to further resources etc.

===== Widening participation =====

It has been suggested (at one of the meetings leading to the draft comfort & conflict resolution proposal) that we could record the meeting as a 'podcast'. 

This might help widen participation as in 2020 we are not limited to text communications. However a recording would obviously need the agreement of everyone participating and possibly limited editing, rather like minutes do.

===== Avoiding Bikeshedding =====
Some general points on how to collaboratively solve problems. Key thing is to consider the problem fully before we all jump in with possible solutions.

See also: [[bikeshed|]]

=== Think Problems ===
  * Understand the problems in detail before considering solutions
  * Listen to all stakeholders, not just the loudest
  * Use techniques such as shadowing, brainstoming
  * Prioritise solving problems that are urgent, pervasive and valuable
  * Write don and communicate the problems - e.g. user stories, use cases, personas, problem statements

=== Think Requirements ===
  * Remember there are multiple stakeholders - anyone with an interest has a voice (e.g. suppliers, potential users, others with opportunity cost)
  * Document the problems as  requirements that can be validated against when considering solutions
  * Consider implicit requirements that are not communicated – and check them with stakeholders (e.g. tea must be in a mug)
  * Remember specifications describe solutions and requirements describe problems

=== Think Emergence ===
  * Understand how your solution works in the end application - how does it interface, what is its boundary?
  * Consider the environment in which it is operating and how it may interact - what negative or positive behaviours or consequences may emerge?
  * Identify how it may go wrong and mitigate those effects

=== Think Analysis ===
  * Consider multiple possible solutions and analyse trade-offs against the requirements you have gathered
  * Iterate - start with simple quick proof of concepts and use them to learn

=== Think Validation ===
  * Validate early to identify changes and errors as soon as possible
  * Constantly communicate with stakeholders in case their needs change

===== Bibliography =====

  * https://seedsforchange.org.uk/resources
  * All of "Yes, Minister", and "Yes, Prime Minister". (Available on youtube.)