Exercise: The (daily) standup

1. What did I accomplish yesterday?
2. What will I do today?
3. What obstacles are impeding my progress?

The combination of regular stand-up meetings, story-cards and a task-board seem to be a particularly powerful enabler for the other elements of Agile teams. What we termed the ‘task-board process’ confers both visibility and responsibility

“What I think about the task-board, and I feel it myself, is that the engineers have a hell of a lot more autonomy now. In what they do, there is much less control about what we do now, we pick things off the board, ourselves and we drive them ourselves right through to the end”

To start off we adopted the following guidelines influenced by one of Dublin's early Extreme Programming consultancy groups EXoftware - now part of emergn. The guidelines helped us start to get into the habit of having a daily stand-up and to avoid some of the weeds that inevitably sprout up around new organisational practices when they appear to start succeeding. The 'weeds' are things that others try to piggyback, slipstream, coat-tail onto anything that succeeds in getting people in one place and paying attention.

Rules of stand-up meetings as follows…

• One of the team calls the rest to convene the stand up meeting
• Everyone gathers at the task board (conference remote people in by phone or skype)
• No interruptions
• Keep story to less than 60 seconds
• Start story with StoryName
• Walk up to the board and point to the cards you are referring to.
• Ask for assistance if required
• All dialogs to expand in break-out meetings after the stand-up
• Each person must stand up to the task board and indicate the story-card they are describing
• Adoption of stand-up meetings will negate the need for the weekly opening meeting
• The last stand-up meeting of each week is the “big meeting”. It will be followed by the weekly group meeting (operational focus as per previous opening and closing meetings).

People can look at our rules and find faults or things to improve, indeed so did we and as a consequence the practice or flow of the meetings changes over time, sometimes for the good sometimes for the worse. Reading through Martin Fowler's reflections on daily stand-up meetings offers numerous points of comparison and critique for us to contrast, interpret and perhaps change our own practice (see link below).

Further Reading
Martin Fowler has given considerable thought to the dynamics, quirks, irritations, failings and other aspects of programmer stand-up meetings (martinfowler.com).

Exercise: Experiment with a research method

Exercise: Experiment with a research method

Materials:
Copies of the research method protocol template. Use the template to structure your experiment with one or more of the research protocols based on the cards from IDEO.

Choose at least one protocol, but even better if you try more than one, if you have the interest or time available.
Context:
Identify an object or context for field work. Possible examples include:

• Stairs
• Doorways
• Queuing in a café
• Anywhere with a queue
• Parcel drop services
• Anything with a touchscreen
• UCD directional maps online and on-campus
• Dublin Bus website 
• ATM machine 
• Train/LUAs ticketing 
• Supermarket Self-service checkout machines 
• Copier machines at the Copi-Print system 
• UCard Top-up 
• Printer
• Kindle or other E-reader 
• Brightspace (from student’s perspective) 
• Alarm System 
• Airport Self-service Checkin 
• Tesco’s Online Shopping website 
• UCD Library catalogue 

Time:
Schedule field study observations over several days.

Instructions:

1. Write your name and the research context on the form
2. Investigate and propose your own version of the procedure for the research method assigned to you. Base this procedure on readings or your own creative extrapolation of the description on the IDEO methods card.
3. Conduct a trial run of the procedure on yourself first, then involve another willing participant, and another...
4. Make hand-written notes, photos and recordings for later analysis.
5. Keep a record of evidence gathered.
6. Make an archive of data/records (paper sketches and notes, digital folder, website).
7. Present your findings and analysis at the next class.

Evaluation:

In class discussion of findings. 

Questions to ask:

1. Did you write the method protocol (recipe/steps)?

2. Did you identify a method reference (source literature/inspiration)?

3. Have provided a sample/example of data you gathered?

4. Did you try to analyse or interpret the data? (may need to apply some tool or technique)

5. What was learnt from it all? Did I learn anything? Can you decide if the method is feasible, practical, suitable for your project?

Research Protocols

Names and descriptions for the IDEO Method Cards (IDEO, 2003)
Ideo (2003) IDEO Method Cards: 51 Ways to Inspire Design. William Stout.

LEARN

Research Method	Description
Activity Analysis	A description of project relevant dynamics: actions, interactions, tasks, and objects of achieving goals.
Affinity Diagrams	Represent or diagram clustering of design elements with activities, goals, obstacles. Proximity, dependence and relationships
Anthropometric Analysis	Human factors or ergonomics to assess project relevant use factors.
Character Profiles	Personas. Archetypes of real people with real goals, lifestyle, behaviour, identities.
Cognitive Task Analysis	List, summary of all available sensory inputs decision points and actions.
Competitive Product Survey	Collect, compare, and conduct evaluations of extant and competitive products.
Cross-Cultural Comparisons	Personal accounts of differences in situations, behaviour and artefacts in different national or cultural settings.
Error Analysis	Capturing the things that actually go wrong in the project relevant setting.
Flow Analysis	The flow of information in existing and/or new system.
Historical Analysis	Identify trends and cycles of product use, customer behaviour, market, and practice. Relate to timeless goals
Long-Range Forecasts	Narratives of future scenarios complete with social and technological trends to predict behaviours.
Secondary Research	Summary analysis of existing sources and 3rd party data on project relevant areas.

LOOK

Research Method	Description
A Day in the Life	Catalogue a person’s whole day without necessarily focusing on project relevant aspects.
Behavioural Archaeology	Look at use, wear, the detailed arrangement or organisation of use objects in their use setting.
Behavioural Mapping	Map position, movement, and use of space over time.
Fly on the Wall	Observe in context without interfering.
Guided Tours	Ask the user to guide you through project relevant spaces and activities.
Personal Inventory	Ask the user to reflect on and describe the things they view as important or significant
Rapid Ethnography	Participate and experience it first-hand with the user for as long as possible.
Shadowing	Tag-along with people through the day.
Social Network Mapping	Notice the relationships between people, groups. Look for identity, profession, culture, and connections.
Still Photo Survey	Build up a visual record of key use and interaction moments over time.
Time-Lapse Video	A way of summarising activity over time, use of time, space, and location.

ASK

Research Method	Description
Camera Journal	A written and visual diary of project relevant circumstances and activities.
Card Sort	Organise cards spatially in ways that make sense. To expose mental models of device or system.
Cognitive Maps	Create a map of an existing or virtual space. The pathways they know and navigate, mental models.
Collage	Self created collage of arranged images. Used to help verbalise complex or unvocalised themes.
Conceptual Landscape	Sketch and juxtapose social and behavioural constructs from participants. People’s mental model.
Cultural Probes	A visual journal for participants to build up themselves. A self generated reflection. Gathered and compared across many participants.
Draw the Experience	Ask participants to visualise and draw the experience in their own way, with their own associations, order, relationships, theories.
Extreme User Interviews	Evaluate (ask) users at extreme ends of market (early adopters, power users, beginners) to highlight their issues.
Five Whys?	Ask “why?” in response to five consecutive answers. Expose/uncover deeper attitudes perceptions.
Foreign Correspondents	Elicit inputs from others (snowball sample) to build up varied cultural and environmental contexts.
Narration	Users perform tasks and achieve goals while describing aloud. Talk aloud protocol. Stream of consciousness.
Surveys & Questionnaires	Targeted questions to assess design, usage, interaction characterises and perceptions of users.
Unfocus Group	Gather a range of tools or materials and get diverse user group to create things relevant to the design or project.
Word-Concept Association	Users associate words with design. Cluster user perceptions to evaluate design features & concepts. Value and priority.

TRY

Research Method	Description
Behaviour Sampling	Snapshot people’s activities at different times. How do pervasive products intrude in your lives?
Be Your Customer	What is it like to purchase your product? Actual experience of searching, buying, consuming, disposing.
Bodystorming	Act out scenarios with many people, using space, place, sequence, queues, etc. Test performance in context.
Empathy Tools	Experience the range of users capability for involvement under real conditions.
Experience Prototype	Mock up a rough but workable prototype to simulate the experience of using the new product.
Informance	Act out scenarios observed in the field to interpret and analyse in the lab. Builds shared understanding and good for solution formation.
Paper Prototyping	Rapid paper based mock-ups that are manipulated to demonstrate functionality. To articulate design concepts with users.
Predict Next Year’s Headlines	Involve users in future design possibilities. Futuristic, wishing, unmet needs. Help separate what is needed now from what can wait.
Quick-and-Dirty Prototyping	Assemble a very rough mock-up of a new feature or product to help start and refine a design.
Role-Playing	Identify actors/stakeholders involved in design use, enact real activities in real or imagined context.
Scale Modelling	Simulation technique to test arrangements of space, place, context.
Scenarios	A character-rich story, to communicate (simulate) and test a plausible story in probable context.
Scenario Testing	Show depictions of possible future scenarios. Share reactions, refine concepts.
Try it Yourself	Like Microsoft’s famous ‘eating our own dog food’ being the first user.

General comments on doing field research

On learning about methods

On methods; I recommend you identify a published research example and adapt it. And look carefully at the example's own bibliography too. The methods literature is broad. You will take ownership ofdiscovering your methods' background, select an informing literature and decide for yourself about method suitability etc.

Each of us is expected to delve into the literature on the different methods available and on adapting these findings to our own topic. The reasons for this are various but primarily because research methods for product design and scientific studies is a very broad area with huge variation and there is no way to teach methods without limiting or biasing your own research journey (see comments below on the overuse of surveys and questionnaires). Educationally I expect each researcher to identify, study and develop expertise in the methods they employ. By taking ownership of this you become authentically involved in the process of professional and scholarly research. You will discover the background to various methods, select the publications that inform your own research design, decide through experimentation what methods are suitable and feasible for your own research context.

Some comments by way of general orientation to a research exercise:

• Be curious and open to discovery
• Goal oriented analysis often yields interesting findings.
• Be open to identifying insights, deep insights, particularly "what I learnt".
• Look out for the unexpected, things that are puzzling, aberrations. 
• Self-reporting can be hugely insightful, this can be researcher self-reporting or respondent/subject self-reporting.
• Don't get side-tracked by 'annoyances' when there is an elephant in the room.
• When making recommendations or advising on solutions
• Contrast with comparable experiences, goals, solutions from other industries.
• Contrast with completely incomparable solutions from completely different settings.
• Avoid 'selling' a new tech system as if it is a holy grail or nirvana solution. All tech systems have their failings, you may simply be changing the source of your pain, not taking it away.
• There is huge value in a quick-dirty prototype. 
• Use paper sketches, paper prototypes, mock-ups, from low to medium to high fidelity.
• Design ideas (sketches, mock-ups, prototypes) are used for feedback, for learning.
• If a design proposal is quite narrow, if so then it must be very focused, well argued, and insightful.
• NO DANCING BEARS! For an explanation see Alan Cooper's book "The Inmates are Running the Asylum" (search link)
• Respect your research subjects' privacy-identity
• It's generally seen as good practice to anonymise your interviewees if putting information in the public domain unless it is absolutely necessary for some reason.
• I recommend redacting personal identities from reports and papers.
• Be aware of copyright and attribution
• You cannot post other people's copyright material online.
• If you 'copy-paste' content from someone else make sure you surround it with quotation marks and include a citation or attribution.
• Do please make posts on your websites that are your own writing. 
• Be aware of and comply with copyright law and conventions for fair use, attribution etc.

On Surveys and Questionnaires

I am not particularly interested in student projects that use surveys or questionnaires as the main or even as supporting research methods. 

Surveys and questionnaires are a tertiary research method and rely on the laws of large numbers and/or access to large representative population pools. Survey/questionnaire methods are explicitly closed-ended in that they imply limited sets of allowable data/responses. Unfortunately these methods are rarely accompanied with a necessary introspection by the researcher of prior assumptions, or reflection/statement of researcher's epistemological/ontological assumptions that may skew or predispose the design of data collection to produce implicit results. A research design may in fact generate (produce, reify) the very objects it seeks to reveal.

It is also rare that we see well justified and well designed questionnaires or surveys. In fact these methods require that that the researcher has already studied (through literature review) or actually conducted extensive primary empirical research and/or carried out medium scale studies before resorting to survey/questionnaire. The findings of prior studies provide the justifications for determining what, why and who to ask. There will be clear connections between foundational research findings and the very design of a survey/questionnaire instrument. The content and sequence of each question is there for a valid research reason. The method is an inherently closed style of questioning and is therefore a kind of 'forcing function'. It produces limited responses responses to focused questions and therefore carries the risk that you will only detect what you expect to find, the method is quite literally self-determining and often results in poor science.

The design of surveys and questionnaires must needs be subjected to scrutiny, refinement and quality checking in order to avoid problems ranging from avoiding leading questions through to establishing construct validity. For example, is it essential for the research that you capture the respondents gender? Why? Is this justified? If so how many categories are you providing? Male/Female? Does the respondent have to answer or can they opt out? If so how does this affect the data and your analysis of it?

Surveys and questionnaires have their uses, for example where the concepts are well defined, not subject to misunderstanding (ref. construct validity), and the questions being addressed can usefully be asked of a large sample population. Therein lies my last bugbear with survey/questionnaire, sample size. A survey with 8 respondents is technically useless unless the whole population is 8. Statements based on small sample sizes are likewise in general useless unless you are sampling small absolute populations. Plus, survey responses are often presented in ways that mislead us as to their significance, for example, "100% of survey respondents answered yes" creates a different impression from "8 survey respondents answered yes".

So when does a survey sample size reach statistical relevance? The answer to this question depends on the margin of error threshold you seek to pass. Notice when talking about populations we generally refer to the sample size, a subset of the population. The implication being that we don't expect to be able to contact every single member of a target population, merely a subset. So what sample size do we need to reach to make reasonable inferences about the entire population? The margin of error or confidence level desired are in fact functions of population size; see "survey population/sample size calculator" for further information.

Survey population-sample size calculators

The Difference between Citing References and Field Data

References and citations should relate to the subject matter being written about. Field data and interviews etc. gathered from a field study site does not constitute reference material in the same way; in this case a quote from the data is simply data not a citation. Similarly survey results are only included where relevant to the arguments or analyses being made, the entire survey with responses should not be appended to the paper. Research instruments and the gathered results may, if desired, be included in an appendix at the end of the document.

Personal Reflection

1-page appendix item "Personal Reflection"

The aim of a personal reflection is to give the student an opportunity to relate a personal understanding of the course. To highlight not just the described learning outcomes but also draw attention to challenges and areas of difficulty. Think of it as a statement of what you determine to be the key learnings and contribution of the course. It can be critical, highlighting gaps etc. Ultimately it is a personal statement of your own (perhaps new or changed) perspective on the subject, new understandings, difficulties, and insights.

Grading criteria:

The Personal Reflection is authentic, critical, supported by evidence and descriptive, conveying your own personal learning insights.

• A single page, approximately 500 words.
• Is it original? Is it your own work? (this is a basic requirement)
• Are the insights and learning described authentic? Does it honestly communicate your personal learning on taking this class?
• Is it critical? Critique isn't a bad thing. It challenges your own and others, even the subject itself. Consider prior understandings, misunderstanding, new knowledge, or changes in understanding?
• Are statements supported with examples? For example, comments or reflections on the homework tasks, the project, themes and subject matter?
• Core concepts? At the very best the reflection offers a compelling account of the significance of some of the key ideas arising in the course.

On the subject of research writing, methods, data, analysis, assumptions...

On the subject of research writing, methods, data, analysis, assumptions... Some ideas for structuring your own research ideas, and useful tips about research design.

Working Title: Initially, phrase a research question as the title of the paper (you can change it later).
Abstract: Restate and expand on the research question in the abstract (you can change it later when you have analysed your findings).

Research Access: Make good use of your personal access to your contacts, projects or companies, past or present for providing data.

Gather data and working backwards:
What I mean by this is that you will almost certainly end up changing/revising the research question as you go along, and the abstract will need to be revised at the end. The working title and abstract written at the beginning was just a first stab at the paper.
A research question is a prerequisite and precursor to a research project. Having a question puts the focus on a few things; the kinds of data you might expect to gather which could be anything from interviews, observations, documentary/documents, to literature review/desk research etc. etc.
A (tentative) research question usually implies particular kinds data, so ask, what kind of data does the question imply? What constitutes evidence for the phenomena under investigation? What data will (or might) provide the kinds of evidence that could be used to make justifiable statements about the research context?
A clear idea of the kind of evidence and data sought leads us to consider the types of data capture methods (research methods) that can be used to produce data or the evidence sought. This in turn indicates a typical overall research model, research design and research approach. Sometimes a programme of research will involve many of these approaches. For example, literature review, a distinctive family of desk based text research, is generally a prerequisite for all other research activities; evident in an introduction or positioning section of a paper, or constitute the whole research project itself. In very general terms, the gamut of research designs or models includes - but is not limited to:

Essay: Purely theoretical, elaborating a conjecture, speculation, conceptual, philosophical argumentation, thought experiment, word games, word play, rhetoric, logicism, formalism, constructionism.
Review, meta-analysis of prior research, selective literature review, systematic literature review.
Empirical: descriptive, idiosyncratic, case-study, naturalistic observation, questionnaire survey.
Correlational-causal: studies adopting systems model views, inputs factors, outcomes, case-control study, observational study, survey, structural equation modelling.
Statistical meta-analytic: research derived from other research, findings based on aggregations of other research.
Semi-experimental: research styled on intervention in settings, field experimentation not amenable to laboratory control, quasi-experiment, trials, living labs.
Experimental: classical closed system model of scientific discovery, reproducible experiment, blind experimentation, random assignment experiments.

(partially derived from the Wikipedia article on Research Design):

These various research models involve or require differing philosophical commitments and assumptions or beliefs around the nature reality and the world (worldview, ontology), and of the nature of knowledge (epistemology is the theory and nature of knowledge; objective, subjective, social). Usually it is sufficient to simply acknowledge the stance adopted for the purpose of the research, be it: interpretive, critical, critical realism, naive realism, post-modern, deconstruction, construction, positivist, aesthetic, utilitarian, speculative, qualitative, quantitative.

Improve the draft:

Commence your paper with an introductory/positioning piece that incorporates a short selective review of relevant recent literature critically addressing the topic areas you are working with.

Provide a presentation to peers or colleagues if possible, talking through your ideas, the data, your analysis and findings. Doing so will inevitably help refine how well you communicate the story, your message, convincing evidence, the key points, highlight your contribution and findings.

Use a Template

Start using a scientific conference template for writing up. I recommend you write using a journal or conference template. Two examples in the IS field below...

This is an example from the ECIS 2015 conference...

(http://www.ecis2015.eu/participation/submissions.html)

This is a pointer to the live HICSS template in Word format or in LaTeX format on the HICSS conference website. See the "Author Instructions" section...

(https://hicss.hawaii.edu/authors/)

The HICSS conference style in LaTeX is provided/shared via Overleaf. Overleaf is an online writing/editing service that uses LaTeX, the defacto standard for most scientific research writing...  

Further reading

Links to various related conference templates below:
A LaTeX and a Word version of an ECIS Template - from Muenster 2015 - recommended!!
A LaTeX version of an ICIS Template - Ryan Schuetzler - a bit gnarly. A Word version of an ICIS Template - it's Word :-(

Exercise: Estimating User Stories

This exercise demonstrates task size estimation using ‘story points.’ A story point is a unit-less measure of size and complexity for a story. More important than the estimate is the discussion the group has about the story. This activity helps a group understand what tasks and proposed solutions might mean/be before attempting to implement them.

Objectives
Understand the ‘planning poker’ technique for task/story estimation for high tech development project and to obtain useful estimates for (iteration) planning.

Prerequisites
Familiarisation with ‘user stories’ and the ‘story card’ method for capturing goal driven requirements.
Planning poker cards or index cards with range of numbers (?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, & coffee)

Instructions
Budget up to 45 minutes to run the whole exercise (for a class size of ~50). Arrange class into groups from 4 to 7 people.

1. Allocate 1” for everyone to read through the ‘local’ rules for planning poker below.
2. Discuss planning poker rules to clarify understanding.
3. Allocate 2” for everyone to read the scenario carefully (don’t make personal estimates yet).
4. 25” for planning poker rounds.
5. 15” for debriefing discussion.

(Local) Rules for Planning Poker; adapted from (Cohn, 2006)

1. The dealer picks up the next story and asks: “Ok, how many story points will this story take?”
2. Team members think about the story and come up their own estimates. Nobody speaks the estimate just yet.
3. Members place a card from their decks face down on the table, with a value equal to or close to their estimate.
4. When everyone’s card is on the table turn the cards over at the same time.
5. Each person explains what he or she thought the story required, maximum of 3 minutes discussion.
6. Taking account of new information the cards are played again (and perhaps again) until rough convergence is achieved or one developer’s proposal and estimate is agreed upon.

Discussion points

• Did you identify duplicate entries?
• How did you handle user stories that did not follow the “As a… I want to… so that…” pattern?
• Were some user stories too ambiguous to estimate?
• How did the teams make sense of the stated requirement?
• Did the teams seek clarification from the product owner?
• How were divergent estimates treated?
• Describe your ‘feelings’ about the process? Fair, political, honest, dominated, contentious, accurate, shared, personalised, ideas, support, attack…
• How did the team arrive at a shared interpretation of the estimated value?
• Did you attach a concrete meaning for the estimate figure? Dimensionless, people, complex-standalone, similar to or like something else, hours, days, small-medium-large, easy-difficult…

Online version

The online version we'll use is courtesy of PlanningPoker.com's basic free account access.

Register at https://play.planningpoker.com/plans and select the free account option

Only one member of the group needs an account. One member of the group sets up the planning poker session. Those invited should not need to register to play.

Enter the following stories:

First a simple test run...

Organise a class night out under Covid

https://play.planningpoker.com/play/game/xItYl4XolMNg93wpjLy39cHOHssGPvYn

Title: Organise a class night out under Covid

Description: As a member of the class I want organise a social event for the whole class that is fun and interactive and accessible so that we (as a class) get to know each other better.

Acceptance Criteria:

It must...

Involve the whole class

Conform with social distance norms

Be fun

Be accessible 

Be interactive

You provide a Wedding Planning Service

The couple wants you to plan and design a whole wedding experience.

How long will it take you to put together a proposal for the following...

• A wedding experience starting on Christmas Eve.
• Options for the perfect venue - a Castle in the West of Ireland.
• With accommodation and board for approximately 200 guests (around 150 arriving from abroad).
• Arranged airport to venue transportation.
• Providing three separate marriage celebration ceremonies running over three consecutive days, each in a different style: European, Asian, South American.
• Concluding with a morning reception on the last day.
• Offering high impact evening entertainment options.
• Provide Media Service and Management (socials, streaming, video, photography).
• Full Security offering.
• Provide optional sports and tourist activities over 3.5 days.
• Arranged airport transportation for departing guests.

Bridge Design Lesson Plans

• A. Five classic bridge designs 
• B. Bridge failures!
• C. Test stuff to destruction!

Title: A. Five classic bridge designs 

Description: As a teacher I want student groups to construct models of the 5 classic bridge designs so that they have practical hands-on experience of design construction challenges.

Acceptance Criteria:

Proposed lessons to be delivered in blocks of 45 mins for a sample group of students (teenagers).

Student group completes lesson for bridge type 1  in 45 mins

Repeat lessons for bridge types 2-5 each taking 45 mins.

Photographic outputs from each lesson.

Title: B. Bridge failures!

Description: As a teacher I want students to test the weight bearing capacity of different bridge designs so that my students will appreciate the applications for different bridge types.

Acceptance Criteria: 

A lesson plan for a 45 min class

Students to generate photographic evidence and scientific data relevant to bridge performance.

Title: C. Test stuff to destruction!

Description: 

As a teacher I want students to evaluate different building materials and relate them to physical design elements  so that my students will appreciate the suitability of material choices for different bridge elements.

Acceptance Criteria: 

Each proposed lesson to be delivered in blocks of 45 mins

Students to create a table of physical characteristics

Students to create a table of load characteristics

Students to create analytical maps of physical demands for bridge design elements

References
Cohn, M. (2006) Agile Estimating and Planning, Upper Saddle River, NJ, Pearson Education.

Exercise: Writing an Academic Article

Use technology to manage a bibliography, referencing and in-text citations.
This exercise introduces MS Word style sheets and References...

The following illustrative exercise uses the ECIS template on Google Drive (link).

1. Copy the template from the shared folder to your own computer.
2. Rename your file using the following pattern "Surname_MyResearchProject_YYYY.doc".
For example my own paper is going to be "HigginsEtAl_WorkingInVirtualLight_YYYY.doc". I have used the author convention "SurnameEtAl" as there are three or more authors.
3. From the MS Ribbon "Home" open the Styles Panel. The "Current style" field show the current text style wherever the cursor is in your Word file. Alternately navigate to top menu "Format>Style" for similar.

The current style at cursor location

4. Select section 1 "First level heading" and rename it "Introduction"

5. Paste and match formatting using following unformatted text as new paragraphs for section 1

Critical management studies appreciate that products and services, produced with technologies, by organisations, and the involvement of users, rely upon "actors having formal and symbolic resources for the exercise of... systematic forms of control over organisational participants, and indirectly over other groups and non-human objects"\citep{AlvDee2000aa}. The techniques and skill of management for producing digital goods and services (through software, hardware and systems) at its best aims to resolve this through the delicate, democratic balancing of power, control of resources, shaping of work culture, and leadership \citep{Kid1981aa}. The following brief introduction to the literature positions this study within the broad field of management information systems and seeks to inform further creative, design, and development initiatives.This study looks at...

6. Confirm that the paragraph current style is "Basic text"

7. Select the following text and change its style to "Subtle Emphasis". You many need to filter the style list selection at the bottom of the styles window.

“actors having formal and symbolic resources for the exercise of... systematic forms of control over organisational participants, and indirectly over other groups and non-human objects”

8. With the MS Ribbon "References" active...

Select the LaTeX citation command \citep{AlvDee2000aa} and replace it with the MS Word equivalent citation, i.e. from the References Ribbon select "Insert Citation". You may need to create a new entry in the Word file's Citations collection

Create a new citation source record

Enter a new source record as follows (n.b. add ", p. 7" to be thorough)

MS Word's new citation source editor

9. Similarly replace the LaTex/Bibtex command for Kidder "\citep{Kid1981aa}" with

Adding Tracy Kidder's Soul of a New Machine to the citation list in your MS Word document

10. Now regenerate the bibliography at the end of the draft paper by navigating to the "References" section, and selecting "Bibliography" to insert a new bibliography. You'll end up deleting the previous copy. You'll also need to reapply the style "Reference" to this text

n.b. the bibliography style-type (Harvard - Anglia) and the insert "Bibliography" command

For further background refer to the notes on the term paper at:
https://managingdesignanddevelopment.blogspot.com/2015/04/term-paper-and-presentation-guidelines.html

Writing styles: The term paper is written in an academic style, presenting your background reading, method, research, analysis, theorising and critiquing aspects, for example of the history, situation, processes etc of a particular sourcing context. Consider identifying an exemplary paper that you aspire to emulate or to compare your own paper with.

You must use the specified scientific conference template for the term-paper. Choose between either the LaTeX or Word template from the ECIS 2015 conference. Copies are available on (Google Drive link). By using and sticking with the ECIS template your paper will automatically conform with the scientific format guidelines for that conference.

Self-assessment for this exercise:

1. Did you upload the file (e.g. word file)?
2. Did you use the correct template?
3. Did you add a new source record into the document?
4. Did you insert a citation into the text of the document?
5. Did you regenerate the bibliography/references at the end of the document? 

Cultural probe method exercise

"Some complex design challenges involve people of different cultures, languages, and societies where traditional research approaches won't help us adequately emphathize with their experiences." (Battarbee et al., 2012: p. 7)

The cultural probe method encourages participants to make a visual journal and reflection of their encounter with a culture context/experience. Probes gathered and compared across many participants offer the possibility to provide both generalisable information and deep insights (potential for broad and/or deep learning).

The following exercise provides a 'flavour' of the method:

Suggested protocol to conduct a cultural probe as follows:

1. Take a trip to a local shop, market, or a specialist food store.
2. Purchase 1 inexpensive food item you never tried before (1x photo).
3. Research how to prepare it to eat or use it as an ingredient.
4. Follow the recipe to prepare the food and test it.
5. Write a paragraph-note summarising the exercise.
6. Findings: Captured in (at least) a 1+ photo and (at least) a 1+ paragraph-note.

Reflections from students:

"The homework’s cultural probe was an assignment that made me reflect on the concept of design empathy and the importance of investing yourself into new contexts and open your senses. The bad designs homework has for example made me look at the world in a different ways. I now notice things from a design perspective that I otherwise wouldn’t have noticed before."

"The cultural probe exercise was not a simple cooking exercise, for a first-time chef like me; it was an interest-oriented, research-based, process designed operation with excellent results."

Exercise: (b) Design a text-free search interface

Some hand-drawn ideas and doodles...

The goal of this exercise is to familiarise students with interface design approaches and tools. First by using pencil/pen and paper. Second by using the Balsamiq wire-frame tool to mock-up your design.

Objective
To practice creating design artifacts to display and test technology use/interaction ideas.

Material
A4 paper, pencil or pen.

Create an account on Balsamiq Cloud (no payment details are needed).

Log In to Balsamiq Cloud
https://balsamiq.cloud/#login

Instructions
1. Use paper/pencil sketch a mockup of a new kind of Internet ‘search page’ that doesn’t use text (at all)! (allocate 10")
2. Collect the sketches and display them to the class; allow the group to provide a brief commentary. (allocate 10" to display all mockups).
3. Next, use Balsamiq to create a digital version of the design. The new design may vary from the paper/pencil sketch. (allocate 15")
4. Discuss the following reflection points. (allocate 10")

Reflection
How did the quality and level of design discussion differ from the earlier exercise?
Comment on how you conceptualised or simulated the 'user' of your design.

References
Snyder, C. (2003) Paper Prototyping: The fast and easy way to design and refine user interfaces, San Francisco, CA, Morgan Kaufmann, Elsevier Science.

(other tools include: wireframe.cc, app.moqups.com, invisionapp.com, sketchapp.com, Axure, Justinmind, Marvelapp/POPapp and iRise)

---

Previous Student Examples

Dilyan's example: Fast booking mock up: Fast booking mock up

Whole class examples in collage:

Lean Software Development: An Agile Toolkit

Poppendieck & Poppendieck (2003) borrow the notion of 'lean' from Taiishi Ohno's Toyota Production System approach and adapt the system to software development. The guiding principle behind the idea of 'lean' software development is to eliminate waste in the form of inventory stock and piece work dwell times from any and every aspect of work possible. In borrowing lean principles and terminology, which were developed for physical goods manufacturing, how does 'lean' apply to software's 'perfect' manufacturing environment (perfection in this sense meaning to software's potential for its manufacture of exact copies of an original via digital copying)?

Waste is present in the guise of unnecessary formality and management overhead.

Extensive documentary efforts lead to waste, excessive communication (meetings) lead to waste, excessive processes, interruption, delays and defects all lead to waste in the software process.

Using the 'lean' model requires that we apply tests to work activities to establish their validity.
"A good test of the value of paperwork is to see if there is someone waiting for what is being produced." (Poppendieck & Poppendieck, 2003:5) They note that the most wasteful work around documentation efforts surrounds attempts to produce documents that "contain all of the information that the next person in line needs to know." (p7) Explicit documentation requires infeasible completeness; rely instead on tacit knowledge and direct communication between producer and receiver. The cases given in this book emphasise processes of communication, on incremental delivery, communication with customers, taking care to produce and give what is really needed, delivering simplest possible meaningful feature sets as quickly as possible.

All software is partially done, or rather is always potentially subject to change. Because software is amenable to change and its requirements are difficult to establish unambiguously software development processes are designed to reduce risk. Managing large software developments is an inherently risky process (Royce, 1970). In industry two polar extremes are taken by attempts to address risk: to establish perfect clarity prior to commencing the work, or to get feedback by producing something as early as possible (to give producer and customer a concrete artefact to explore, clarify, negotiate and make sense of. Lean takes the second position as its goal. P&P paraphrase Royce (1970) by stating that "every step in the waterfall process except analysis and coding is waste." (Poppendieck & Poppendieck, 2003:4). However Royce's own position was that "there are two essential steps common to all computer program developments, regardless of size or complexity. There is first an analysis step, followed second by a coding step... This sort of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the final product is to be operated by those who built it" (Royce, 1970: 328).

Value stream mapping is one way of describing the 'as-is' situation and preparing to change current processes and the balance of effort invested in development. Lean thinking applies the view that early feedback reduces waiting, the goal for which is to free the developer somewhat and the customer too, to give each the opportunity to clarify meaning and learn from each other what is desired, desirable, degrees of freedom and constraints. The implication of providing and giving early feedback is to recast the idea of who controls and manages development, instead control or management figure through involvement in production. Development may at this extreme be better understood as co-production. How then is this heightened communication between customer and developer attained?

References

• Poppendieck, M. & Poppendieck, T. (2003) Lean Software Development: An Agile Toolkit Upper Saddle River, NJ, USA, Addison Wesley.
• Royce, W. W. (1970) Managing Development of Large Scale Software Systems. IEEE WESCON. TRW. http://facweb.cs.depaul.edu/jhuang/is553/Royce.pdf

Notes:

SA 1: Is the use of a manufacturing metaphor in what is clearly a field of design and development work strictly applicable?

SA Note 1: The two fields of design and manufacturing are both conceptually and physically different. Certainly software duplication does not require the sorts of controls and efficiencies sought for in scaling production of physical goods manufacture. For digital media the finished product is absolutely the end of the story. More importantly, in the case of software a shift of focus from reproducing a digital good towards the work of designing the good is absolutely necessary. Software development's focus must be upon everything that precedes the production of the first copy of the end product. The manufacturing metaphor has limits when applied to software development however the principles of 'lean' are still relevant and applicable to software's activities: design, analysis, coding etc.

Good UI delivers visibility, feedback, control.

Golden Krishna's thoughts on 'NO UI' prompted a response by his colleague at Cooper Design, Stefan Klocek, who argued back that good UI can be, should be, is desirable. Design should not be about removing UI, but that good UI is instead about those three big things that Don Norman focuses on: visibility, feedback, control. Klocek's article is available from The Cooper Journal (link)

The best interface is no interface

Who doesn’t want Twitter inside the refrigerator? 

I'm sorry, Twitter in my refrigerator, why?

“Upgrade your life” with a better refrigerator door from Samsung and check Tweets when getting some water from the fridge?? 

 How do you make a better hotel lobby? Slap an interface in it. A giant touchscreen with news and weather is exactly what’s missing from my hotel stay?!?? Golden Krishna argues that our love for the digital interface has gotten out-of-control. With more than a touch of irony...

"Creative minds in technology should focus on solving problems. Not just make interfaces."

From The Cooper Journal (link)

Avalanche Rescue? There's NOT an app for that...

How to survive an avalanche? Don't get into one.

Interview with Jill Fredston

(Eptstein, 2021)

Illustration by Slate Magazine 2021

https://slate.com/human-interest/2021/04/how-to-survive-an-avalanche-tips-from-expert-jill-fredston.html

Out of bounds (an article from ABC News, Australia (2021 link))

Avalanches? In Australia? They are real and they can be deadly. But a group of back-country adventurers is trying to keep skiers, boarders and bushwalkers safe when they head out into the alpine wilderness. 

The Canadian Avalanche Centre "Avalanche Canada" gear recommendation:  https://www.avalanche.ca/gear

The BCA Tracker2 Avalanche Transceiver on epictv.com

"The Tracker2 avalanche transceiver is used to quickly locate avalanche victims and is required equipment for ski touring and backcountry skiing. The Tracker 2 is one of the fastest and most precise pinpointing transceivers on the market. It features triple receive antenna, instantaneous real-time display, and the same easy-to-use interface as the Tracker DTS. A mechanical search/transmit switch is super intuitive making it easy to use right “out of the box.” Includes multiple burial indicator lights and Special Mode.

Galileo-LawinenFon turns a smartphone into an avalanche transceiver (2014 link).

"(in 2013...) the Canadian Avalanche Centre (CAC) issued a warning about the dangers of relying on smartphone apps that were being marketed as economical alternatives to avalanche transceivers. But a new smartphone app and add-on hardware component could provide an alternative that is not only cheaper than dedicated avalanche transceivers, but also provides additional functionality.

On misguided attempts to replace avalanche rescue beacons with one of a growing number of smartphone apps (2013, link).

"Some people may be tempted to save a couple hundred dollars on an avalanche beacon and opt for one of several apps on the market. The Canadian Avalanche Centre does not recommend using these apps for actual avalanche incidents, however. It assessed three European apps – iSis Intelligent (Mountain) Rescue System, Snøg Avalanche Buddy and SnoWhere – before coming to the conclusion that they are unreliable and promote a false sense of security.

Avalanche airbags now offer wireless remote activation (2010, link).

"ABS has introduced a world-first - a remote, networked electronic system which allows airbag inflation to be triggered by other members of a skiing party, allowing them to help each other in an emergency.

This tracking system promises faster help for avalanche victims (2007, link).

"A new positioning system which will use Galileo, the future European global positioning satellite system, may prove to be a life saver for avalanche victims.

The Avalanche case

Similar case: 6 skiers survive backcountry avalanche near Whistler: Report by CBC (link).

---

From Bill Buxton's "Sketching User Experiences" (Buxton, 2007).
This case sets up the issues for high-tech design, design that works 'in the wild', that works for real people in real situations and facilitates achieving their human goals.

Bill Buxton sets the scene with the avalanche responder case. It is an incident experienced by his good friend Saul Greenberg, Saul's wife, and three friends when skiing in high mountainous terrain in Canmore and Kananaskis Country, Alberta, Canada.

The group was traversing a valley slope when a lethal avalanche fell across their path. The three skiers in the middle of the group were caught in the slide. The lead (Saul's wife) and the last skier could only watch the disaster unfold as three of the following skiers were engulfed by the avalanche. One was simply knocked down, one was buried up to her shoulders, and the last, Saul, was missing.

Let's pause the story at this point.

Avalanche and path of ski group collide

What is the normal procedure when backwoods skiing where there is a risk of avalanches? 

First, you go equiped with specialised equipment: radio transceivers, probes, and collapsible shovels. But more than just the technology; it requires know-how, knowledge, practices, shared practices, skills, situational analysis, stuff you learn and some stuff you have to make up as you go.

When skiing across an avalanche risk slope or area, you work one of a number of simple systems depending on the severity of the risk. Normal procedure for traversal is to spread out and post lookouts at either end, and traverse one-by-one. If a group gets caught in a slide and some survive (most don't) what do you do?

1. Someone goes lookout (you may be hit by another avalanche). 
2. Reverse triage; rescue the most able first (and they may be able to assist later). 
3. Rescuers go to the approximate location of buried victims, judge if carried onwards, then guide using transceiver. 
4. Use an avalanche probe to locate the body. 
5. When the victim is felt you start to dig and dig. 

The story continues...

"Steve, who was higher, checked up on Shane (who was okay), then immediately went to his wife. He freed her arms, and made sure her head was above the snow." 

"Judy went directly to the spot where she had last seen Saul... In order to pinpoint Saul's location, Judy used her avalanche transceiver. ... Using this, she walked a particular pattern on the snow, employing the loudness of a ping (determined by the strength of a signal from Saul's transceiver) to guide her closer and closer to a spot above where he was buried." 

"Judy started digging. Steve arrived and asked if she had verified the spot with her probe, she hadn’t. Judy was confident that she had the right spot, but by this time she had had to dig so deep that her confidence was wavering…"

Saul had tried to ski his way out of it but got caught in the hollow (avalanches can travel at up to 200km/hr whereas 40km/hr is really fast for a skier).

Saul got caught in the trough, a ‘feature trap’, that also meant he was buried deep! But he had cupped his hand over his mouth and nose, preserving a small air space so he could breathe.

He waited, buried under the weight of the snow, and tried to relax. He had to trust in his partners, their training, his and their gear.

None of the participants had ever been in this situation before. Time elapsed from avalanche impact to rescue was about 10 minutes. Under the conditions, after 20 minutes he would have been dead.

(Buxton, 2007) 

Question: After the 'who'; what saved Saul?

---

Instructional videos by Canadian Forest Rescue SEE SAFETY (http://www.fsavalanche.org/).

Design related material:
Source: Buxton, B. (2007) Sketching User Experiences: Getting the Design Right and the Right Design, San Francisco, Morgan Kaufmann. (Video examples for the book can be found at the publisher's companion site)
Bill's homepage (billbuxton.com)

Cray was a legend in computers and said...

Selected quotes: 

From around 5' mark 
"So, let me tell you a little bit, a few of the problems, that ah, and the solutions that I see in building large computers.
First of all... I think that building large computers should be done with the fewest possible people.
One is perfect, but you can't quite work with one.
So.. the next best thing is about 12."

"The reason you need 12 is you kind of need one person from each of the disciplines that are necessary.
You need a mechanical engineer to build the box that it'll go in.
You need an electrical engineer to put the circuit together.
You need a little bit of logic... and programmer here and there
And you need a secretary of course.
But not very many."

From around 6' mark 
[On the projects I've been involved in]
"the number of people involved has been pretty much constant.
... from a low of 25 to a high of 40.
[Small enough] that's a group where I can remember everybody's name, which I think is kind of important, but large enough enough so that we can in fact build large scientific computers."
...My current company has 25 people, it started 2 years ago, and I certainly wouldn't want any more, it's kind of crowded."
...Our current machine is far enough along that it's starting to run programs.
"A small group of people is kind of essential.
And ah, the extent to which I've been successful in building large machines I think that is one key thing.

From around 8' mark
"...and another key point, that's perhaps equally important is discipline.
If you work in a large corporation it's very hard to keep on one track for 4 or 5 years.
And 4 or 5 years is how long you need to keep on track to work on a project like that.
So continuity is, .. is another very very important thing.
And to develop the continuity I mean not only the scope of the organisation that's providing the money for you but also the continuity in the sense of people sticking around and finishing the job.
It's hard to design a computer if the person who designed it has left and has been replaced twice by somebody else."
So another characteristic, the people I'm working with today, my little elves, are all kind of old little elves, they've all been around since the early 50s or mid 50s.
...And that brings me to another important point that I think you'll appreciate and that hit me hard this year.
Because, we decided we were all getting too old and something should be done.


From around 9' mark
"...So we decided that we would hire 8 new people, fresh out of school, who didn't know a thing about computers.
They might know a little bit about electronics a little bit about physics maybe.
But ah, let's say three of them were college graduates, three of them from trade schools.
And we'd just sit 'em down and try to teach them about this huge complex computer that we were designing and see how far we'd get.
Well, the shocking thing was, it was only about three months, and they were doing so well at it,  that they were telling me about my design and what was wrong with it.
And by golly they were right.
These new kids were, were finding flaws in my logic design that I wouldn't have found myself.
And yet they had no experience prior to a few months of contact.
And I guess one of the things was that they were so unimpressed.
They had no idea, really, that this was supposed to be a big powerful machine.
And they were so unimpressed, that of course, you know, that they thought this was what everybody did that graduated from school.
[laughter]
And with an attitude like that, it's amazing, I guess maybe we are building simple computers.
..."

Reading an article and not sure how to write about it yourself?

- readings, precis, impact, application -

Prompting questions:

• What did I learn from reading this article?
• What was the intention of the authors?
• Who is the audience for the article?
• How could I use the article?

Readings are often difficult to understand or alternatively, to interpret and make sense of. I've often read a paper and said to myself "so what", "it's obvious", "what's the appeal of this stuff?" Sometimes I've been confused, overwhelmed with detail or just don't get the point. I've also read papers that have set off ideas, recalled past experiences, given an outlook that changes something I thought I knew well but now see in a different light.

Writing a precis of a paper turns the whole process back on itself somewhat; I go from being the reader of the paper to being a writer. Writing about a paper demands something of me, not just my impression of the paper and the information contained within, but how I felt about the ideas expressed, how I saw them applied, and reflected on their wider impact.

Written comments on a reading need to be succinct (if you go past a page then perhaps you should be writing a new paper?), and impact-full. Get to the point, don't just summarise, criticise! Refer to other works in a meaningful way (counter examples, supporting examples), and reflect on the bigger picture. If there are implications for practitioners and practice then state them, particularly if they are personal, affecting you.

When criticising a paper you should always attempt to be fair. Criticise it on its terms, not because it doesn't address certain areas that you think are more important; there may be good reasons for a paper's omissions: limited space, out of scope, irrelevance.

Finally, keep to the limits, wordcounts shouldn't be treated as "targets". If you can say less then say less; less is often more. It takes time to distill your comments and the result is often unexpected, but often in good ways.

Pointers

• Pick out some aspect of interest from the paper
• Comment on it (there are no wrong answers, it's just an opinion)
• Link it back to design processes.
• And consider linking your argument with pertinent external readings.

Try not go off on a tangent or indulge yourself in a flight of fancy. But if the paper sets off your creative side then explain your logic:

"The reading included a discussion of X which made me consider Y (not in the reading) because...".

Relate it back to the course; to continue:

"...but both X & Y are pertinent to Z which we have seen is a fundamental to the work of analysis, design and development"

The following rubric (a protocol or procedure) on assessing a written work may also be useful...
Audience: Who is the reading directed at? Is a question formulated, is it interesting and clearly put? Did the author clearly explain the purpose of the article?
Structure: Are the thoughts/agruments connected? Is there a logic to the presentation of ideas? Is theory utilised? If so is it treated critically or uncritically (just applied)? Do the authors anticipate and respond to counter-arguments?
Style of evidence: Does the work offer conjecture and possibilities based on the literature? Does the work offer empirical matter? Are assumptions stated? Is a philosophical foundation indicated?
Validity: How is the work positioned such that we understand how to test the extent of its claims, justification, rigour.
Rhetoric: Is the article persuasive? Are the findings, discussion and conclusions convincing? Does the work present implications and impacts? Are there behavioural, managerial, organisational consequences?


Further reading (about reading...no irony in that is there?)

• R. Subramanyam. Art of reading a journal article: Methodically and effectively. Journal of Oral and Maxillofacial Pathology : JOMFP, 17(1):65–70, Jan-Apr 2013. (link)
• E. Pain. How to (seriously) read a scientific paper. Science, March 2016. Available online at http://www.sciencemag.org/careers/2016/03/how-seriously-read-scientific-paper (Accessed: 29 November 2017). (link)
• A. Ruben. How to read a scientific paper. Science, January 2016. Available online at http://www.sciencemag.org/careers/2016/01/how-read-scientific-paper (Accessed: 29 November 2017).

Podcast media - two ideas (music, cover art)

What is podcast cover art?

Podcast cover art is a direct descendent of the traditional record cover. Think of the printed cardboard sleeve that contained old vinyl records (aka phonograph record, gramophone record, disc record, long-playing record, or just 'record'). The LP record had a diameter of 12' so the sleeve it came in was a 12' square. Sleeves for singles were typically 7' square.

(e.g. Example_Instagram_Format_Post.pptx)

You will create a cover art image in PowerPoint or other graphic design application. The image must be: 

• A SQUARE artwork of size (minimum) 1400 x 1400 pixels to (a maximum) of 3000 x 3000 pixels, 72 dpi that can be exported to JPEG or PNG file.

If third party media is used then you must identify the source (file, location etc), credit the creator and/or owner of the copyright, and ensure you in turn have a valid copyright license to use the media or derivatives.

What is intro/outro music?

An intro/outro is typically a 5 to 15 second audio segment (a cut) that acts as a musical punctuation for media. As creators ourselves we need to understand copyright, royalty, licences, and permissions. Especially as we publish our own work under a Creative Commons licence.  Creative Commons enables use to licence - use and share all kinds of digital media legally.

You will search for and select one music media file (mp3) available under a CC licence or similar no-fee royalty free licence.

Further reading

Creative Commons licence - using and sharing media legally