Architecture and Agile went to a bar. They start to argue on how and when and who and where and at what order to deliver a beer, but the overarching question was .. why?! The bartender shot himself, went out of business and started selling oranges.
Great talk Simon. The comparison of fixed vs growth mindsets w.r.t. agile strikes a chord with me: too often I see frameworks, coaches, processes, etc. as evidence the "we do agile" but the organisation has missed the point completely.
Very interesting. I don't disagree with any of what Simon says but we need to factor in the organisational ability. Simon worked for me in the 90s and with a couple of other guys made up the best team i have managed. Extremely bright and like Simon said could exercise at different levels of the organisation and technical roles. In big enterprises it is much more difficult because that consistent high quality is not there. So my question is if the team has not got the skill and discipline would this not just result in failurewith potentially massive business consequences.
Thanks Erwin! Hope you’re doing well! Couldn’t agree more re team skill (there’s lots I couldn’t talk about in just 35 mins), part of what modern EAs need to do in the ‘organization architecture’ part of their role is spot and call out those skill gaps and the risks that are there if the 2-pizza teams don’t have the right technical leadership and skills within. If teams don’t have high quality and discipline, and in particular don’t have a technical lead who is a go-to person for ensuring and role-modelling that - for sure, there is failure, I still deal with this on a very frequent basis. This happens regardless of the model you choose! Happy to chat more some time :)
Many thanks for pointing to 'business value' ! I was surprised to find out that a lot of 1st line managers and team leads in the outsource company does not have clear sense of this tricky balance of value to the customer vs value to the employer.
No disagreement, but what to do when sales and management keep promising feature after feature, to keep the customer buying, and you spend more and more time adding quick and dirty features and fighting fires instead of repaying the technical debt? This can't end well at all, that is obvious, but how do you get out of this cycle?
Thanks for the thought provoking content. 👍🏼 I really liked the fast-slow decision matrix. I would have appreciated having the presentation presented full screen during more of the recording.
To me, it feels like Gerrit doesn't do presentations in English very often. I appreciate his writings in German, but this presentation is a disappointment. Especially the fact that it tries to convey both theoretical and practical aspects in a short time frame makes difficult for me to find the "what is in it for me" bits. (I read the blue DDD book and an introduction to the Systems Theory along with a couple Luhmann articles. Also, I work in an embedded domain, not in the business IT).
Curious to see your opinion on large (100s or 1000s) orgs working in one code base, where VPs may continuously kingdom-build and reorg. I believe this is the "self-organized" being violated. There is also something about the number of people sharing ownership or having in the past had ownership that leads to degradation of code quality
Yes, when teams are formed, changed and disbanded at will by management then there is little space for self-organizing teams. It also has the effect that code ownership gets changed, and people will start getting detached from it, not feeling responsible, not feeling pride to keep it clean.
I'm not so sure about the French proverb thing. It is "Je suis a Paris.", but is also: "Je suis en France". The French proverbe "en", is not really a contraction of "à" and "là" but is specially used for countries. In both cases they mean "at".
More people need to hear this message! But most people only design 2 or 3 systems in their life. It’s only when you’ve designed 5, 10 or 20 systems that you can see the patterns and know what good looks like.
I'm very much the kind of learner who needs motivation to learn. I can't just be told to look into something, and then be asked to produce something good enough. I also like to iterate on stuff. Go back and make things better as I have reflected and looked into the subject some more. I'm not a person who liker or handles the pressure to do something. I'm not just a simple doer. I'm a curious learner at heart.
Rebecca Parsons delivered an absolutely incredible session, brimming with invaluable insights cultivated over years of dedicated work. A heartfelt thank you to Rebecca for sharing such an enlightening and thought-provoking talk. It truly was a remarkable experience.
I got too late aware of the conference, so it would be greate to me to see as much as possible. Liked the talk of Rebecca. Many basics and good insights. Looking forward for further talks
