The Guindon Design Experiment

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? What boundary objects used to make sense of the challenge?
What evidence of design work is available (diagrams, prototypes, experimental trials)?

Class of 2024/25 (25" deadline announced at 20")

Group ID	Test 1	Final Span (cm)
Bananagram	OK	90cm
Whatever	OK	55cm
Noodle	OK	60cm
Goodfellows	OK	80cm
Carbonara	OK	80cm
Creators	OK	80cm
Alpha	Catastrophic collapse	10cm

Class of 2019/20

Group ID	Test 1	Final Span (cm)
NinjaTurtles	OK	86cm
Rogue1	OK	51cm
Rogue2	OK	43cm
DontDrive	OK	78cm
TeamTape	OK	109cm
Waterslide	OK	75cm
FishingRod	OK	108cm

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

Guindon Design Notes:

In the late 1980s Raymonde Guindon designed an experiment to observe software designers at work while they were engaged in the process of creating a solution to a set problem. The software engineers, working individually, adopted a ‘thinking-aloud’ protocol and were observed directly by the researcher and videotaped for analysis.
As a consequence of these studies Guindon developed an understanding of design and development work as it unfolds over time; it is in fact a chaotic process of learning and reflection through trial and error. In essence the process of creating a solution to an ill-structured problem is itself un-structured, at least in the simplistic sense of being a planned, logical process moving from high level design to low level implementation in a smooth orderly manner. In fact the observations lead Guindon to the conclusion that software design work is largely underdetermined (Guindon, 1990).

“opportunistic decomposition is better suited to handle the ill-structuredness of design problems… top-down decomposition appears to be a special case for well-structured problems when the designer already knows the correct decomposition. .” (Guindon, 1990)

Guindon’s study demonstrated empirically that top-down design doesn’t occur as such in design work, or at least it doesn’t occur in a linear sequence from top to bottom. This has implications for lifecycles and frameworks that impose linear or staged phase structures based on the concept of top-down design-to-development processes.

Reference: Guindon, R. (1990) Designing the Design Process: Exploiting Opportunistic Thoughts. Human-Computer Interaction, 5, 305-344.

Spaghetti cantilever experiments over time

ASE Guindon Exercise 2013

https://photos.app.goo.gl/WnCQ1MFXQMYDJBFb7

Spaghetti Cantilever 2013 (class 1)

https://photos.app.goo.gl/n7yDyGLm3mppgHSu8 

Spaghetti Cantilever 2013 (class 2)

https://photos.app.goo.gl/CgeHbcozbjgDZcWP8

Guindon Exercise 2012

https://photos.app.goo.gl/D4h6H93MLhoYQp5x6

Are methods necessary?

How does systems analysis and design of software take place in practice? What is the role if any of methodologies in the organisation of development? The authors argue that

"traditional IS development methodologies are treated primarily as a necessary fiction to present an image of control or to provide a symbolic status, and are too mechanistic to be of much use in the detailed, day-to-day organization of systems developers' activities." (Nandhakumar & Avison, 1999)

The structures of organisation arise through experiences that solidify into practices over time.

"ad hoc development practices became institutionalized, forming structural properties of the team. The team members were therefore following these practices reflexively in their day-to-day activities." (Nandhakumar & Avison, 1999: 182)

The structure of methodologies is shown to be demonstrably broken across time, in the same way that the structure of life cycles have been shown to be fictions, not apparent in fact (Guindon, 1990). But if methods and life cycles are known to be fictions why are they employed? Are methods necessary and if so who uses them and why?

REFERENCES
Guindon, R. (1990) Designing the Design Process: Exploiting Opportunistic Thoughts. Human-Computer Interaction, 5, 305-344.
Nandhakumar, J. & Avison, D. E. (1999) The fiction of methodological development: a field study of information systems development. Information Technology & People, 12, 176-186.

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

MDD Class 2011: Guindon design challenge

The MSD class 2010 working on the cantilever problem

The following slideshow records The MSD class 2010 working on the cantilever problem.


The Guindon design exercise says something deeply important about the dynamics of design work in teams addressing partially specified problems.