the "goals" are noble, however i'd like to point out that true leaders do not ignore people. they coach and mentor them to become (better) leaders too.
Out of the whole talk, only one point I disagree with: Part when he discusses organizational oversight "WebService compliance architect" 30:40. Some competences do not scale; some are regulatory - you can't expect a person responsible for a narrow field to be directly engaged in a legwork with a team; and you can't expect to hire such a person per team. In essence, this is an example of a situation where the team should definitely drop the dogmatic approach to independence.
I could immediately connect with the given example: Someone with a title walks in, "entitled" to get a report, where neither the team understands the purpose, not the requestors understands the work output of the team. That's why many processes, reports, quality indicators etc in "BigOrg" are so entirely detached from and counter-productive to SW development: Parties are not willing to sit down in order to understand each other's needs, but rather insist on remaining in their isolated silos. I still have wet dreams about a quality department to have an actual clue about SW development, the KPIs they are supposed to collect, and the impact their demands have on development performance.
A refreshingly realistic take on agile SW development in BigCorp that you find seldomly discussed, yet will encounter around every corner in RL organisations.
Have I understood correctly what he was saying regarding change agents? Basically, if you are the one, who tries to make changes in the processes organization, you're pretty much fated to leave the company soon, because you will be resented? This is pretty dire outtake.
Fred's go-to approach is a classical consultant strategy: Go straight into it guns blazing, turn stuff inside out with top management approval, bypass all the middle management while at the same time make them look really bad, then establish a status quo the middle management can't easily roll back, and move out again, taking all the credit. Nobody within an organisation can do that without negative consequences to themselves. It's actually a great argument to hire a consultant in order to get radical changes done.
Very realistic talk. I have been on the same mission and journey for 15 years helping different organizations. I used some of these strategies without noticing :). It is very nice to learn about other techniques.
Agile design does not account for structurally changes. If you have a shared function between 2,3,4 you name it, different domains, which need to be centrallized and the customer needs some fundamental changes, you are standing with your back against the wall. At this point as a developer you only got 2 options: Produce shitty code or make a huge refactoring. As the system growes and more people are involved, this problem will lead to end endless cycle, leading to project, that either are fast and produce ugly code, no one understands after 5 years in production or leading to endless refactoring cycles. You need the right persons, with enough domain knowlegde and a basic structure, which then is agile enough to change and doesn't have too many dependencies in the end. This is really tricky, because you dont want calculation code (f.e. invoicing sales and orders) to be done twice, as this can lead to massive differences when code is changed only in one domain. Therefore you are forced to refactor anyway. The bigger the projects get, the more unefficient agile will get, when there is no clear predifined structure/architecture in the code. Alternativly you can ignore the fact and build the ultimative home with no foundation, which means the technical dept needs to be absorbed by the customer at any time sooner or later in the furure in reinventing the wheel again. Love your talk
Some good ideas, but the assumption that all leaders are men, and that combat is the only way forward kept me sufficiently distracted that I didn’t absorb much.
This comment makes some pretty naïve assumptions about both men and women. And it really only highlights that you are indeed not able to pay attention to anything without projecting whatever wild chaos is going on in your head from the last Reddit comment you read. Just take a second to take a deep breath and allow the speaker to present with his voice. Defer your shallow judgements for half a second and try listening.
This is the most therapeutic and correct talk of the century.
Such a good and practical advise. Thanks for this lecture.
the "goals" are noble, however i'd like to point out that true leaders do not ignore people. they coach and mentor them to become (better) leaders too.
This is such a good talk. I need to remember these strategies
Out of the whole talk, only one point I disagree with: Part when he discusses organizational oversight "WebService compliance architect" 30:40. Some competences do not scale; some are regulatory - you can't expect a person responsible for a narrow field to be directly engaged in a legwork with a team; and you can't expect to hire such a person per team. In essence, this is an example of a situation where the team should definitely drop the dogmatic approach to independence.
I could immediately connect with the given example: Someone with a title walks in, "entitled" to get a report, where neither the team understands the purpose, not the requestors understands the work output of the team. That's why many processes, reports, quality indicators etc in "BigOrg" are so entirely detached from and counter-productive to SW development: Parties are not willing to sit down in order to understand each other's needs, but rather insist on remaining in their isolated silos. I still have wet dreams about a quality department to have an actual clue about SW development, the KPIs they are supposed to collect, and the impact their demands have on development performance.
A refreshingly realistic take on agile SW development in BigCorp that you find seldomly discussed, yet will encounter around every corner in RL organisations.
What other corps exist besides real life organisations? 😄
Gold at 14:10
In the Age of assisted ai code, having an entrepreneurial mindset is more important than technical skill
Good work Fred, hope the Norwegian knows to use you now when your in the country.
Great preso. Highlighted a lot of unpleasant truths.
Have I understood correctly what he was saying regarding change agents? Basically, if you are the one, who tries to make changes in the processes organization, you're pretty much fated to leave the company soon, because you will be resented? This is pretty dire outtake.
Fred's go-to approach is a classical consultant strategy: Go straight into it guns blazing, turn stuff inside out with top management approval, bypass all the middle management while at the same time make them look really bad, then establish a status quo the middle management can't easily roll back, and move out again, taking all the credit. Nobody within an organisation can do that without negative consequences to themselves. It's actually a great argument to hire a consultant in order to get radical changes done.
Amazing talk
Very realistic talk. I have been on the same mission and journey for 15 years helping different organizations. I used some of these strategies without noticing :). It is very nice to learn about other techniques.
I wish I had heard this 10 years ago.
Being a change agent has been brutal.
Agile design does not account for structurally changes. If you have a shared function between 2,3,4 you name it, different domains, which need to be centrallized and the customer needs some fundamental changes, you are standing with your back against the wall. At this point as a developer you only got 2 options: Produce shitty code or make a huge refactoring. As the system growes and more people are involved, this problem will lead to end endless cycle, leading to project, that either are fast and produce ugly code, no one understands after 5 years in production or leading to endless refactoring cycles. You need the right persons, with enough domain knowlegde and a basic structure, which then is agile enough to change and doesn't have too many dependencies in the end. This is really tricky, because you dont want calculation code (f.e. invoicing sales and orders) to be done twice, as this can lead to massive differences when code is changed only in one domain. Therefore you are forced to refactor anyway. The bigger the projects get, the more unefficient agile will get, when there is no clear predifined structure/architecture in the code. Alternativly you can ignore the fact and build the ultimative home with no foundation, which means the technical dept needs to be absorbed by the customer at any time sooner or later in the furure in reinventing the wheel again. Love your talk
Some good ideas, but the assumption that all leaders are men, and that combat is the only way forward kept me sufficiently distracted that I didn’t absorb much.
This comment makes some pretty naïve assumptions about both men and women. And it really only highlights that you are indeed not able to pay attention to anything without projecting whatever wild chaos is going on in your head from the last Reddit comment you read.
Just take a second to take a deep breath and allow the speaker to present with his voice. Defer your shallow judgements for half a second and try listening.
/mm