Agile meets Architecture: Connecting the Dots
Note: No AI has been used to write this article, for better or worse.
This article was written in March 2025, and later re-published on my new blog.
Recently I had the incredible opportunity to attend and speak at the Agile meets Architecture. Conference in Berlin! The conference was fantastic, the organisation was impeccable and the location - the famous Berlin Kulturbrauerei - of course a perfect backdrop for this event! I met many incredible people, had a fantastic time and learned a lot! My colleague Berrin Akvardar and I were there to present our talk on "Shift-Left for Learning - with the Help of Enabling Teams". The experience was both wonderful, and incredibly nerve-wrecking - our talk was going to be the last on the programme, so it felt like nailing jelly to a wall to make my brain ignore the fact that our session was coming, while trying to pay attention to each talk. If the speakers weren't as stellar as they were and so good at holding my attention, I might have not been able to write this blog post - and you might have been happier for it. But it is what it is and the post is here!
While I was listening to the talks, I had a recurring thought each time which would go something like "oh, this fits great together with ... from that other talk". So many interconnected and related ideas, different perspectives and fresh metaphors. So, I thought, I would love to do a "Connecting the dots" post for the conference.
Sadly, I couldn't watch all the talks, and am still patiently waiting for the videos to appear, but in the meantime, my post will focus on the talks I did see (and one which I didn't..)
Simon Wardley - From Here to There and Back Again
Starting off with the ever so brilliant Simon Wardley who delivered the opening keynote on Wardley Maps. And what a stellar opening for the conference it was! I can't pretend to do it justice, but I can at least share what it made me think about.
What do you think of your company's strategy? Can you understand the reasoning behind it, have you attempted to evaluate it? What if you had a tool to do both of these activities with much more ease? Wardley maps give you just that, and more. It's astounding we are not using them routinely for decision making. It's safe to say that once you've tried Wardley maps, you can never go back to any other strategy frameworks, SWOT analysis and the likes.
A Wardley map forces you to anchor your thoughts at the user needs. It gives you additional dimensions to explore and guides you how to play with them. It is simple: Determine your users needs, map out the value and supply chain you need to meet these needs and put each link of the chain in its evolution state (genesis, custom-build, product, commodity). Your business is suddenly a network of elements or components, each in a different evolution stage. This already gives you an opportunity for so much insight - if you have a dependency between two components of very different evolution stages, this might be a pain in the butt because they will tend to change at different rates. Or, like Simon shared in his talk, if you're contracting out multiple components of different evolution stages to the same contractor, you'll be in for a ride - you simply can't expect developing cutting edge tech or working in a novel space to behave the same as integrating a fairly ubiquitous product.
Add to this, the direction of movement on the map - with component evolution being inevitable, and his climatic patterns and suddenly, you can play a rich, immersive strategic game and reason about different strategies with ease. Anyhow, a map makes issues and opportunities really pop and stand out. There is power in visualising things, making them explicit and clear. And here is the first connection I want to make
When talking about visualisations and software architecture, of course we can't go on long before mentioning diagrams. The C4 model for visually expressing and communicating software systems, introduced by Simon Brown, has now been around for over 15 years. It's inspired by the realisation that different audiences and purposes are best served by different type of diagrams. Simon shared a lot of his experience on working with companies across the world and helping them on their architectural issues. He shared that even after so many years, we still struggle with the same issues of communication and lack of understanding between different roles. Especially close to home was his observation on teams knowing their local context, but missing the bigger picture.
A Simon Brown's C4 Diagram on a Wardley Map?
The "big picture" is just another way of saying that we seek to understand the interplay between several subsystems. Because after all, teams are not truly independent - otherwise we wouldn't bother to seek a big picture - so we'd like to know how a change in one part will or could affect other parts. Simon Brown's C4 model is a great tool for visualising and understanding the big picture (and also detailed views) of a technical system. But having heard Simon Wardley's talk on mapping, it got me thinking about evolutionary stages and changes in the evolutionary stage of a component. Let's say we have a C4 model diagram, i.e. a context diagram. Each of its components will exists in its evolutionary state - some might be relatively innovative parts we are experimenting with, other will be rather solid, old and rarely changeable - like commodities we don't often pay much attention to. When an evolutionary change happens in one component, it will cause ripple effects through other components. Enriching C4 diagrams with the evolution dimension from Wardley mapping could be a useful tool for developers, teams and businesses to reason about systems and design in order to make better decisions: If something becomes commoditised, what innovation will this change open the doors for, or what issues would it cause for us? If we have to decide whether or not to invest in new functionalities in part of the business that we are custom-building ourselves, but realise that this capability has long been available as a mature off-the-shelf product that has the functionalities we need, it might make sense to look into buying this product instead of keeping the in-house solution going.
Jacqui Read - Design Patterns for Software Diagramming
When it comes to architecture diagrams, both Simon Wardley and Simon Brown point out that the engineering lingo is difficult to understand by business people. Simon Wardley compared it directly to "Elvish". Simon Brown shared a quote by Thomas Betts "Every software problem is fundamentally a communication problem". A good thing Jacqui Read was at the conference! I was so bummed I missed her talk and will have to wait to watch the recording. However, she brought the topic of "Design Patterns for Software Diagramming" - how to apply design patterns, so that our diagrams aid communication and collaboration instead of causing confusion. Her book "Communication Patterns" has been a great source of inspiration - I know I fall for some of the anti-patterns she talks about, and have been using her tips to improve on my own communication. I remember sitting in countless meetings staring at diagrams full of anti-patterns, struggling to understand them while the presenter was already half-way through their narrative. Whenever that happened, I would ask other people in the meeting if they understood the diagram - more often than not, I was not the only one struggling. Now I know why! Some anti-patterns I've often seen, which have been most difficult for me to deal with, include having too much visual clutter, often mixing multiple granularity levels, and most annoyingly, using too many acronyms with no legend! I guess these are some of the reasons why unified diagram models like C4, UML, etc exist - defining a set of elements and diagram types helps us avoid some of the anti-patterns.
Markus Harrer - Evolutionary Software Design
A talk that had great visual style and easy to understand visualisations and diagrams, was Markus Harrer's "Evolutionary Software Quality". He made the observation that as a product (idea) goes through different evolution stages of development, different quality criteria matter more than others. Especially interesting was the point that at the same moment in time</i>, often what matters to the business is different from what matters to developers. For example, the maintainability of the codebase is usually one of the most important things for developers, but often lands on the last spots of what the business values. Driving Markus' insights was also utilising Wardley Maps and reasoning about product life cycle and evolution.
I wonder if using Wardley Maps isn’t one of the most useful thinking tools we've learned about in the last few years. Markus' talk has been eye-opening for me though for this one subtle observation - different groups will differ in their understanding of what's most important. Acknowledging this instead of ignoring it, can work much to our advantage - only by doing that did Markus arrive at a model that can be incredibly useful to both business and developer groups. As luck would have it, a little later on I was sharing a table with both Simon Wardley and Markus Harrer, along with Carola Lilienthal in Eberhard Wolff's Software Architecture Stream on Wardley Mapping for his YouTube channel.
Simon Rohrer - 4 Lenses on Organisations
A true masterclass in connecting the dots. Simon spoke to us about these 4 lenses:
Team Topologies and Value Stream Management
Sooner, Safer, Happier - Nested organisations
Viable systems model
Gaseous, Liquid, Solid organisations model
What stayed with me most was the last concept on liquid organisations. He spoke about different forms organisations could have - solid, liquid or gas. A solid organisation would be very rigid, resistant to change, stale, whereas a gaseous organisation are too chaotic, with no clear direction. He describes that through this lens, a liquid organisation that balances autonomy and alignment is an ideal to strive for. A liquid organisation would have both governing and enabling constraints, would be able to understand and navigate the complex and create just enough bureaucracy. It's interesting to think about how a solid organisation could thaw and how a gaseous organisation could become more liquid. That's where I think there is no simple formula - every organisation is "solid" or "gaseous" in its own way, with its unique patterns, working off its own (sometimes invisible) principles. But when introducing change in an organisation, we have to think about what we wanna achieve - Simon mentioned the case of Start-ups becoming Scale-ups and then suddenly deciding to "mature" by bringing in a lot of project management, bureaucracy and waterfall style development. I've heard business owners speaking about these type of "transformations" before with a lot of regret - mostly due to lack of knowledge on modern alternatives to organising and continuous improvement, but also - the abstractness of some of these modern approaches. The "good old" waterfall is so readily available to regress to, still can feel like a comfort blanket, with its promise of certainty, of "figuring out all the details before we start", especially when it is the common method used in your industry.
Speaking of waterfall...
James Lewis - How Flow works and other Curiosities
The many hand-offs waterfall created in the name of predictability, quality and governance can be hard to get rid of. We know they are inefficient, we even know they can mess up the very same "quality" we are trying to ensure, but it never seems urgent enough to invest time to start removing them. James' talk on Flow gave us a lot of tools on how to drive attention to this topic. Mapping the way value flows through your system can be an eye-opener - seeing these waiting time accumulate, discovering inefficient back-and-fourth "processes" wasting valuable time can really help you grasp how much potential you're not able to tap onto, just by staying idle.
James' talk was packed with lots of insight, and definitely something I am bringing in to my own teams to learn from. For example, the ever painful topic of metrics and the never-ending tendency to target metrics in the name of "improvement", "quality" or "excellence". How many times have I seen cycle time being targeted, or predictability. Then inevitably, it's been cheated! James reminded us that cycle time is a lagging indicator - so not something you can directly optimise/control for. To get that improved, you have to look for a leading indicator that is linked to it and you know leads to a improvement in cycle time. It can be really tricky to find these, but for cycle time it is fairly easy - batch size! Smaller batch sizes give you shorter cycle times! Now we only need to get the teams on board with all that slicing! :) James opened his talk with a sharp paraphrase of Charles Stross: "AGI is already here. We call them companies and get paid to execute their algorithms very slowly". In a way it rings true. The companies we create or work for form their own intelligence, collectively moulded by us humans, and now also increasingly LLMs. We tend to not think of companies like this, at most we think of them as some sort of factories with assembly-lines, Taylor style. Shifting our perspective towards seeing them as intelligent beings opens the mind to perceive them as organisms, adapting to an environment.
Figuring out how work flows through this "organism" is no small feat - it can be incredibly daunting, as in many companies, things get so complex, that you will rarely find anyone who has a complete overview. More and more, you have to get people together and figure out how to enable them to effectively collaborate. It can sometimes be human issues in the way!
Kenny Baas-Schwegler, Evelyn van Kelle - Collaborative Software Design: How to facilitate domain modeling decisions
Kenny and Evelyn shared with us their experience on facilitating diverse groups in the context of collaborative software design. What stayed with me from this talk was how subtlety shapes social dynamics. One little gesture, or an automatic response we don't think about can lead to biased outcomes. Take rank for example - the way we are used to associate social rank/authority with certain groups. Due to social rank we tend to direct questions towards elderly white men, rather than women or towards the more extroverted among us, rather than the quiet ones. If we go by, unaware or ignoring this bias, we might miss important viewpoints, or fail to give recognition where it is due. What can help all of us though, is to be aware of your rank, own it, play with it and share it - if you are in a high rank position - share it, invite others!
Facilitating groups and navigating group dynamics can be very tricky. Evelyn and Kenny talked about the concept of the shadow - everyone bringing their own shadow to a collaborative session: Our state of mind, fears, insecurities or worries for a sick family member all affect us. Gone are the times when we thought we can leave them at home when we are at work. We know now that's not how our brains work. So, we have to acknowledge that every one of us comes with their shadow. Once we do that, we can actually start dealing with that.
And a facilitator can help with that - paying attention to people, their reactions or even if they are not reacting. If you're facilitating a team you know, you notice when someone is unusually quiet, and then you can do something about it - what the right action is also depends on the person and relationship you have with them. The point is though, to act with as much awareness as possible... Where Simon Wardley talked to us about situational awareness in terms of technical components and their evolution state, Evelyn and Kenny teach us about having awareness of the humans we work with and their biases and psychology. When we are in a group, collaborate and make decisions, both types of awareness is needed - of the "factual" side and the "human" side - both will play a role, the social rank of a person will inevitably put a high weight behind that person's views of the factual, thus influencing decision making of the whole group. A well prepared facilitator can avoid these traps.
More often than not, effective facilitation this is not just nice to have. Companies invest in of collaborative problem-solving especially when the stakes are high - bringing people together is costly and time-consuming, and can have unclear outcomes. One context in which this happens is the ever-green topic of architecture modernization.
Eduardo da Silva, Nick Tune - Towards Effective Execution of Architecture Modernization
Eduardo and Nick talked about addressing common pitfalls when undertaking a big modernization effort. Unsurprisingly, architecture modernization can be one of the hardest and unpredictable things a company could do - every modernization journey is unique, the constraints of the organisation, its structure, politics, support, etc will be different. Still, Nick and Eduardo showed us some patterns they've come across over and over and give us some hints on how we can deal with them.
One thing they notice is that, while a kick-off modernization workshop, i.e. an Event Storming session, can be very energising and motivating, it also doesn't usually reveal the really tricky issues that will pop up down the line. There will be roadblocks, and you have to be prepared to run a marathon. And to do that you might need to train - work on skill gaps, unblock architecture capabilities, and find the right way to communicate with leadership to gain support. The issues can be numerous and really hard to overcome, and when we discover them, it can be really tempting to fall back in our old ways and succumb to inertia - sounds like a challenge enough where a team might do a better job than a single person.
And this is where the Architecture Modernization Enablement Team comes in. They describe it as a "strategic pattern to accelerate improvement of architecture capability and overcome modernization inertia". Especially in the beginning- to mid-phase of a modernization journey, this team can help sustain the momentum gained in the initial sessions and activites. A dedicated team that will not itself do the modernization, but rather will help teams develop relevant missing skills like test automation, CI/CD, decision-making processes, DDD, product discovery and UX design, etc.
Time for Learning
I found that Eduardo and Nick's talk had great parallels to our own talk on "Shift-Left for Learning - with the Help of Enabling Teams" - we also speak about the significance of having an enabling team when it comes to establishing and honing a company's ability to create a learning culture. Especially when a company is seeking to modernize, the amount of learning and knowledge that needs to circulate can be much higher than what everyone has been used to. Suddenly, it's not just about learning some technical skills once in a while on LinkedIn Learning. It is about learning new skills and applying them on the job, possibly within a system you don't fully understand. We need to circulate both tech knowledge, and domain knowledge. When we are not used to doing this, the energy cost for people can be very high and so the risk of falling back to just not doing it and slowing down the pace. An enabling team again can be the answer to combat inertia, until the new behaviour becomes natural.
The Enabling teams emerge for me as a great pattern to fight inertia in companies - and this to me is how multi-team management should work - we team up and manage the environment: The access people have to needed tools and knowledge, the time they can invest in learning new crafts or experimenting, the support they need in getting together to collaborate or exchange, and the clarity they need in terms of how to progress and make decisions.
One last thing...
The Agile meets Architecture conference in Berlin was a truly rich event - rich in topics, rich in connections and rich in inspiration! I even got invited to share the stage with Michael Plöd, Eduardo da Silva, Simon Rohrer, Kenny and Evelyn, and Carola Lilienthal for the Team Topologies panel! That was an amazing experience and only my second panel on a stage! Michael who did a fantastic job moderating, as usual, had prepared some interesting questions both for us in the panel, and for the audience. It was really interesting to see the interest the topic has generated, even though the book is already five years old. It speaks to the fact that even though it is a model and thus imperfect, it is indeed a quite useful one, to paraphrase George Box. I am thankful to all the organisers of the conference, for bringing this event to live and tirelessly and without brag, working their magic to create this unforgettable experience! And I can't wait to watch the talks that I have missed!
Watch the talks on AmA's YouTube channel!