Development
Community
images/KulturBrauerei.png

Big Ball of Mud Dead Puppies and Other Fun in Germany

Some fresh views, new ideas and learnings from the Agile Meets Architecture conference in Berlin.
Harri Määttä
Site Reliability Engineer

Soundtrack for this post is here because, as chatGPT analyses it, “In summary, the song ‘Es wird viel passieren’ seems to express a desire for change and to awaken people to be more active in their own lives and in relation to world events. It criticizes excessive routines and passivity while emphasizing an individual’s responsibility and opportunity to influence the future.”

The two-day conference Agile Meets Architecture took place at the beginning of October at KulturBrauerei in Berlin. The conference was divided into two tracks, and the sessions were focused on issues in agile software development and how the (old) way of architecture culture could be improved. At conferences like this, in two days, you can get a good snapshot of theories and great “war stories” from real life, along with meeting people from the most exotic imaginable places on Earth, like colleagues from Pasila!

Here I have collected some takeaways to give a clear picture about the topics and atmosphere at the conference. Every session can be watched on their YouTube channel.

Agile Event in Berlin

My picks from the conference

Kevlin Henney had a session with the topic The Case for Technical Excellence. He had a ton of good points, like if your software is not agile, then you can’t be agile. This means that if you _can_ make rapid changes in your software, then you have achieved technical excellence. He underlines that software systems are made with software. Feature development is software development. One issue in “agile” that he raised is busyness. These days, developers have repeating deadlines, which is exhausting and doesn’t support technical excellence. Also a term like “business value” is difficult to utilise until it is precisely defined. Who are you creating value for? He also raised some good thoughts about estimates. He thinks that you can’t know the business value of a feature beforehand, you can only estimate it. The architecture tells you (developer) where you need to spend your time and money. Kevlin also had some good stuff about technical debt, such as explaining that debt is a financial word, and in which cases debt is a good thing. Overall, his outcome (one of those) was that the best architectures, requirements and design come from self-organising teams.

The first session of the whole event was Towards Architecture Organization Topologies for Sustainable Fast Flow of Change, held by Eduardo da Silva. In this session, architecture was defined as the ability to design and decide and learn. And not just learning, but also how to leverage. I like the term “sustainable learning, designing and decision”, which was used in this presentation. He thinks that the outcome in organisations can be a “fight” against a changing environment. Overall, the idea was that change and uncertainty would not end. The learning points were to think about how to learn more quickly through teams and to encourage teams to try and mess up. “Classic ‘controlling operating models’ and ‘ivory tower architects’ do not work well in complex domains!”. I think that it was good to raise the issue that organisation(s) are constantly interacting with a changing environment.

Another session was Transforming Ivory Tower Architecture to Enabling Teams by Michael Plöd. His idea was to run teams from economics of scale to economics of speed. One point was that architects are not (and should not be) somewhere on a level above. By preventing this, eye-level communication would improve and pitfalls (in transformation) would be avoided. Empathy is needed. His main idea was stream-aligned teams, where developers are able to make architectural decisions and enabling was key value for architects and stakeholders.

He told a funny real-life story from working life. The original idea in the company was that architects should coach, not just give instructions. In this story, even though the architect in the story had a good idea, they couldn’t get a raise, because the next level required that the employee has __instructed__ others, but this architect had “just” been coaching. Policy blocked process, and the company couldn’t give this poor employee a raise.

Gitte Klitgaard held a good session for all scrum masters, agile coaches, etc. with the topic Agile Coach Meets Manager. Her idea was that leadership hasn’t changed for ages. There are some barriers driving this: companies do as they have always done, and leaders don’t have the right tools. Managers and leaders are not always the same. There are some similarities to agile coaches and managers: coaching and helping people, listening and caring, communication, etc. Differences are like different responsibilities: managers are bosses, and they can hire and fire, etc. Based on her experiences, she suggested that many managers have not learned how to be leaders. People skills are underrated, hard skills are underrated and there is a lack of self-leadership. Overall, there are many things that need to be changed, and agile coaches can help managers to be better.

In the session From Software to Systems: Modern Agility, Diana Montalion, mentioned a good set of facts that we should be aware of: 1) We are moving from software to systems; and 2) we are terrible at system thinking. We need to practise.

She believes that modern agility is not a method of control:
- The ability to design and deliver systems (of software) in the midst of uncertainty
- 1) Share expertise by partnering
- 2) Respect each other’s leadership
- 3) Invest TEA (time, energy and attention)
- 4) Everything is (only) about learning
- 5) Donate and improve the rules of the game
- Be really good at building tech.

Also, she thought that, “Everyone who handles these five steps has been in good in tech. Being good in tech doesn’t mean that you are good in all five steps.”

The last session that I would like to summarise here is Innovation-Enabled, Value-Driven Architecture Evolution by Dave Thomas. This emotional presentation by Mr Thomas summarised quite well what we all think … I think. He think that companies are still doing stuff like in the old days, even though agile/XP has been in use for a quarter of a decade. A few points to underline from his thoughts are one-liners, like “XP is the best for teams to write software”, and “XP is great for mature software maintenance”. Instead of being code-centric, he focused on data and data flow.

I would like to end this post with Dave’s comment,
“Shut up and ship!”
-Harri

Berlin the best part of Germany

PS. The conference was filled with good book recommendations, and most likely, I can recommend these to everyone that is interested in the topic and has the skill to read. I was able to note down these books during conference sessions:
* Matthew Skelton, Manuel Pais - Team Topologies: Organizing Business and Technology Teams for Fast Flow
* Aino Vonge Corry - Retrospective
* Diana Montalion - Learning System Thinking
* Clare Sudbery - What is Trunk-Based Development?
* Tim Ottinger - Technical Excellence Workshop
* Niklas Sundberg, Helene Barnekow - Sustainable IT Playbook for Technology Leaders: Design and implement sustainable IT practices and unlock sustainable business opportunities
* Donella H. Meadows - Thinking in Sytems
* Adam Tornhill - Your Code As a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs (The Pragmatic Programmers)

PPS. “Dead Puppies” was taken from the session A Puppy Dies when Agile Meets Reality which was the last session, at the end of the conference. The session was a stand-up comedy session by Luxshan Ratnaravi. Luxshan is one of the writers of Comic Agile. This was one of the funniest sessions ever.

PPPS. (I should write a script with a loop to print these Ps!) ‘Big Ball of Mud’ can be seen as a monolith that has become overly complex, disorganised and difficult to maintain. And this most likely without specifications and planning. More details from the original source: http://www.laputan.org/mud/.