Businesses are increasingly recognising that “the best architectures, requirements, and designs emerge from self-organising teams”. From an Agile perspective, the role of the architect can actually be seen (and applied) as one of motivator, broker and curator of ideas within the self-organising team – as opposed to the source of ideas. The minute we try to apply architecture within an Agile practice in any meaningful way, we run up against a few tough challenges: how do we convert business requirements into implementable design when we’re developing in short iterations (sprints) and in small increments? Who owns and maintains the ‘big picture’ in terms of the design process for a product/project? This session addresses these questions and how architecture works when teams are Agile and self-organising. We’ll look at the benefits, challenges and some real-world examples of how architecture is (and can be) applied successfully in an Agile practice.

1. Surfing the Wave of Emergent Design
Bernard O’Leary
CallPlus Group Limited
Your pic

2. “The power to make
buildings beautiful lies in
each of us already.”
– Christopher Alexander

3. Why is Design Important?

4. Themes
Planning to fail vs. failing to plan
Collective brain-power vs. design “hero”
Learning Objectives
Incremental experimentation and failure as a design strategy
Coping with fatigue; design adjustment and refactoring
How to assess what level of design is appropriate, when
Capture the collective design-oriented brainpower of a team

5. Perfectionism
vs.
Experimentation and Failure

6. Architectural Experimentation and Failure
“Think global act local” applies
Maintain big picture as an overall objective
Balance level of process and design control against nature of business
Test/fail early; rule out non-viable options and mitigate risk
Maintain design pivot as an option

7. Big
Design
Up
Front
- Review

10. Emergent
Design -
Review

11. Agile Development
The Theory

12. Agile Development
The Reality

13. Some Sprints have a greater
design component; some
lesser
Some functionality requires
more infrastructural work
We’re designing, testing and
refactoring as we go
We’re focussed on customer
value as opposed to generic
throughput
Why’s That?

19. Emergent Design
Each change in direction represents a cost
Cost is in design adjustment and associated refactoring
Incremental design cost is incorporated with each iteration
Design adjustment and refactoring is uncomfortable, perhaps scary
Like anything, the more you do it, the better you get
The alternative is scarier – BDUF
Help is available…

20. Team
Brain
Power

21. A
Design-Oriented
Super-Computer
Collective brain-power outsmarts individual
Promote discussion and experimentation
Self-organising team as a super-computer
Architect as a catalyst and curator of ideas

22. Closing Thoughts
Collective responsibility
Plan to fail
No silver bullet

23. Thanks for listening…
Bernard O’Leary
CallPlus Group Limited
Follow me @bernardoleary
Your pic