Developing and Delivering Products Professionally [P1]: Emergent Software Development - Dispelling the Myth that Scrum Teams Don't Think About Architecture

Question 1

How do you design your system?

Answer 1

• constraints impacting your system
• your system - context, scope
• users of your system
• any other system using your system

Question 2

What aspects need to be consider in a basic architecture?

Answer 2

• building blocks
• deployment
• cross-cutting concepts
• runtime - e.g. logging, persistence, domain model

Question 3

Give and explain the architecture pretzel

Answer 3

[SEE DIAGRAM]

Question 4

Give the Ken Schwaber 2006 quote about proving architect

Answer 4

“architectural ideas are not valid until proven out in a working system”

Question 5

What questions need to be asked when considering making an architectural decision?

Answer 5

• What is the cost of change?
• Is there a more important dimension?
  
  • e.g. use a repository pattern
• If we want consistency, how do we get there now?
  
  • setting expectations
  • consensus building patterns
  • communities of practice

Question 6

What methods can you try when you want to make large architectural changes incrementally?

Answer 6

• branch by abstraction
  
  • treat vendor products as black boxes
  • use existing tests as documentation of expected functionality
  • build alongside existing functionality, migrating clients as their needs are met

Question 7

What type of approach should be taken when several large architectural changes need to be made?

Answer 7

Incremental approach

Question 8

When a change is being made to the architect, what do we need to challenge the team to do? Why?

Answer 8

Have “just enough” and then put it into implement changes.

gives you more options to adapt.

Question 9

How to reduce architecture work time?

Answer 9

• use refinement to do some light early work to exchanges ideas + cross over skills - good understanding + more informed choices
• if you have to make a change later, usually that change has some additional value to it
• if you have to do rework - usually means made a bad decision early on
• not really reworking something - more informed and finding a better solution/get additional value

Question 10

Why can’t we have a sprint 0? (define architecture up front)

Answer 10

• never be done with it or satisfied+ never have all the info until start implementing and get better understanding of better solution
• What’s the cost of not changing? → value agility!!