An alternative and guided approach to running efficient retrospectives that tackle come challenges including : sacred cow, authority bias, bike shedding, imposter syndrome, and the Dunning-Kruger effect.
The 7 Things I Know About Cyber Security After 25 Years | April 2024
Driving Process Improvements - A Guided Approach to Running Effective Retrospectives
1. A guided approach to running effective retrospectives
DRIVINGPROCESS
IMPROVEMENTS
VICTOR SZOLTYSEK
2. We know exactly what to do to
improve things (but don’t
necessity have
fi
nal say)
The client/team doesn’t want to
do them
Simply telling the client/team
doesn’t change their mind
If anything client/team only
“doubles down” on stubbornness
Trouble ensues
THENUMBERONEPROBLEM
INCONSULTING:
3. RETROSPECTIVES
At regular intervals, the team reflects on how to
become more effective, then tunes and adjust it’s
behaviour accordingly. — Agile Manifesto
(onesolution)
6. - Important items are held back
- Imposter Syndrome, Lack of Psychological Safety, Lack of Anonymity, Bike
Shedding, Authority Bias, Sacred Cows, etc
- Resistance to change and experimentation
- People really don’t like being told what do to (especially by new people, and
especially if it implies they’ve been doing things the wrong way)
- Lack of focus and measurable outcome
- E
ff
ect: Regular Retro’s are generally not that E
ff
ective
- Though still better then ZERO self re
fl
ection mechanism
CHALLENGES:
8. - New to Existing Project
- You don’t have
fi
nal say
- You don’t have full context
- Seeing Fundamental Issues
- Long Pull Request Times, Di
ffi
culty Refactoring as example
- Resistance to change
- Don’t want to go in “guns blazing” .. and criticize everything that’s been done already
- Action - Volunteer to run the next retro
EXAMPLESCENARIO
17. An idea, custom, or institution
held, especially unreasonably, to
be above criticism.
SACREDCOWS
Importance of everything
being open to discussion
and criticism.
18. Human brain's tendency to trust
and accept superiors regardless
of how empty their claims are.
Even though our gut tells us
something is wrong, we don't
question it anyway.
AUTHORITYBIAS
Importance of everything
being open to discussion
and criticism.
Be tactful :)
19. The amount of time spent
discussing an issue in an
o r g a n i z a t i o n i s i n v e r s e l y
c o r r e l a t e d t o i t s a c t u a l
importance in the scheme of
things.
Also known as “Law of Triviality”.
BIKESHEDDING
Importance of focusing on
consequential and often
di
ffi
cult items.
21. Psychological pattern in which an
individual doubts their skills,
talents, or accomplishments and
has a persistent internalized fear
of being exposed as a “fraud"
often despite evidence to the
contrary.
Often made worse by the
“Dunnig-Kruger”e
ff
ect.
IMPOSTERSYNDROME
Importance of speaking up,
even when unsure of self.
24. ISSUES/CHALLENGES/BLOCKERS/CONCERNS
- 10 minutes — until everyone has written and submitted at least 2 paragraphs
- Anonymous submission via Google Forms (all RAW feedback will be posted / shared)
- Actionable Observations / Concerns / Possible Solutions
- Random Discussion Items / Categories :
- E
ff
ectiveness of Stand-ups / Meetings / Rituals - Is there value from current meetings ? Are we spending too much
time in meetings ? Are meeting objectives clear ? What about cadence ?
- Story Process - Is JIRA process clear ? i.e. what needs to be worked , what to work on next ? Do current stories need
more analysis ? Do I know who to talk to when business requirements are uncertain ? Are JIRA stories up-to-date ?
Do we have too much process or too little ?
- Work in Progress / Context Switching - Are we wasting unnecessary development time due to context switching ? Do
members (including boss / PM) know when I’m getting pulled to do work for other teams ?
- Transparency and Priorities - Are team goals and status clear ? Is it clear who to get work from ? What priorities are ..
- Team Charter - Are our processes clear ?
- Friction / Waste - Are we spending an unnecessary amount of time on “friction” and other “non-value” add activities
instead of actual “business value” functionality (i.e. our special sauce) ? Which activities ? What are some
suggestions to improve things ?
25. NEXTSTEPS
- Discussion of main items (focus on one or 2)
- What’s one small thing that we can change to move things in the right direction ?
- Identify process improvements to try and experiment over next Sprint
- Any potential “table-napkin” metrics to track ?
- Review at the beginning of next Retrospective
- Get Team Buy-In (ideally teams suggestions and not yours)
27. TIPS:
- Start with small improvements
- While “claiming” neutrality, you can always add your own anonymous feedback
- Considered focused / themed Retro’s
- i.e. tackling speci
fi
c issues — build problems, quality, etc
- Post Retrospectives on Con
fl
uence / Sharepoint (internally but publicly)
- Raw Feedback, and Action Items
- Important to Track Historical Changes (for bigger strategic changes)
