Sabotaging an Agile Transformation • Fred George • GOTO 2022

Подписаться 993 тыс.

Просмотров 119 тыс.

50% 1

This presentation was recorded at GOTO Amsterdam 2022. #GOTOcon #GOTOams
gotoams.nl
Fred George - Early Adopter of OO & Agile, Advocating Microservices & Programmer Anarchy
ABSTRACT
Transformation efforts must overcome a myriad of challenges to achieve success. Some of the inhibitors we will discuss include:
● Executives unaware of the transformation
● Failure to engage all the necessary parties
● Individuals losing power with the transformation
● New roles and disappearing roles
● Lack of an effective Change Agent
● Success conservatism
● Lazy buyers
● Blame-oriented cultures
For each of these inhibitors, we will cite:
a) situations where this occurred
b) mitigation actions to overcome the inhibitor, and
c) the effectiveness of these efforts.
We will conclude by suggesting some best practices we are currently employing in anticipation of likely inhibitors, including our newest proposal process of only selling complete solutions to our clients (not just body-shopping people) [...]
TIMECODES
00:00 Intro
01:40 Sabotage?
04:53 Case: NAV Deployments
06:00 Active saboteurs
10:10 Active saboteurs mitigation
20:15 Organizational sabotage
32:52 Other types of sabotage
33:23 Pod as a mitigation strategy
38:57 Other mitigation techniques
41:10 Outro
Download slides and read the full abstract here:
gotoams.nl/2022/sessions/2148
RECOMMENDED BOOKS
Aino Vonge Corry • Retrospectives Antipatterns • amzn.to/3naFk84
Lee, Wickens, Liu & Boyle • Designing for People • amzn.to/313ovpi
Stone, Chaparro, Keebler, Chaparro & McConnell • Introduction to Human Factors • amzn.to/3mfXqY2
/ gotocon
/ goto-
/ gotoconferences
#AgileTransformation #Transformation #DigitalTransformation #Agile #Agility #AgileDevelopment #Teams #Scrum #Scrummaster #AgileSchizophrenia #ProgrammerAnarchy
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ru-vid.com...

Наука

Опубликовано:

14 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 19

@Thorax232 Год назад

This is the most therapeutic and correct talk of the century.

@retrodad9390 Год назад

I have respect for this guy, after all these years, still trying to change the mindset within a company on multiple levels, even when he got paid for this you need a lot of passion for the job. Thanks for the video

@TheHabibass Год назад

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.

@stephanklein257 Год назад

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.

@Venthe Год назад

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.

@stephanklein257 Год назад

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.

@drhilm Год назад

Such a good and practical advise. Thanks for this lecture.

@cecilienielsen3030 Год назад

Good work Fred, hope the Norwegian knows to use you now when your in the country.

@neoplumes Год назад

This is such a good talk. I need to remember these strategies

@jazzlighthart Год назад

Amazing talk

@ChrisAthanas Год назад

Gold at 14:10 In the Age of assisted ai code, having an entrepreneurial mindset is more important than technical skill

@STFU665 Год назад

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

@arafathegazy101 Год назад

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.

@stephanklein257 Год назад

A refreshingly realistic take on agile SW development in BigCorp that you find seldomly discussed, yet will encounter around every corner in RL organisations.

@blaiseutube Год назад

I wish I had heard this 10 years ago. Being a change agent has been brutal.

@NigelFurtado Год назад

Great preso. Highlighted a lot of unpleasant truths.

@juliorojaschanto6360 Год назад

/mm

@vosechu Год назад

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.

@Thorax232 Год назад

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.