Exercise: Sutton's creative strategies

Objective To assess how prepared I am to manage a creative team and a truly innovative project.
These questions are set out as either/or style. There is no middle ground, they are not 'fair'. They act as a forcing function to get you to honestly resort to your true belief on how you intend to manage creative work teams. Your answers are naturally founded on your own personal beliefs and/or experiences. Your answers will probably change if the test is taken at another point in your career.

Instruction stage 1
Ask everyone to self-access the following questions.

Score	Either	Or	Score
+1	Seek out and be attentive to people who will evaluate and endorse the work	Seek out ways to avoid, distract, and bore customers, critics, and anyone who just wants to talk about money	-1
+1	Think of some sound or practical things to do, and plan to do them	Think of some ridiculous or impractical things to do, and plan to do them	-1
+1	Reward success; punish failure and inaction	Reward failure and success; punish inaction	-1
+1	Bring happy people together and make sure they get along	Bring happy people together and get them to fight	-1
+1	Promote “fast learners” (of the organizational code)	Promote “slow learners” (of the organizational code)	-1
+1	Hire people who make you feel comfortable, whom you like	Hire people who make you uncomfortable, even those you dislike	-1
+1	Hire people you (probably) do need	Hire people you (probably) don’t need	-1
+1	Take your past experiences and replicate them	Take your past experiences and forget them	-1
+1	Use job interviews to screen candidates and, especially, to recruit new employees	Use job interviews to get new ideas, not to screen candidates	-1
+1	Do something that will probably succeed, then convince yourself and everyone else that success is certain	Do something that will probably fail, then convince yourself and everyone else that success is certain	-1
+1	Ignore people who have never solved the exact problem you face	Ignore people who have solved people the exact problem you face	-1
+1	Encourage people to pay attention to and obey their bosses and peers	Encourage people to ignore and defy their bosses and peers	-1

Calculate your total personal score. Possible value ranges between -12 through to +12.

Instruction stage 2
Provide Sutton's principles paraphrased below for creative teams and then open the discussion, e.g. consider some of the questions below.

• Place bets on ideas without heeding projected ROI.
• Radical innovation implies ignoring what worked before.
• Take happy people and goad them into disagreement.
• Reward action, success AND failure.
• Have people who don’t fit in.
• Disagreements are necessary.
• Use new employees to bring in NEW ideas.
• Generate and use NEW ideas.

Nilofer Merchant (link) illustrates the contradictory qualities of situations where groups attempt creative problem solving through collaboration. In asking why (creative) collaboration is so rare she hits on a realisation, it is dangerous, risky, involves loss of face, basically it is something that can't be controlled and that translates into something to fear.

Discussion

• Are the recommendations irresponsible?
• Is a creative culture doomed to self-destruction?
• Can a creative development culture coexist with general production?
• Are Sutton's principles simply those that apply in startups?
• If this is startup thinking or behaviour where does it fit in 'scale organisations'?
• Must innovation efforts be separated from the mainstream organisation?
• Does the "Innovator's Dilemma" imply that innovation efforts need independence to succeed?
• Thinking of the possibility of 'Zones' of creative production occurring within the traditional monolithic organisation; Characterise a creative zone or project in such a way that it can be understood, appreciated and supported by a wider conventional organisation: skunk works, black team, blue sky, laboratory...

Observation: This test reveals how 'prepared' for and 'aware of' we are, of the intrinsic demands of creative innovative design environments. In spite of rhetoric to the contrary most organisations and most employees are not involved in innovation. In the main we repeat and reproduce routines that extract value from existing products, markets, customers, business models. Consequently most of us adhere to ingrained approaches to valuing, managing and acting within teams and their wider organisations.

References
Creativity Management (anti-)Principles (link)
Cliff Kuang. The 'done' manifesto: 13 Rules For Realizing Your Creative Vision. 2011 (link)
Nilofer Merchant's post the "Eight Dangers of Collaboration" (link)
SUTTON, R. I. 2001. The Weird Rules of Creativity. Harvard Business Review, 79, 10.
SUTTON, R. I. 2001. Weird Ideas That Work: 11 1/2 Practices for Promoting, Managing, and Sustaining Innovation, Free Press.

---

Results from ASE class 2013

Results from PT MSD class 2013

Results from FT MSD class 2013

Results from MSD class 2012

Results from MSD class 2011

Exercise: Creative Problem Solving

robot, n. The word ‘robot’ was first used in Karel Čapek’s play R.U.R. (Rossum's Universal Robots), a science fiction play in the Czech language in 1921.

This exercise simulates a creative-problem-setting-solving-setting etc in teams.
Objective: Understanding theory, principles and guidelines for group brainstorming sessions.

Materials
"Lego Mindstorms" Robot Base (1 per group of 4 to 7 people).
Creativity Assessment Sheet.
One hour to run.

Technology Familiarisation Stage
1. Introduce the robot and programming tools.
2. Allocate 7 minutes for individuals to take turns familiarising with the robot's capabilities.

Play Prototype then Try 
Part 1 
1. Turn the robots OFF.
2. Problem 1 is set.
3. Allocate approximately 3 minutes for initial exploration and solution working individually. Individuals working alone write a program to solve the problem on paper.
4. Allocate approximately 5 minutes for group discussion and determination of group program.
5. Robots can now be turned ON.
6. Allocate approximately 5 minutes to program the robots and 3 minutes for the teams to demonstrate.

Part 2
1. Turn the robots OFF.
2. Problem 2 is set.
3. Robots can now be turned ON.
4. Allocate approximately 15 minutes for groups to determine own approach to solve challenge.
5. Allocate approximately 5 minutes to program the robots and 3 minutes for the teams to demonstrate.

Reflection and discussion
What is called designing?
Was leadership difficult?
Could you put yourself forward, could you step back?
How did the team feel?
How did the team perform? On the task, overall?
Comment on behaviours that reinforced or diverged.
Was failure evident? How often? Personalised or not?
If you feel you failed do you think you learned more or less than if you hadn't?
Comment on risk taking.
Comment on the workspace.
Describe your ideal workspace; what things would be present, how would space be arranged?
Are you an 'insider', an 'outsider'?
Was 'talk time' shared? If not who didn't speak and why? If not who spoke most and why?
Does physical control of the 'things' limit collaboration?
What behaviours enable collaboration?
What is your motivation?

Additional links
In defense of brainstorming by Scott Burkin, blog post (link)
see the module "Inspiring Creative Thinking: Didactic methods in practice" (link)

Battleship as a metaphor for Plans or Planning

Exploring the difference between design and designing, or  plan and planning.

Step 1:
Individuals produce one or more up-front plans using provided blank sheets.

Step 2:
Open the playable version of battleship on GitHub.
Enter each up-front plan using the 40 shots per iteration game.

Step 3:
Enter your results in the survey form (survey form here)
Look at and discuss the results (data spreadsheet here)

Step 4:
Allocate 'iteration ranges' to individuals or groups and ask them to attempt to obtain the best possible result.
Continue to capture the result of each game in the survey form (survey form here)
Look at and discuss the results (data spreadsheet here)

Discussion:
What might 'design' be with respect to this game?
What might 'strategy' be with respect to this game?
What might 'project planning' be with respect to this game?
What (if anything) might this exercise highlight for projects in general?

Notes and References:

The members of Zilverblog have developed a simple version of the Battleship game, written in Javascript, as a tool to illustrate a number of ideas that seem to be relevant to planning systems development. For example:

The difference between Plans and Planning

The value of feedback

Cost and reward

The size of an effort versus the payback in terms of information

The game-like nature of projects (like pinball, the goal is to play again?)

From the Zilverblog The Power of Feedback in Scrum:

Update: Now also direct playable on GitHub.

"Board layouts are random and you get 40 shots in total to destroy the enemy’s fleet. After each iteration you get feedback about hits and misses. If you use iterations of 1, you are playing the regular battleship-game. Each shot costs 10.000 and when you sink a ship you get the_ships_size * 50.000 (e.g. the submarine of size 3 will reward you with 150.000). If you keep track of the balance after each iteration, you could also try to get across the idea that stopping after a few iterations might give ‘good enough’ rewards. It can be downloaded from our GitHub repository as a zip or you can take a look at our code. Just double click on the index.html (in the public folder) to start a game."

Exercise: Researching for Designing

Materials:
Copies of the research method protocol template. Each form depicts one of 27 different interpretive research protocols based on the 'Learn', 'Look', and 'Ask' cards from IDEO.

Time:
Allow a day between setting and concluding the exercise.

Protocol:

1. Write your name and the research context you will investigate 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 notes and analyse them for findings.
5. Keep a record of evidence gathered.

Evaluation:

In class discussion of findings. 

In research pairs.

Notes:

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, behavior, 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, behavior and artitfacts 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 behavior, 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 organization 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 summarizing 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 visualize 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 characterists 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
Behavior 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 analyze 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 Modeling	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.

Scene from the CSEPF class 2013 (MSc ASE) UCD

Creative Process Workshop 2013

Guindon design exercise slideshows

---

---

---

---

---

n.b. G+ is evil. Need to go back to Picasaweb albums to do get generated embed code :( https://picasaweb.google.com/lh/myphotos?noredirect=1

Exercise: Requirements Design Trade-off

This exercise has been adapted from Alexander’s ‘Notes on the Synthesis of Form’ (Alexander, 1964); the simple design problem from section 1 ‘the need for rationality.’ Alexander’s classic design tetrad characterises trade-offs between the major product requirements: simplicity, performance, features, economy.

Objective
Organise, model and explore the interrelationship between different requirements.
Requirements/Design Preparation
1. In groups of 2 or 3 categorise the following non-functional requirements for an imaginary high tech product.
Statement of non-functional requirements

• A simpler product (system, service, device) will be easier to manufacture and operate.
• A simple product with fewer features is going to be less costly to maintain.
• A simple product is easier to construct as it has fewer features.
• Greater system performance or power is achieved by including more (advanced) features.
• A highly optimised product is difficult to improve, change, fix or maintain without degrading its performance.
• A simpler product does not deliver as many features or options as a more complex product.
• A simple product using fewer specialised parts will not perform to as high a level as one using specialised optimised parts and sub-systems.
• Adding more features makes the product more difficult to maintain.

2. Consider following product requirements categories: Simplicity, Performance, Feature Set, Build/Operate Economy.

3. Each group to complete a diagram illustrating the trade-offs between the requirements list and the product requirement categories.

Discussion:

• Is there a unique solution that satisfies this statement of requirements?
• Do requirements influence design decisions?
• Do requirements specify design?
• Is it possible to overcome contradictory requirements?
• Would more detail enable us to overcome contradiction?
• Will computer modelling of requirements enable conflicts to be resolved?
• Does the design of the product limit which requirements can be delivered?
• Is there always a trade-off between requirements and design?

Reference:
Alexander, C. (1964) Notes on the Synthesis of Form, Cambridge, Massachusetts, Harvard University Press.

---

A Collage of Outputs from the Requirements Exercise

Exercise: Learning to learn in groups...

Adapted from material developed by Maeve Houlihan and Aoife Doherty 
Lecture time: 1h15'

Objectives (5') - S1-S2 

To produce and present a critical analysis
To conduct independent research
To experience and reflect on group work

Transition (5')

Identify groups

Provide readings

Group work starts (20') - S3 

In groups of approximately 5

• Critically evaluate one of the articles provided.
• Preparing a group review (without visual props). 
• 20' to read and prepare of which 5' quiet time.

Without giving too much guidance up front simply ask the students to spend 20 mins critically evaluating their article and then each group can present their critique for a maximum of 2 mins (without powerpoint) to the rest of the class. After all of the presentations there should then be approx 15 mins for the lecturer to provide some feedback based on the key touch-points.

Presentation delivery (30')

10x 2-minute presentations followed by one quick Q&A on the subject matter

---

Articles

Document 1: From Naur & Randell "NATO Conference on Software Engineering," 1968 (link)

1. Group Discussion: User Requirements (pp 40-43)
2. Group Discussion: The Nature of Software Engineering (pp 19-23)
3. Group Discussion: Software Engineering Management and Methodology (pp 24-30)
4. Group Discussion: Design and Production in Software Engineering (pp 31-32)
5. Keynote Speech, by A. J. Perlis (pp 135-137)
6. S. Gill: Thoughts on the sequence of writing software (186-187)

Document 2: From Randell & Buxton "Software Engineering Techniques; NATO Conference Proceedings," 1969 (link)

1. Group Discussion: Case Histories; A Survey (pp 41-42)
2. Group Discussion: Apollo Programming Support (pp 43-47)
3. Group Discussion: The Electronic Switching System (pp 48-50)
4. Group Discussion: Software Engineering Education (pp 61-66)
5. R. M. Needham: Software engineering techniques and operating system design and production (pp 111-113)
6. R. M. Needham and J. D. Aron: Software engineering and computer science (pp 113-114)
7. J. I. Schwartz: Analyzing large-scale system development (pp 122-136)

---

Thematic Discussion (10")

• What can we take from these passages?
• What were they concerned about in the 1960s?
• Are old concerns still contemporary issues? Why?
• What did they think would solve these problems? Based on what knowledge?
• Was there agreement as to the problems? The solutions?
• Is the work we do today and the ways we manage it essentially different or only accidentally different?
• In what ways is the work then and now similar?

---

Class Discussion (10')

What is critical analysis?

• Evaluating
• Subjective
• Persuasion
• Evidence
• Scientific
• Political 

Did typical roles arise? What were they?

• Manager
• Timekeeper
• Recorder/checker
• Sceptic
• Big boss
• Lurker
• Facilitator

Were roles assigned or volunteered for?
Did people change roles? Why?

Did each member have a voice, make an impact?

What was the dynamic (over time)?

• Initial analysis
• Independent research
• Synthesis
• Chaos
• Lost in the desert
• A cavalry charge

Did the group...

• Present a brief and cogent piece? 
• Add value - illustrate, relate etc?
• Reflect and critically evaluate?

e.g. (t: critical analysis - 30s) / (t: synopsis + 30s) + insightful analysis + impactful conclusions.

Wrap up - S4 - S5 - S6 - S7 - S8 - S9 - S10

---

Further reading

A process for combining self-directed and group-based learning can be organised as follows. Note, groups should adapt and modify the steps to suit the round style and conditions. (Schwartz et al., 2001) 

1. First encounter a problem ‘cold’, without doing any preparatory study in the area of the problem.
2. Interact with each other to explore their existing knowledge as it relates to the problem.
3. Form and test hypotheses about the underlying mechanisms that might account for the problem (up to their current levels of knowledge).
4. Identify further knowledge gaps or learning needs for making progress with the problem.
5. Undertake self-study between group meetings group to satisfy identified learning needs.
6. Return to the group to integrate the newly gained knowledge and apply it to the problem.
7. Repeat steps 3 to 6 as necessary.
8. Reflect on the process and on the content that has been learnt.

The Seven Jump or Maastricht process offers a similar template for structuring small-group tutorial learning. (Grave et al., 1996)

1. Clarify unknown terms or concepts in the problem description.
2. Define the problem(s). List the phenomena or events to be explained.
3. Analyse the problem(s). 
• Step 1. Brainstorm. Try to produce as many different explanations for the phenomena as you [can] think of. Use prior knowledge and common sense.
• Step 2. Discuss. Criticize the explanations proposed and try to produce a coherent description of the processes that, according to what you think, underlie the phenomena or events.
4. Formulate learning issues for self-directed learning.
5. Fill the gaps in your knowledge through self-study.
6. Share your findings with your group and try to integrate the knowledge acquired into a comprehensive explanation for the phenomena or events. Check whether you know enough.

Alternatively the MacMaster ‘triple jump’ represents three main stages for student-driven problem investigation: initial analysis, independent research, and synthesis. Each stage consists of a series of activities (not necessarily taking place in sequence).

1. Initial analysis: identify problems, explore extant knowledge, hypothesise, identify knowledge gaps
2. Independent research: research knowledge gaps
3. Synthesis: present findings – relating them to the problem(s), integrate learning from others, generate a synthesis, self-assessment of learning process, repeat ‘triple jump’ if needed.

References:

• GRAVE, W. S., BOSHUIZEN, H. P. A. & SCHMIDT, H. G. (1996) Problem based learning: Cognitive and metacognitive processes during problem analysis. Instructional Science, 24, 321-341.
• SCHWARTZ, P., MENNIN, S. & WEBB, G. (Eds.) (2001) Problem-Based Learning: Case studies, experience and practice, London, Routledge.

Exercise: The (daily) standup

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: (c) Design for search by smell

(a collaboration with Norman Su) A variation on earlier design exercises (exercise a and exercise b)

Objective
Theory: To demonstrate the design dynamics surrounding paper sketches, digital sketches, and speculate on the implications for digital design environments.
Practice: To gain practice at creating sketches and digital design artifacts to display and test technology use/interaction ideas.

Materials
Sheets of A4 paper, post-it notes, pens and pencils of different colours.
Online access to the Balsamiq Mockups wireframing tool. http://webdemo.balsamiq.com/ (accessed: 2015-05-22. Also see http://balsamiq.com/products/mockups (accessed: 2010-2011)

Instructions Part 1
1. In groups of 2 or 3 use paper/pencil sketch a mockup of a new kind of App that uses 'scent' or 'smells'! (allocate 10")
2. Assume there is some way to capture 'scent' or 'smells'.
3. 10 minutes
4. Let me know (raise your hand, etc.) when you’re done

Instructions Part 2
5. In the same groups use Balsamiq to create a digital version of the design. The new design may vary from the paper/pencil sketch.

Tips:
Mockup → Download as PDF (to save a copy of your finished design)
Mockup → Clear Mockup (but don't mistakenly wipe your mockup before you save a copy)

6. 15 minutes
7. Let me know (raise your hand, etc.) when you’re done
8. Discuss the following reflection points (in groups first followed by class discussion). (allocate 5")

Reflection
Your own thoughts/observations?
How many design possibilities were sketched on paper? In Balsamiq?
Consider the difference between paper/pencil sketch vs Balsamiq.
How did the tool used shape, constrain or enable your design thinking?
Comment on the discussion dynamics within the group.
Did someone take responsibility for driving the group forward?
Describe your feelings and thoughts on the process of translating your ideas into different concrete representations.
Can you identify 'who contributed what' to the designs?

References
The science of smell (link to article on brainfacts.org)
Intel Neuromorphic chip demonstrates smell functionality (article from intel.com)
"Sniffing Entrapped Humans with Sensor Arrays" (link) & NewAtlas article (link)Chat Perf for smartphone. Intro article on Gizmag (link)
SAPER app (link on gizmag). Not quite an electronic nose but close.
Wongchoosuk et al, (2009) Detection and Classification of Human Body Odor Using an Electronic Nose. Sensors, 9, 7234-7249. (doi 10.3390/s90907234 - resolve via dx.doi.org)
How Internet Odors Will Work (howstuffworks.com)
Related imagery and concepts on the Edible Geography blog (ediblegeography.com)
Want the nose of a Sommelier? (Null, 2018 - article on wired.com)

Exercise: Systems Development Life Cycle Analysis

Objective:
To translate descriptions of different systems development life cycles into realistic/probable milestones and actionable activity timelines; as templates for the purpose of choreographing or managing teams.

Preparation:
Allocate at approximately 30” to run this exercise. 5” setup and briefing. 15” complete the exercise instructions below. 10” debriefing. This exercise can be carried out individually or in small groups. No special room/space requirements. A document projector is desirable.

Material:
Provide copies of this instruction sheet and additional blank sheets of paper.

Instruction:
Generate a milestone calendar or activity/time diagram using (at least) the activities of the generic SDLC, for one of the following life cycle models.

1. Waterfall.
2. Spiral development.
3. Or any other life cycle/method you are familiar with.

Outputs:
A single A4 sheet of paper upon which each student/group creates their own annotated diagrams for the life cycle model, e.g. a timeline of phases/activity for a project or iteration, a map of business function/activities over time, a consolidated diagram. Write your name(s) on the sheet.

Learning Outcomes and Reflection:
At the end of completing the exercise the tutor can gather the diagrams, group and display them during discussion using a document projector. Alternatively select student/groups to show, talk about and explain their diagrams to the class.

Practical Aim:
Identify the key characteristics of the listed software production and systems development lifecycles.

Knowledge Aim:

• Describe and discuss current and emerging management approaches to systems development in general.
• The overall goal of this exercise is to explore how you would operate or organise your team's activities over time based on one or other lifecycle.

Cross reference: Systems development life cycle notes

Exercise: planning game

Goal
To demonstrate and experience one particular process of planning in a team environment where knowledge and expertise is distributed among team members.

Roles/Identities:

• Product Owner: Product owner judges the trade-off between value and timing of features. Will engage in discussions at the PLANNING GAME, prioritising and valuing features. Is authoritative to accept a feature as developed or NOT.
• Architect: Architect identifies links between features, architectural/design and delivery elements. Creates diagrams linking Features (F) with architectural elements (A) and deliverables (D).
• Lead Developer and extra developers if available: Developers provide estimates of effort and risk for design-delivery elements. Have important domain knowledge and suggests needed features. Is authoritative on estimates for effort or time of a design-delivery element.
• Scrum Master: Scrum master (or someone assigned) will turn feature and development stories into a planning chart and highlight the critical path.

Activities 
The Scum master keeps the PLANNING GAME focused by:

• asking “what (F) features do we need?”
• asking “what (D) deliverables satisfy (F)?”
• asking “how does (A) architecture link (F) & (D)?”

Allocate approximately
Feature Discussion (5 minutes)
Design-delivery discussion (~5 minutes)
Architecture discussion (~5 minutes)
Decide backlog (~10 minutes)

Debriefing
~10’ Discussion: group pairs report progress to the whole class.
Was there a perfect solution?

Research and Further Reading

• Agile Game Development with Scrum
• What sort of Games can we play with teams?

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…

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

Exercise/Experiment: Guindon Design Activities

This experiment is an adaptation of the Spaghetti Cantilever Teambuilding Exercise. Organise into large and small groups (from 4 or 5 people to 8 or 9 people).
• Each group will employ a ‘thinking aloud’ protocol as they run the experiment.
• The cantilever designers should highlight key transitions or changes in their thinking about the problem.
One person will act as the researcher, capturing a time-record of the designers’ abstraction level and time at any moment. The researcher will make judgements about the abstraction level. The researcher is not allowed to take part in the design and construction.
• Change the person in the researcher role every 5 minutes to give all team members an opportunity to contribute to the cantilever design and construction.

Resources for 10 groups

Include the following observations on the ‘Design Activity Graph.’
• Scenario thinking
• Requirement thinking
• High level solution thinking/building
• Medium level solution thinking/building
• Low level solution thinking/building
• Key ideas.
• Testing or Review.

Example of one group's design-construction activity chart

Spaghetti Cantilever Exercise
An exercise in design and coordination (adapted from Patrick Stacey’s boundary object seminar). This exercise resonates with Peter Skillman's 'Marshmallow Challenge.'

Allocate at approximately 1 hour to run this exercise. 10" setup and briefing. 30" experiment. 5" extra time. 15" debriefing.

You will need a large space with scattered desks to accommodate the exercise. Tiered lecture theaters are not suitable environments for this activity.

Aims
Practical Aim: Construct a cantilever extending from a surface, such as a table top.
Knowledge Aim: To assess the different activities people engage in open-ended problem solving.

Material
For construction each group is given a pack of spaghetti, a roll of tape, 2 sheets of A4 paper. Pens are for writing and not to be used in the structure!
Each group to be given a sheet of graph paper to capture the team's Guindon graph.
The tutor will need a timer and tape measure.

Competitive dimension/evaluation: Which group will construct the longest cantilever, - it must not touch the floor!
The tutor will need a measuring tape to measure and compare the length of the cantilevers.

Reflection
Ask each group to classify the activities they underwent (perhaps over 4 or 6 distinct kinds of activity)
Ask each group to estimate how much time they spent on each activity.
Ask the groups to reflect on how they won (or lost!) and to reflect on the contributions their different experience, backgrounds, disciplines made to the solution.
Were there collaboration problems? Were boundary objects used to make sense of the challenge?
What evidence of design work is available (diagrams, prototypes, experimental trials)?

ASE Class of 2013/14

Group ID	Test 1	Final Span (cm)
a	OK	72cm
b	OK	44cm
c	OK	64cm
e	OK	91cm
f	OK	64cm
g	OK	20cm
h	OK	52cm
x	OK	71cm

Class of 2013/14 FT

Group ID	Test 1	Final Span (cm)
a	OK	13cm
b	OK	10cm
c	OK	70cm
e	OK	46cm
f	OK	58cm
g	OK	67cm
h	OK	59cm
i	OK	62cm
j	OK	18cm, 18cm

Class of 2012/13 

Group ID	Test 1	Final Height
a	3/4	56cm
b	OK	71cm
c	1/2	nil
e	1/2	52cm
f	1/4	81cm
g	3/4	46cm (74cm)
h	OK	83cm
i	1/4	83cm
j	3/4	51cm

Exercise: a 30 second video

"I like the UCD because..."

Goal
To get 'hands-on' experience creating a video presentation.

Instructions
You have 30 minutes to produce a 30 second video.

1. Form groups, at least one member of each group to have a laptop computer on the wireless network.
2. Each use your own smartphone with video function
   
3. Announce the objective
• To create a video "I like the UCD because..."
• Completed video to be 30 seconds duration or less.

Tips First try producing the video in a single take (to avoid merging different shots or doing complicated edits). Planning a video... Start by brainstorming different ideas in the group. When brainstorming:

1. Let each member provide 2 or 3 ideas, capture each ideas with a post-it notes.
2. Suspend your judgment until everyone has stated their idea.
3. Next build on ideas, some ideas will be put aside at this stage.
4. At all times be aware of your own and other's personal safety.
5. Criticise the idea not the person.
6. Use serial discussion, everyone has a turn, no one person dominates.
7. Consider taking on roles but keep it democratic.

Producing a video Videos have a beginning, middle and end so consider writing a brief script. Assign roles...

1. to write the script.
2. to plan the shots.
3. to film.
4. to act.
5. find/create props.
6. to edit.

Do dry runs!

Perhaps you might

• Upload your video to Vimeo or YouTube?

---

Further reading

• Storyboarding is also used as a user-design technique for systems development. For examples see The Importance of Storyboarding Your iPhone App by Josh Clark and Storyboard technique for software projects by Adam Musial-Bright.
• Reynolds, G. (2008) Presentation Zen: Simple Ideas on Presentation Design and Delivery, Berkeley, CA, New Riders.
• Sawyer, B. (2009) The Learner's Journey in Practice. (blogs.oreilly.com)
• BBC video editor (link)
• Camista screen recorder (link)
  
• Quick and Easy Video with a Flip Cam (dspace.ndlr.ie)
• A Guide to Student-Generated Videos(www.studentgenerated.com)
• MINO HD FLIP CAMERA USER GUIDE (dspace.ndlr.ie)

Here's my pitch for you to 'storyboard' and some tips on how to do it. Storyboarding from Allen Higgins on Vimeo.

Lego First Iteration

Planning a backlog for the First Iteration
After user story estimation the team met again to plan the first iteration. Again the whole team had to be present but everyone was there on time so the meeting started promptly.

“Our goal for this meeting is to plan our first iteration and release,” said Mary. “Because of the short timeline for the workshop the iteration itself will be incredibly short. As you know, for development projects you’d normally set aside anything from two to four weeks for the first iteration. Given the constraints we’re working under we want to review progress tomorrow. Basically we’ve got the rest of the day to work through some of the user stories.”

“How reasonable is that?” asked Daniel. “Doesn’t intense time pressure undermine good work?”

“Not always,” said Yi, “we already know we have limited time and a limited number of people available, so we will manage the only variable that it is reasonable to expect, scope. I prefer to under promise and over deliver.”

“If I could add,” said Neal, “we’re not creating a new technology here as such, but we are creating exercise projects for the volunteers to teach. I see these deliverables as one or two page guides to each exercise. There might be a student copy and a teacher’s copy.”

“But still…” said Daniel.

“Well I signed up for this, lets just get the planning done so we can move ahead with developing the material,” said Paraic.

There was general agreement and so Mary proceeded.

“The first iteration deals with Primary Level students. Typically 4th/5th class students. We can’t assume these schools will have computing resources to install the LM PC/Mac development environment so this iteration will develop content material for the stand-alone option.”

“I don’t like to be the one complaining all the time but what’s this about the Mindstorms PC/Mac development environment?” asked Daniel.

“It should have been in your briefing packs,” said Neal. “Haven’t you installed it yet?”

“Neal, can you hand around copies of the NXT Software to the group?” suggested Mary. “Well add a story to the iteration plan

• Evaluate NXT Software v2.0 with Datalogging on Mac or PC

“Great,” said Daniel, “but we’ll need to install the software on our PCs and play around with it before we can talk about how to design the content for Second Level students, that is, assuming they have PCs in the classroom.”

“Let’s make sure it goes in the plan. Now what should we develop first?” asked Mary.

Estimating Lego Stories

Estimating User Stories for Primary Level
After an hour spent working through the stand-alone functionality of the LM kit in small groups everyone gathered again.

“We’ve got a new story to add,” said Alan. “During the spike and after doing some research we found some existing 5 step exercises which are already written and fairly easy to do.”

“And our group,” added Amir, “thought the Try Me submenu was worth treating as a full exercise.”

“Yes,” said Alan, “we thought so too, perfect for Primary Level.”

The extra story cards were added to the list.

“What we’re going to do,” Mary started, “is estimate the stories using ‘story points.’”

“What’s a story point?” asked Daniel.

“A story point is a unit-less measure of size and complexity for a story, we’ll think about duration after we’ve got a feel for size and complexity.”

“Shouldn’t I be thinking in terms of how long it’ll take?” said Daniel.

“Not yet,” said May, “this way we’ll get a general feel for the size and difficulty of the story before we get into the detail.”

“The devil is in the detail,” said Daniel.

“Yes,” replied Mary, “but this will also help us understand what these stories actually mean before go to that level of detail. Now we’ve added the extra stories after the spike.” (Table 4)

Table 4. Primary Level User Exercise Stories

Story Text	Estimate
As a student I want an opportunity to explore the Try Me submenu. (&View submenu)	0.5
As a student I want to make my robot drive faster so that it wins the race. (Robot Rally Race)	3
As a teacher I want the student to apply maths concepts to driving the robot.	Relegated to common task.
As a student I want to build the basic driving base	3
As a student I want to make the robot go back and forth when its Touch Sensor is pressed.	.5
As a student I want my robot drive and turn when I clap my hands.	.5
As a student I want my robot to drive along until it detects a dark floor colour.	.5
As a student I want my robot to move forward, whistle a tune and wait for its touch sensor to be pressed.	1
As a pupil I want the robot to respond to sensor input so that it behaves differently.	1
As a pupil I want to modify my robot to make it better than the other groups’ robot.	1
As a student I want my robot to speak when I clap my hands.	.5
As a teacher I want to demonstrate how logical steps create the robot’s behaviour	2
As a teacher I want the students to connect and operate sensors and motors. (NXT Program submenu)	1

“We should size the stories next,” said Mary. “We’ll be using the story points I talked about before, remember this is just to get a general feel for the size and difficulty of the story before we talk about how long it will take. We’re going to estimate by playing ‘planning poker.’”

“What’s planning poker?” asked Daniel.

“It’s an estimation technique that gets over the problem of people anchoring their estimates based on each others, you know, when the first person picks a number out of the air, and you go along with it just because it’s out there,” said Mary. Each of you takes 7 index cards and writes your own deck of numbers on the back, lets say: 0, 0.5, 1, 2, 3, 5, 10”

Yi spoke up, “because we’re simply developing supporting material for an existing product we thought the estimates would be thought of in range of hours and fractions of hours.”

Mary continued, “but the point is to get an estimate of size rather than how long it will actually take. But, yes, our starting assumption is notionally to use hours, however if you think days or weeks are required then say so. Anything less than half an hour we’ll treat as 0. And before anything else, keep your estimate secret until I ask you to show your cards. Shall we start with the first story, the Try Me submenu?” 

“OK,” said Mary, “has everyone selected a poker card? Right, let’s turn them over.”

Alan and Daniel both estimated 0; Amir and Paraic 1; Mary, Stewart, Yi and Neal 0.5.

“Not too extreme a spread,” said Mary. “Alan and Daniel, why zero?”

“Well,” said Alan, “it seemed a pretty trivial exercise, definitely less than half an hour of ideal time.”

Mary asked, “Amir, what were you thinking about for the ‘Try Me’ exercise?”

“Well,” began Amir, “Quite simple really, instructions for students to wire up the brick, then each student should get a hold of it and run through the options, there were 5 options if I recall correctly. We’d need to document the learning goals, some pointers on what to do if students delete the tests. That kind of thing.”

Neal added “That description ties in nicely with the programme. It seems the sort of thing that should be done with both user groups, Primary and Secondary.”

“So,” Alan began, “you’re saying our job is to write up a crib sheet or instructions to the teacher to deliver this story?”

“Yes,” said Neal, “our job is to provide other programmers and engineers like ourselves with the cheat sheets and scripts to run these exercises in classroom settings. Think of the situation we’ll find ourselves in; 25 or 30 students in groups of 5 or 6, following your instructions, Lego bricks scattered on tables. This programme is going to need to be pretty well bulletproof. Even a simple exercise like this one can quickly unravel into chaos in a classroom setting.”

“Shall we do another round on this story?” asked Mary?

Everyone agreed. This time the estimates were: Daniel still 0; Alan, Amir, Paraic, Mary, Stewart, Yi and Neal 0.5.

“Well Daniel,” asked Mary, “would you be prepared to see it estimated at 0.5 rather than 0?”

“That’s OK with me,” said Daniel.

“Right,” said Mary, “let’s move on. Making my Robot faster”

“This story isn’t meaningful,” said Amir, “it needs a concrete example before it can be performed. You can only make the robot faster to win a race if the exercise involves a driving robot and a race of some sort. And the third story, well all the exercises will typically involve some maths concepts, this story is so general that it could apply to everything.”

“One at a time,” said Mary, “so you think the second story isn’t clear, it should be a race exercise or competition of some sort?” Everyone agreed so Mary updated the card. “And the third card, isn’t a standalone exercise, you think it is a feature or task for all exercise stories?”

“Yes,” said Amir, “that makes it sense.”

“So what we’ve done here is clarified the definition of story 2, and relegated story 3 into a general task for the exercises,” said Mary. “Can someone update the ‘exercise’ stories, on the other side of the card write ‘maths concepts described.’”

“Just a thought,” said Alan, “should our estimate for Try Me story be updated to account for this?”

Mary asked if anyone thought the estimate needed revision but no one did.

“OK,” said Mary, “this story, build the basic driving base.”

“This one is a problem!” said Daniel. “First it has nothing to do with programming, but you can’t do anything useful until you’ve got it done.”

“There’s nothing wrong with it not being programming,” said Stewart, “hardware is important too.”

“Right,” said Daniel “but this exercise is really time consuming and requires a lot of concentration. Primary Level students just may not get it done in time. It took me nearly an hour. It’s fiddly work. Can you image a group of 6 or 7 ten year olds working together under time pressure?”

“All right,” continued Stewart, but we’re not estimating how long the students will take to complete the exercise, we’re estimating how complex it is to document it as an exercise in ‘Cool.’”

“I’m just saying it’s by far the most complex exercise on the list. And by the way, it needs to be done to before the interesting 5 step programming exercises can be done.”

“Do we have enough information to estimate?” asked Mary? “Right, ready? Show your hands.”

This time the estimates were: Daniel, Alan, Amir, Paraic, Mary, Stewart, Yi and Neal 3.
They continued planning poker estimation of the rest of the stories until they reached the final one.

Stewart spoke up. “I think the first and the last stories are duplicates. After having used the NXT brick I think the Try Me submenu does both of those things.”

“But,” Yi added, “the view menu also give access to some of that functionality as does the NXT Program submenu.”

“Perhaps we can treat them as separate exercises?” suggested Alan, “Try Me is quick and easy, whereas View gives a quite ‘technical’ view of the sensors, even motors as sensors with rotation detection. I can see quite a lot of learning objectives being covered just using ‘View.’”

“Well, OK,” conceded Stewart, “you’ve convinced me, perhaps we should add View to the first and clarify the last stating it should deal with the NXT Program submenu?”

There were no objections so the story cards were updated and the estimate played.

NEXT STAGE >>

Lego User Stories

The team members formed into workgroups and discussed and wrote down the stories as shown below (Table 1).

Table 1. Stories for Cool Software

Story Text
As a teacher I want everyone on a team to get involved in programming the robot.
As a student I want to make my robot drive faster so that it wins the race.
As a teacher I want the student to apply maths concepts to driving the robot.
As a pupil I want the robot to respond to sensor input so that it behaves differently.
As a pupil I want to modify my robot to make it better than the other groups’ robot.
As a student I want my robot to speak when I clap my hands.
As a teacher I want the students to connect and operate sensors and actuators.
As a teacher I want to demonstrate how logical steps create the robot’s behaviour.

“That’s a good start,” said Yi, “but we haven’t addressed how the delivery of these things should be structured. Shouldn’t we include things like how the programme is delivered.”

“A good point Yi,” said Mary. “These stories are quite mixed, the first story does suggest a delivery requirement. Let’s group the stories. One group for stories implying delivery issues, another group for stories dealing with content like student exercises.”

The discussion continued and the team members added to and organised the stories as shown below.

Table 2. User Stories for Exercises

Story Text
As a student I want to make my robot drive faster so that it wins the race.
As a teacher I want the student to apply maths concepts to driving the robot.
As a pupil I want the robot to respond to sensor input so that it behaves differently.
As a pupil I want to modify my robot to make it better than the other groups’ robot.
As a student I want my robot to speak when I clap my hands.
As a teacher I want the students to connect and operate sensors and motors.
As a teacher I want to demonstrate how logical steps create the robot’s behaviour.

Table 3. User Stories for Delivery

Story Text
As a teacher I want everyone on a team to get involved in programming the robot.
As a teacher I want a way for students to design simple programs without using the NXT Brick or a PC, because I don’t have enough resources to give everyone one.
As a teacher I want the students to think about how they organise the team, so that they understand some of the issues of teamwork.
As a pupil I want feedback on how my program/robot performs.
As a teacher I want to reward all the students so that they each feel they have achieved a goal.
As a teacher I want the session to deliver ‘wins’ quickly, in less than 30 minutes, so that students’ attention remains high.
As a teacher I want the setup to be quick, less than 5 minutes.
As a teacher I want to be able to pack up quickly, less than 5 minutes.
As a teacher the resource kit must be portable, fit into a car boot.
As a teacher I want competitive tests at the end of each exercise, but to also reward everyone for achievement.

Stewart spoke up at this point.

“I find it interesting that we haven’t addressed the different audiences, the Primary Level student and the Second Level student.”

“Right you are Stewart,” Mary said. “Both kinds of user are very different. We’ve all done a bit of research into the National Curriculum material addressing the two groups and we’ve all had a basic introduction to the capabilities and limitations of the LM platform. How about we discuss how the exercises can address the different audiences?”

“I think we can only talk about Primary Level today” said Amir. “I simply haven’t had the opportunity to evaluate the advanced features of the LM platform yet.”

“If I could respond?” Yi said. “As you know Neal, Mary and I have timetabled some breakout sessions over these three days. The idea with these sessions is that we ourselves can learn about LM’s capabilities. Before going into the details of Primary Level and Secondary Level content, should we break-out now into smaller groups to get up to speed with LM?”

“That’s a good idea Yi,” said Mary. “We can have a coffee break now and then reconvene in small groups to run a short spike. A spike is a term for a short intensive exploration of a problem or new area that needs investigation so that we can better understand the kinds of solution and estimate. After the break we’ll invest one or two pomodoro length periods in understanding the basic NXT brick capabilities.”

“Yes, and if I could add,” Yi said, “three days is a very short turn around to develop and deliver the kind of polished programme material we want. The fact is, we don’t expect a polished finished product. What we want is a working prototype of the programme. Something we can test trial with teachers at a local Primary and Secondary school, and to demonstrate to the members of the IE-ICS-ISA steering group to get their buy-in to move it forward.”

“The point is,” Mary continued, “that we’ve got about a day or so for the Primary programme and a day or two for the Secondary programme. If we take them in that order our ability to estimate the stories will improve as we learn ourselves. Is that all? Then lets get back together after the spike.”

NEXT STAGE >>

Lego Mindstorms Planning Scenario

Day 2 – Tuesday Morning
Neal had been Engineers Ireland’s representative on the education task force. Neal, with Mary, from the Irish Computer Society and Yi from the Irish Software Association were joint chairs of this morning’s meeting of the volunteer group. Mary was going to act as a facilitator for the meeting.

“Good morning everyone, welcome to the workshop,” Mary said as the groups settled in the conference room. “Is everyone here?”

“Everyone except Stewart and Daniel” said Paraic from ZWare.

“Should we start without them?” asked Amir. 

Amir, like all the volunteers, was in the workforce, but his and the others’ employers were supporting the ‘Cool Software’ initiative by releasing them to the project for the next three days. It didn’t mean his day-to-day workload had really gone away though so he wanted to get started as quickly as possible.

“We should wait until we’re all here, Amir,” said Mary. “It is important that the whole group is here. Everyone needs to participate, particularly at the start of the process. Even though they may not have much to add initially we’ll all benefit if we start the process together and start the planning together.” 

Mary proceeded to break up a bar of dark chocolate and pass it around the group.

“I work in the same company as Stewart,” said Alan. “I drove past him on the way in. He’s on the bike, he’ll be here in a minute,” 

Just then Stewart walked in, helmet and bag under his arm, followed immediately by Daniel.

“Apologies all, I underestimated how long it would take to get into town on the bike,” said Stewart.

“I couldn’t find the room,” said Daniel.

“Right, we’ve got the whole team,” said Mary, “let’s get started.” 

She moved up to the white board and started writing.

“We’re trying to address two main groups, primary and secondary students. The outreach sessions have to take place outside normal teaching hours; we think we’ll be able to get 2-hour blocks on agreed weekdays, generally the afternoon. Although some schools may accommodate sessions during school hours we shouldn’t plan for it, we don’t want to attract criticism around distracting students from the core curriculum.”

“Can we expect that we’ll be delivering multiple sessions?” asked Paraic. “Or is it likely that some schools will only get one session?”

“Yes, realistically our teams might only make the one visit to some of these schools so the first session has to be good” said Neal. “And the whole initiative is being staffed by volunteers. Member companies from the various associations have said they will support scheme by freeing up employees for multiple 1 day blocks, but a lot depends on people’s availability, the time of year, size of class etc.” He continued, “we think the sessions should be run by pairs of engineer/programmers so there’s an operational challenge coordinating people at our end. But the biggest challenge we think is synching up with the schools.”

Yi added, “however our working assumption is to develop material for three, two hour long, teaching sessions that can be delivered by volunteers from our societies member firms.”

“And not forgetting,” added Neal, “material addressing the primary school audience and material addressing the secondary school audience. At least, that’s the current plan. It could be up to six different sessions in the basic model.”

“Excuse me,” piped in Daniel. “What are we developing and delivering?”

“Right,” said Mary. “My bad for not stating the overall goals. ‘Cool Software’ is being proposed as an industry supported outreach project designed to excite and involve Primary and Second Level students in maths and programming.”

“About the Lego?” suggested Amir. “What is it and why are we using it?”

“Can I answer?” asked Yi? Mary nodded. “We’ve all read the reports from the task force report dealing with the general decline in student numbers and results in Science and Maths. The knock on effect is putting the whole sciences/high-tech industry sector at risk in Ireland. These reports consistently highlight the need to raise awareness and create excitement about Science and Engineering careers. But how do you create this kind of excitement? We decided on Lego Mindstorms, everyone loves Lego, it looks fun, is fun, and using the kits can expose students to real programming and engineering challenges.”

“And if I can add,” interjected Stewart, “if we’re doing technology outreach, we can’t assume a lot of technology support in the classroom, particularly at the primary level. You’ve got to assume you’re bringing a stand-alone self-contained environment on-site. You can get LM up and running from a single box, no need to install stuff in their computer labs, at least initially.”

“And remind us,” asked Amir, “what are we going to be doing here for the next three days?”

Neal went up to the white board and spoke as he wrote. “Our objective, as Yi said, is to develop material for two streams of three, two hour long, sessions. One set for Primary level, another for Secondary level. It may be that we’ll see opportunities to expand the programme, but these are our basic objectives.”

“Right,” said Mary. “We’re going to start this morning’s meeting by writing user stories. User stories are brief statements of concrete deliverables or functionality, mainly stated from the user’s perspective. For example ‘as a student I want to make my robot drive faster so that it wins the race.’ As another example think about ‘as a teacher I want everyone on a team to get involved in programming the robot’”

“Those two suggestions seem reasonable,” said Amir. “How do we capture them?”

“We’ll write them on these index cards,” said Mary.

She handed out packs of index cards to the different groups.

“Ok, I’ll write up those two,” suggested Amir.

• As a student I want to make my robot drive faster so that it wins the race.
• As a teacher I want everyone on a team to get involved in programming the robot.

“Is it ok to have two different users?” asked Daniel. “Shouldn’t we treat them all separately, with separate meetings and separate planning?”

“Well,” suggested Mary, “if there were going to be two separate products, perhaps we could treat this work as two separate projects. In this situation it’s the same product – the outreach programme – just seen from two different perspectives.”

“What about the format of these user stories?” queried Daniel.

“We adopt the following style,” said Mary.

She wrote on the board:
‘As a... , I want to...  so that...’ 

“It’s a simple way of capturing who is going to use the feature, their goal and reason for the goal.”

“I’ve just noticed,” said Amir. “I don’t have a ‘so that’ for the second story.”

“That’s ok,” said Mary. “You don’t always need a ‘so that’ clause when it’s obvious or the goal states the reason.”

“So what next?” asked Yi?

“We try to write all the stories for the programme,” said Mary.

“All the stories?” questioned Yi.

“Not all possible stories,” said Mary. “Just those we absolutely need to meet the overall goals within the limits we’ve identified,” 

She pointed to the board and indicating the two programmes, one Primary Level, the other Secondary Level, starting with an introductory 2-hour session followed by other more advanced ones.

“Any more general questions before we start talking about the design of the programme?” asked Mary.

“Cool Software?” said Daniel. “I’m not sure about the name, should we pick another name? It’s not usually ‘cool’ to call something ‘cool.’”

“Thanks Daniel,” said Neal. “For the moment we’re considering it a code-name, we’ll get professional input later on how to brand it.”

NEXT STAGE >>