meetings_how_to
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
| meetings_how_to [2020-06-01 15:08] – tkerby | meetings_how_to [2020-06-08 01:05] – [Avoiding Bikeshedding] river | ||
|---|---|---|---|
| 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 39: | Line 39: | ||
| 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. | 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 | + | See also: [[bikeshed|]] |
| + | |||
| + | === Think Problems | ||
| * Understand the problems in detail before considering solutions | * Understand the problems in detail before considering solutions | ||
| * Listen to all stakeholders, | * Listen to all stakeholders, | ||
| * Use techniques such as shadowing, brainstoming | * Use techniques such as shadowing, brainstoming | ||
| * Prioritise solving problems that are urgent, pervasive and valuable | * 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 | + | === Think Requirements |
| * Remember there are multiple stakeholders - anyone with an interest has a voice (e.g. suppliers, potential users, others with opportunity cost) | * 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 | * 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) | + | * 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 | * Remember specifications describe solutions and requirements describe problems | ||
| - | Think Emergence | + | === Think Emergence |
| * Understand how your solution works in the end application - how does it interface, what is its boundary? | * 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? | * 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 | * Identify how it may go wrong and mitigate those effects | ||
| - | Think Analysis | + | === Think Analysis |
| * Consider multiple possible solutions and analyse trade-offs against the requirements you have gathered | * 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 | * Iterate - start with simple quick proof of concepts and use them to learn | ||
| - | Think Validation | + | === Think Validation |
| * Validate early to identify changes and errors as soon as possible | * Validate early to identify changes and errors as soon as possible | ||
| * Constantly communicate with stakeholders in case their needs change | * Constantly communicate with stakeholders in case their needs change | ||
meetings_how_to.txt · Last modified: 2020-08-10 09:26 by river