meetings_how_to
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
meetings_how_to [2020-06-01 14:58] โ suggestion of recording ev | meetings_how_to [2020-06-01 20:15] โ [Actual content follows] Simon | ||
---|---|---|---|
Line 24: | Line 24: | ||
* Meetings should have a purpose. | * 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/ | * 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/ | ||
- | * After the meeting has finished, create | + | * Create |
* Discuss this action list at the start of the next meeting if there is one. | * 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. | * 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. | ||
Line 35: | Line 35: | ||
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. | 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. | ||
+ | |||
+ | === Think Problems === | ||
+ | * Understand the problems in detail before considering solutions | ||
+ | * Listen to all stakeholders, | ||
+ | * 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 ===== | ===== Bibliography ===== |
meetings_how_to.txt ยท Last modified: 2020-08-10 09:26 by river