This document discusses how to implement iterative design practices within agile development frameworks. It notes that while user stories and test-driven development brought iterative requirements and testing, design practices have not been as clearly defined. It suggests that collaborative design approaches that leverage the knowledge of self-organizing teams can help "the best architectures, requirements and designs emerge." The document then examines how agile ceremonies and definitions of done can support iterative design work.

2. Synopsis
User Stories moved us into iterative requirements; TDD brought us iterative build
& test. So how do we do iterative design without ending up with a Big Ball of Mud?
How do we make "the best architectures, requirements and designs emerge from
self-organising teams?" a reality? How do we collaboratively design to take
advantage of our shared brain power, and grow people at the same time?
In this context, what is the difference between architecture & design anyway?
How do we use Agile ceremonies and the Definition of Done to make it work?

3. We have incremental requirements
Big
Idea
Big
Idea
Feature
Feature
Feature
Theme
Theme
Theme
User
Story
User
Story
User
Story
TimePhase
Gate

4. We have incremental testing now
CollaborationRecrimination

5. XP tells us if something is good we should do more of it
Requirements, Design, Coding and Testing are activities and not events
XP: Simple Design, System Metaphor
Agile: The best architectures, requirements, and designs
emerge from self-organizing teams.

6. So if we think Design is Good, we should do more of it

7. The Ceremonial Dial
Relaxed
• Few Documents
• Light Process (Small DoD)
Formal
• Careful Documents
• Traceable
• Audited

8. Module 2
Module 1
Design or Architecture
Think of this
Module 1
Module 2
Class A
Attr 1
M1
Class B
Attr B1
M B1
Class A
Attr A1
M A1
Class B
Attr B1
M B1
IntF AB
Attr AB1
M AB1

9. Exercise
Think of design and architectural issues
Let’s take 5 and shout
out some thoughts here

10. ElaborationRetrospective
PlanningDemo
Story Time
Lifecycle of a
sprint

11. Lifecycle of a story
Design
Testing
Requirements
Coding

13. How does A3 work
Use of templates
An A3 per story? Maybe
Are A3s reviewed and agreed?
See your DoD and ceremonial level

14. User Story US167 Story Lead John Smith
User Voice Acceptance Information
As A Development Team
I Want To Create the persistence structure for
component XX1
So That The teams(s) can develop the
functionality of this component
Given Starting Point XX1
When I perform a read operation
Then I get the data I selected
Given Starting Point XX1
When I perform a Update operation
Then I update the data I selected
Given Starting Point XX1
When I perform a create operation
Then I create the new data
Given Starting Point XX1
When I perform a delete operation
Then the data I selected is deleted
Analysis
The class model for component xx1 is
And the ERD we have worked on is
1. We need a database structure to reflect these entities and a set of hibernate
configuration to map the models together.
2. The Product table will need a primary key on the product ID as our estimate for
max rows here is 3,700,000
3. Note that this data is impacted by the DPA and upcoming GDPR legislation
Tasks So Say all of Us
Create the table Person with the columns
as shown
Create the table Product with the columns
shown and PK
Create the ORM configuration
Create test data for the Acceptance criteria
Create automated tests for the acceptance
criteria
Mary Smith
John Khan
Jane Doe
Billy Chin