The document discusses myths, legends, and monsters that may arise when scaling agile practices in an organization. Myths are used to justify the status quo and involve heroic figures, while legends spread rumors and lessons learned. Monsters represent resistance and require confronting objections. The document provides examples of each and suggests approaches like communication, negotiation, and aligning on values to address concerns raised by myths, legends, and monsters.

1. Myths,
Legends &
Monsters
The Quest for the
Grail of Enterprise Agility
François Bachmann, SPRiNT iT

2. Who’s talking
François Bachmann
• « The Urban Traffic Parable »
• « The Art of the Retrospective »
(Agile-Alchemist.com)
• Organisational Development Coach since 2004
• Interests:
Systemic Thinking, Complex Adaptive Systems
(like a Jam Session @AgileEE )

3. What You Should Get

4. Your initial situation
• Pilot project « success »
• Request/need to scale this success
• Existing company
]Out of Scope[
• Introduction to Agile, Lean, Scrum, XP, …
• Growing an agile company

5. Warnings(1)
Scaling is always complex

6. Warnings (2)
Agile is a mindset, an attitude
 plan lots of time for full-fledged adoption

7. Starter: A customer myth
« Normal Change » at a Swiss bank
Source: http://itsm.certification.info/normalchg.html

8. Myth
A traditional or legendary story
that can contain a moral lesson
Built on Archetypes
Gods, animals, angels, demons, other worlds
Used to justify a social institution
and its way of viewing the world
Source: dictionary.reference.com
Told at ceremonies
(start, transformation, end)
Principal purpose: federate

9. Myths: project choice / dimension
« Let’s do Agile within a fixed-price contract »
« We apply Agile but only to Development »
« We do ALL our projects with Agile»

10. Myths: Roles
ScrumMaster: Thor / Superman /
James Bond / Chuck Norris
« Three Roles is enough for any
company »
 Scrumdamentalism (H.Kniberg)
« In our company, we’re all like a big family»

11. Myths: transition
« Just use Scrum of Scrums
and everything will be fine»
« Trust me, in this company we know
what change management is! »
« To really become Agile,
you have to destroy & rebuild from scratch»

12. Summary: Myths
• Main purpose:
federate
• Used for
justification
of status quo
• Usually involve
superhumans 
• Reveal values of the company

13. Legend
(lat. legenda = to be read)
• Official shape of the rumour
spread during coffee breaks
• « I know someone who… »
• Urban Legend
• Can end both ways
• Finishes with a lesson to learn
Principal purpose: education

14. Legend: Company Culture
« My cousin tried to introduce Agile in his
company: it didn’t work at all!
Now I agree that they have a very special
company culture….»
« Actually, our company culture
has always been agile; let’s just change the
terminology and we’ll be fine»

15. Customer Legends: Company Culture
• Mediterranean: mix of nationalities
• Web company: resource allocation > flow

16. Legends: Organisation
« It seems that this won’t work
in an outsourcing context… »
« Another team in our division used it during
a few months, their productivity dropped…
and they switched back afterwards»
« What about my career plan? »

17. Legends: Transition
« A well-planned transition is the cornerstone
of success: plan the work, work the plan»
« Let’s just establish a matrix between the
old and the new roles»

18. Legend: Tool
« Company X bought tool Y when
they moved to Agile and the whole
enterprise is now using it.
But how can I convince my
management? »

19. Summary: Legends
Purpose:
Institutionalized Learning
« What hasn’t worked in
the past and what were
the consequences »
Advice: are a very efficient
communication tool:
« Worst Practices » or
NotHow-Transfer©

20. Monster
(lat. monstrum:
wild beast)
• Impersonates
resistance
• Gatekeeper
• Requires the
hero to go
beyond the
normal plan

21. Monsters: Middle Management
« I’ll be the Scrum Master for all teams »
« I can replace the Product Owner, if needed »
« Well, someone has to assign the developers to
projects, no?! »
Strengths: network, relationships
Weaknesses: conflicting priorities,
overestimates his potential influence
Fights for: his position and his « power »
 Approach: give him a catalyst role,
actively include in information exchange

22. Monster: Project/Process Office
Distinguishing marks: once they understand Agile is not
going away, they will try to govern it and create rules
Strength: power to standardize
Weakness: mechanistic world view
Fights for: being the process master
and force their rules on developers
 Approach:
1) produce their artefacts and
2) when the right time comes: question the value of
these artefacts (not of the Project Office!)

23. Monster: Saboteur
Definition:
Person who is involved
but has a hidden agenda
(subversion, obstruction,
disruption, or destruction)
Strength: internal knowledge
Weakness: bottleneck
Fights for: « unofficial » priorities
 Approach: make responsibilities explicit,
confront one-on-one if necessary

24. Monster: AgileGuru
Pretends to sell the One And Only Agile
Distinguishing marks:
elitist, likes to fight
(he/she usually wins)
Strength: *very* convinced by his Agile flavor
Weakness: exclusive, tends to work alone
Fights for: his Truth (destroying others)
Approach: recall Agile values, let him show
how his flavor brings them forward

25. Summary: Monsters
• Strongholds, Gatekeepers
• Have power & reputation
• Often easier to « turn around »
than to overpower
• Advice: don’t play on their territory!

26. Summary
Properties How it’s helpful Suggested approach
Myth Historical, federates and passive-implicit communication,
heroes, illustrates common strategy and long term follow-up
« Best values (world view)
Practices »
Legend « Worst Lessons learnt, active-explicit communication,
Practice » NotHow-Transfer© use & recall in major
retrospectives
Monster Personalized Strong, potential negotiate, convince, align on
objection , ally, when aligned values
Gatekeeper with your cause

27. Enjoy the Quest, brave knights!

28. Thanks!
© Pixar Technologies, Inc.
f.bachmann@sprint-it.ch
FrBachmann