To demonstrate and experience the intricacies of design and planning processes in a team environment when knowledge and expertise is distributed among team members.
Three `real' concepts up for grabs in the Design Play:
- feature/need (F)
- architecture/design elements (A)
- use/deliverables (D)
 |
| Role/identity cards for the Design Play |
Roles/Identities:
- The architect. Knows how features/needs relate to architecture/design and how architecture/design relates to use/deliverables. Creates diagrams linking feature/need (F) with architecture/design elements (A) and between architecture/design and use/deliverables (D).
- The product owner. Knows the value of each feature. Represents the user/customer. Is the authority to test and accept whether a feature has been developed to the user's satisfaction or not. The product owner can make a trade-off between value and timing of features.
- The developer. Estimates how long it should take to create a use/deliverable. Knows how much effort and uncertainty is involved in creating the use/deliverable. The developer can also suggest and estimate additional deliverables that don't produce quantifiable user value.
- Feature value, feature need
- Feature design, design architecture
- Design/architecture, use-deliverable
- Creative ideas, effort to deliver something
- Done versus done done
- Deciding what to do over the next (backlog)
- What do we want to deliver?
- How valuable is the feature/need?
- Show how architecture relates to use/deliverable.
- Does a deliverable satisfy this feature/need?
- Draw a design/architecture diagram of links between feature/need and the thing (use/deliverable)?
- How much time do we have?
- How much effort do we have?
- Sense demanding
- Sense giving
- Sense breaking
- Sense making
- The idealist
- The pragmatist
- The fool
- The follower
- The leader
- The purist
Debriefing
Is there a perfect solution?
Research and Further Reading
