arrangeres av Shiraz A. Bhaiji og resten av fagfolkene fra faggruppen Løsnings- og integrasjonsarkitektur
Kurset dekker fire temaer over fire dager (4 timer/emne).
Påmelding innen 25. januar:
Medlemmer: Kr 20625,- inkl mva
Ikke-medlemmer: 22500,- inkl mva
Påmelding fra og med 26. januar:
Medlemmer: Kr 21875,- inkl mva
Ikke-medlemmer: 23125,- inkl mva
Påmeldingen er bindende. Deltakere som er forhindret fra å møte, kan erstattes med en annen deltaker. Kun skriftlig avbestilling gjelder
Topic: Principles and Practices for Stream-Aligned Teams
We look at the constraints imposed by Conway’s Law and how we can turn these into a strategic advantage. The importance of teamsized software and responsibilities.
- What happens when we take a team-first approach to organization design?
- What are the trust boundaries across an organization and how do they influence behaviours with Dunbar’s numbers?
- How to reduce inter-team communication overhead with techniques like Team APIs, virtual spaces that promote well-defined team interactions?
- And more.
Topic: Reducing Cognitive Load with Supporting Topologies
We explore the goals, expected behaviours, recommended practices, primary interaction modes, and meaningful metrics for each of the supporting topologies. We will see how to assess cognitive load and whether it is effectively minimized by modern platforms, targeted upskilling, and contextualized abstractions.
Furthermore, we will see how a true organizational landscape emerges from aligning our existing teams with the fundamental topologies, and how that helps organizations adapt faster to market and technology changes.
Topic: Evolving Responsive Organizations
Agile clarified how individual teams need a customer focus. DevOps helped bring team collaboration to the spotlight. The “Spotify model” focused on team alignment with business value streams. Yet, there is still very little guidance on organization design for technology organizations. How do we know when to re-think existing teams?
- What happens when team interactions get awkward?
- Why are maintenance or BAU teams effective for resource utilization but terrible choices for fast flow and customer focus?
- What happens to some of the traditional roles (PM, QA, middle managers, software architects, support, etc) when teams become truly autonomous, with virtually no handovers of work?
- Why do we need co-design of the organization’s socio-technical systems?
Topic: Team Boundaries and Architecture for Fast Flow
There is an excessive focus on replacing monoliths with more fine decoupled software design, but what the business really needs is to decouple different works streams so that each of them can move at its own pace. Optimizing software architecture (moving to microservices for example) is the wrong starting point. We need to first identify relevant business domains (using mature techniques like domain-driven design, or lighter approaches such as Independent Service Heuristics), and the different streams of work within them.