 An Agile Architect in Large Scrum projects Johannes Brodwall Chief scientist, Steria 

 Contents  Case studies  Observations about enterprise architecture ▬ Unintegrated architects lose sight of the ball ▬ Teams without sunlight wither ▬ The new and the old will coexist ▬ Standards won’t stop a bad team from misbehaving ▬ Good teams communicate  Conclusions and questions

 Definition: Large project

 Case studies

 Architecture council Architecture team Infrastructure team Interbank svc team Payment svc team Information svc team Online team Online subteam Case study 1: Banking

 Experiences  Architecture and infrastructure teams wrong focus  Misguided advice from architecture  Enforced reuseability => poor usability  Technological standards => heavy toolbox  Incomplete picture => expensive, unfit, infrequent deliveries

 Architecture community Architecture forum

 Improvements  Most standards, reuse, design are considered tactical, team-level decisions  Architecture team => architecture community-of-practice  Technological simplification  Broader team responsibilities

 Supplier 3 Case study 2: Pension fund Supplier 2 Supplier 1

 Experiences  Teams trapped between product owner and architecture team  Misguided advice from architecture  Technological standards => heavy toolbox

 Case study 2: Pension fund

 Experiences  Focus on usability enable more frequent releases  Pair programming with rapid rotation creates collective ownership  Mob programming across teams creates a shared technical culture

 Common observations

 Observations  Unintegrated architects lose sight of the ball  Teams without sunlight wither  The new and the old will coexist  Standards won’t stop bad teams from misbehaving  Good teams communicate

 Unintegrated architects lose sight of the ball

 Integrate the architects  The story of the push parser  Architects speculate rather than investigate  Architecture team: A team has two masters  Architecture Community: Exchange experience  Coming up: The principle to divide a project

 Teams without sunlight wither

 Every team is a UI-team  The story of the rules engine in the basement  The story of the Enterprise Integration Bus blocking the door  Not knowing the user leads to expensive, unfit, infrequent releases  Misguided SOA initiatives removes teams from the user

 The new and the old will coexist

 Do ”live betas”  Coexistence is a good thing  Accept it as soon as you can  The story of the impatient CIO  The story of salvaging some value from the ashes of the unsplittable project  The unremarkable story of the release for the service reps  Knowing the user + accepting coexistance => frequent delivery

 Standards won’t stop bad team misbehaviour Cade -

 Don’t make strategic choices for tactical problems  Stop and think: Which parts of your present project do you want to be stuck with in the future?  The balance between duplication, noise and paralysis  Tactical decisions: ▬ What framework and libraries to use ▬ What to reuse, what to recreate ▬ Use of rules engine etc  Strategic decisions: ▬ Everything that creates work for others

 Good teams communicate

 Create spaces for sharing knowledge  Daily communication with customer  Pair programming  Mob programming ▬ Dojo ▬ Spikes ▬ Reviews  Internal (un)conferences  You can help create a culture, but not via paper  Meetings and documents is where communication stops

 Observations about enterprise architecture  Unintegrated architects lose sight of the ball ▬ Communities of practice instead of teams  Teams without sunlight wither ▬ Every team should have a UI  The new and the old will coexist ▬ This is good news, embrace it!  Standards won’t stop bad teams from misbehaving ▬ Leave tactical decisions to the tactical level  Good teams communicate ▬ Create spaces for collaboration

 The patience to accept the things we cannot change; the courage to change the things we can; and the wisdom to know the difference.

 Johannes Brodwall Chief Scientist Steria, Norway Thank you for listening 