You can't be agile when you're fighting your code - ALLEN HOLUB | Craft Conference 2021

This talk was recorded at Craft Conference 2021. Allen Holub from Holub Associates spoke about the intersection of process and architecture.. Architecture (of both your code and your organization) and process are interrelated and interdependent. Change one and you must change them all. Agile transformations fail when the code and organizational structure don't change to make agility possible. A new software architecture will fail if your organizational architecture doesn't change to support it. In this lecture, you'll learn: • How architecture, process, and organizational structure interact and why. • How Agile principles and values influence software and organizational architecture. • What an agile-friendly architecture looks like and how to create one."
The event was organized by Crafthub.
You can watch the rest of the conference talks on our channel.
If you are interested in more speakers, tickets and details of the conference, check out our website: craft-conf.com/
If you are interested in more events from our company: crafthub.events/

[@kourosh234]

Our biggest problem as programmers is that the organization says despite the fact that we know that the way we are working is wrong, so this is the way our customers are asking for!

[@buckstraw925]

The item that is most dynamic is the business logic. If you allow the business logic to be pushed into all the modules then you have a nightmare when things change.

[@IngoBing]

Lot's of food for thought here!

[@nandoflorestan]

35:46
I love all of Holub's lectures, but the answer to the first question disappoints me. I understand getting rid of technical debt is not a *user* story, but then another kind of task must exist, because getting rid of technical debt is essential, because of the title of this video.
Dealing with technical debt prevents team failure. Letting it remain guarantees failure. When he says "so we've failed"... that bit is backwards. 36:54
Even for one team member to occasionally spend one week or even more just refactoring... is often necessary and very beneficial to the speed of the team. Therefore every empowered team will spontaneously deal with *important* technical debt, and if it requires a lot of time, then it requires a lot of time.

[@aslkdjfzxcv9779]

💯

[@mastermikeyboy]

Great talk. For future talks, the presenter should mute his mic or have better filtering during Q&A as we can hear Allen through his mic.

[@emaayan]

14:05 the other other issue is simply trust, organizations are not gonna go completely strucutre themselves as well as the code just because one consultannt told them too because who's to say another one won't say the same in the future.

[@piotrkozbial8753]

Ok, so we want to deliver every hour and only in terms of user stories. I fail to imagine what kind of a user story could be delivered within an hour....

[@roddypine6077]

Stories are requirements and DDD is a process. If the story requires you to expend a week with the database is because it DID require a week.

[@BryonLape]

Every presenter seems to define stories differently.

[@addcoding8150]

can confirm:
The Japanese is correct. I would have used another kanji, but it is accurate.

[@piotrkozbial8753]

The question that mentioned CAD: a good example how this does not work and I suspect that the speaker has only worked on the one kind of application: the typical business-oriented DB+UI type of applications. The answer given to that question completely misses the point.