Session on the psychology behind change in software transformation efforts. First held at Limerick .NET Azure User Group.

1. WHAT DID I LEARN TRYING TO MIGRATE
TEAMS FROM LEGACY TO MODERN?
Matteo Emili
matteo.emili@live.com | @MattVSTS |
mattvsts.blogspot.com

2. WHAT ARE WE GOING TO
TALK ABOUT TONIGHT?
PEOPLE
BEHAVIOURS
PSYCHOLOGY

3. WHO AM I?
• Systems Engineering Advisor @ One Identity
• Microsoft MVP – Developer Technologies
• Professional Scrum Master 1
• Microsoft Certified Technology Specialist: Team Foundation Server
• Technology enthusiast

4. IT USUALLY DOES NOT MATTER…

5. …BUT THIS TIME IT REALLY DOES.

6. SO, WHO AM I?
• A person with many interests
• Fast learner, always looking for
something new to try or discover
• I run a sizeable homelab and home network
• Soaked in the technology community
since…pretty much ever
• Started blogging at 17, speaking at
technical events at 19
• Microsoft MVP at 20
• Always been into architecture, quality,
ALM more than code for its own sake
• Spoke about DevOps on the Microsoft
Stack (WinOps?) for the first time in 2012

7. PROFESSIONALLY?
• Self-taught software developer and
tinkerer
• Started working as a Software Developer
while in High School (three afternoons a
week)
• Code was ‘fine’, but writing it right was
more interesting for me: quality, testing,
architectures, …
• I’ve been the go-to ALM person for
years, everywhere – TFS was my
cornerstone
• I worked on several transformation
projects, of all sorts, in many industries

8. WHY THIS SESSION?

9. WHO DOESN’T LIKE
PATTERNS?
• The idea came speaking with Giulio Vian
and other members of the
GetLatestVersion.it community
• We regularly ask ourselves questions like
‘How would you tackle this? How can I
come out on top of that?’ with general
problems ranging from technology to
business matters
• While we all gave out many different
answers, I realised there are patterns that
keep repeating all the time, especially in
transformation projects
• So I started digging in the world of
psychology, and I opened a Pandora’s
box

10. DEFINE TRANSFORMATION!
A “legacy to modern” transformation can
be:
• Virtualisation effort
• Waterfall to Scrum/Lean/Whatnot
• Zip files to Version Control Systems
• Excel to Jira
• Manual weekend deployments to
Continuous Delivery
• ALM/DevOps stack consolidation
• Practice establishment
• Monolith to microservices
• …

11. TRANSFORMATION IS DISRUPTION

12. TECHNOLOGY DOES NOT MATTER

13. TECHNOLOGY IS JUST A TOOL

14. THEY ALL TRY TO DO THE SAME

15. CHANGE

16. COMPANIES ARE MADE OF PEOPLE

17. PSYCHOLOGY LEADS TO SUCCESS

18. WHY? SAY HELLO TO THE
HUMAN BEING
A pretty bleak picture to be fair…
• Fear of change
• Innate risk avoidance
• Tribal knowledge
• First-hand experiences vs collective
knowledge
• Relies on bias and beliefs
• Suffers from peer or performance
pressure
• …

19. IT’S NOT ALL LOST

20. WE ARE HUMAN BEINGS TOO

21. THERE ARE SOME SOLUTIONS

22. EXAMPLES?

23. ALM STACK
CONSOLIDATION
Company ABC decides to consolidate all
the ALM stacks across the company to a
single-vendor solution, unifying years
(decades?) of intellectual property under
the same roof
It is a huge company-wide effort that is
going to massively improve how software
is developed internally
Scenario #1

24. A PRACTICAL EXAMPLE
• Atlassian Suite+Trello+Excel+Custom &
SVC+CVS+Git+SourceSafe
• Everything moved and consolidated on
TFS
• It is a *huge* change
• There is a level of investment required

25. WHAT’S GOING TO
HAPPEN?
• People are going to complain
• Some departments are going to raise a
level of resistance
• A few people are going to protest
because ‘my things have been moved! I
cannot find anything here/in this mess!’
• Someone could potentially make your
life really hard
• I also saw some examples of sabotage
over the years…

26. WHAT IS LIKELY TO
HAPPEN?
• Resistance can be really weak, or passive
• It is usually driven by ‘tribe leaders’
• People are going to follow, mostly
because of innate instinct (“If it works…”)
• Also important: change implies reset,
starting again from scratch
• We are not used to it

27. WHAT COULD HAPPEN?
• Internal competition to shine the most
• Volunteering for support or help
• Rush to get it quickly out of the door
and carry on as normal

28. WHAT DID I LEARN?

29. WHAT DID I LEARN
• Leverage tangible results
• Timing is essential, but don’t rush things
• The incremental perception is key
• Show knowledge bridges wherever you
can
• Delays are normal and they happen –
nobody is going to get mad about it

30. INCREMENTAL IS KEY

31. INCREMENTAL IS GOOD!

32. WHY IS IT SO IMPORTANT?
• Incremental, iterative approaches are the
ones that play on the individual’s
motivation
• Short timeboxes and a continuous flow
of deliverables make the team feel in
control
• Positive vicious circle: the team feels in
control and make decisions based on
their own pace and esperience
• This is where you can actually use tribal
knowledge to your own advantage – a
self-managing team is clearly going to
be more productive than a top-down-led
team
• Also, it is the only way of defeating
Parkinson’s law

33. PARKINSON’S LAW?

34. WORK IS LIKE IDEAL GAS…

35. …OR BUREAUCRACY

36. WORK EXPANDS SO AS TO FILL THE
TIME AVAILABLE FOR ITS COMPLETION

37. NO MATTER WHAT, YOUR TEAM IS
GOING TO BE ‘BUSY’

38. OVER TIME, THE ACTUAL VALUE
PRODUCED BY AN ‘ALWAYS BUSY’
TEAM GOES DOWN

39. REALLY?
• If your team is always overbooked, the
actual quality of the deliverables is going
to be low
• Bugs will be continuously added and
technical debt is going to go through the
roof
• If your team has spare capacity (but still
adhering to Parkinson’s law) it is going
to focus on trivial things
• Deliverables will be very light and there
is going to be an emphasis on the small
changes brough forward
In both cases, value is low

40. WATERFALL TO AGILE
Company Y123 decides to jump on-board
the Agile bandwagon, ditch its inefficient
Waterfall-based process and move to Agile
It is a top-down effort where management
wants to catch-up on the trending market
topics to prevent the company from
remaining behind its competitors
Scenario #2

41. A COUPLE OF RED FLAGS HERE…

42. …THE AGILE BANDWAGON…
…MOVE TO AGILE…

43. …A TOP-DOWN EFFORT…
…MGMT WANTS TO CATCH UP…

44. PANIC-INDUCED REACTIONS &
HEAVY-HANDED APPROACHES

45. HOW TO MAKE IT WORK?
• A quick (often informal) training is more
than enough to get started with Scrum
• Scrum is excellent for this as overhauls
everything while retaining a strict
timeline
• No need for comparative evaluations at
this stage, as it is mandated by the top
anyway
• Take a portion of a product and start
creating a backlog
• The collaborative effort makes the move
from planning to delivery straightforward
• Scrum is just the starting point. Lean?
Scrum? Scrumbut? It is all up to the
individual team after that

46. WHERE IS THE MAGIC?
• Team morale here plays a key role
• Software development is a team effort
• People should feel motivated and
excited, not depressed because of
another management mood swing
• Agile methodologies put everybody on
the same level, so diverse individual
contributions are really invaluable
• The burden of deciding how to move
forward is taken away – it is actually a
positive point
• Improvement can be carried forward
based on tangible experience

47. IT IS OFTEN DOWN TO THE BASICS

48. THE PERFECT STORM
• Imagine a situation where a company
wants to invest in telemetry (both
reactive and proactive)
• There is an X amount of people in the
‘Telemetry team’
• The management team believes it is
going to be really effective: a
combination of data-driven decisions
and artificial intelligence so that R&D
time can be wisely invested
• What is *actually* going to happen?
Scenario #3
(fictional)

49. THE DUNNING-KRUGER EFFECT

50. THE LESS, MORE
• Cognitive bias in which people of low
ability have illusory superiority and
mistakenly assess their cognitive ability
as greater than it is
• Also, people of high ability incorrectly
assume that tasks that are easy for them
are easy for other people
Source: Wikipedia

51. THE LESS, MORE
• Common examples are found in people
just out of school/university, but pretty
much everybody can be affected
• It is surprisingly common in another
category of engineers: people that have
worked for a long time with legacy
technology and they are suddenly
exposed to something completely new
• The solution is fairly easy: a paired
induction at on-boarding time or internal
mentoring as required
• It is usually a good sign, of a person that
is motivated to improve after losing the
illusory superiority

52. IMPOSTOR’S SYNDROME

53. THE MORE, LESS
• Psychological pattern in which an
individual doubts their accomplishments
and has a persistent internalized fear of
being exposed as a "fraud“
• Proof of success is dismissed as luck,
timing, or as a result of deceiving othersSource: Wikipedia

54. THE MORE, LESS
• Extremely common in high-performance
software engineers
• The reason behind this is that personal
standards are usually way higher than
company standards
• Peer-reviewing is extremely
commonplace in the industry, fuelling
the syndrome
• Media coverage contribute to it, and not
in a good way…
• It is quite dangerous, as fighting it can
lead to burnout

55. THE MORE, LESS
• Tackling this as a change factor is not
easy
• Nobody is going to tell you “I feel I
should not be here”
• The best way to indirectly approach the
problem is to leverage on internal
feedback funnels (standups?)
• People will feel motivated and compelled
to contribute, leading to better
awareness
• Unfortunately it is not a straightforward
process

56. ALPHA-TYPE SUPREMACY

57. I AM ONLY HUMAN, AFTER
ALL…
• People will naturally be polarised with or
against the alpha-type elements in the
team
• Telemetry analysis is something that
should be as automated as possible
(hence the rise of proactive telemetry)
• As the process is data-driven, the mix of
one of the above ‘syndromes’ with an
alpha-type personality means that the
outcome of the work done by the
‘Telemetry team’ is going to be skewed
• There is no real way out here, not even
leveraging processes – it is bound to
happen

58. COMPETITION

59. I AM ONLY HUMAN, AFTER
ALL…AGAIN!
• Two human beings sharing a repetitive
task will most likely become competitive
• As the level of competition rises
(especially if incentives are on the line)
the number of false positive will rise
• Also the other way around – if there are
negatives involved, the overall level of
reported items will be lower than
expected
• Never, ever, introduce competition
within a team!

60. A COUPLE MORE TO REMEMBER

61. PUTT’S LAW

62. A BINARY SITUATION
• Technology is dominated by two types of
people, those who understand what they
do not manage and those who manage
what they do not understand.
• Every technical hierarchy, in time,
develops a competence inversion.Source: Wikipedia

63. A BINARY SITUATION
• Many technical people don’t want to be
promoted to ‘management’ roles
• On the other hand, there are people who
are average on a technical role but they
sport a good business acumen or people
management skills
• It is the duty of a good company to
identify these people and let them
express the best they can
• The company can eventually only gain
from such an approach, leveraging on
people’s best skills and having a
motivated team
Source: Wikipedia

64. THE PETER PRINCIPLE

65. INCOMPETENCE?!
• A person who is competent at their job
will earn promotion to a more senior
position which requires different skills.
• If the promoted person lacks the skills
required for their new role, then they will
be incompetent at their new level, and so
they will not be promoted again.
• But if they are competent at their new
role, then they will be promoted again,
and they will continue to be promoted
until they eventually reach a level at
which they are incompetent.
• Being incompetent, they do not qualify
to be promoted again, and so remain
stuck at that final level for the rest of
their career
Source: Wikipedia

66. COMMON OCCURRENCE?
• It looks like it goes hand in hand with
office politics
• Common in heavily structured
companies
• There isn’t much one can do about it –
yet…
Source: Wikipedia

67. QUESTIONS?

68. THANKS!