The document summarizes a workshop about how the OneABB team transitioned to agile practices. It describes how the team initially had issues like disorganization, poor transparency, and "hero culture" behaviors. To create buy-in for change, the workshop leaders had team members brainstorm problems, prioritize them, and assign owners to resolve top issues. This helped team members recognize needs for improvement and gain motivation to change by giving them ownership over solutions.

1. Workshop
The
OneABB
Team
Goes
Agile
The
Tricks
Used
for
Crea8ng
Awareness
and
Desire
for
Change
and
Actually
Doing
the
Change
Ma?hew
Caine

2. AGILE
Some
people
call
it
a
method
or
an
approach
above
all
It
is
about
PEOPLE
and
RESULTS

3. Assump8ons
• You
are
looking
for
real
challenges
of
“Agile”
• Expect
some
quick-­‐win
“take-­‐aways”
• You
are
not
here
to
fine-­‐tune
your
Standups

4. Who
am
I?
•
•
•
•
•
•
English
Come
from
near
Liverpool
/
Manchester
I.T.
background
Lived
in
Zurich
since
1994
Worked
in
London,
NY,
Berlin,
Geneva
and
ZH
Discovered
“Agile”
in
2009
August
2011
Setup
M.C.
Partners
&
Associates
September
2012
Launched
the
Agile
Academy

5. Community

6. OneABB’s Purpose:
“An Awesome Website”
www.abb.com

7. www.abb.com
2000
content
editors
80
country
sites
over
1
million
urls
10
million
views
/
month

8. ABB’s website is a key customer connection
Facebook and LinkedIn are the top sources of traffic
after direct visits, search, and visits from the intranet

9. The
Real
Story
•
•
•
•
•
•
•
•
No
transparency
on
status,
people
or
ac8vi8es
50
people
in
four
countries
40
people
in
Krakow
organized
by
skill
Culture
of
maintenance
“Hero
culture”
with
Prima
Donnas
Agile,
but
not
really
Constant
“firefigh8ng”
Stuff
was
late,
not
as
expected,
poor
quality

10. This
Workshop
is
about
the
changes
above
and
beyond
Agile
skills.
It
is
about
some
of
the
things
we
had
to
do
con8nue
to
do
and
s8ll
need
to
do
to
give
Agile
a
chance!

11. How
the
Workshop
will
Work
• 9
topics…
The
first
5-­‐6:
– Examine
the
Scenario
/
Theory
– You
get
5
minutes
at
your
table
to
discuss
– I
then
chose
2
groups
for
feedback
– We
then
look
at
what
was
actually
done
• At
the
end
we’ll
scan
the
remaining
topics.

12. Managing
Prima
Donnas
/
Gold
Pla8ng
=
Quality
Remote
Teamwork
Performance
Reviews
The
Gan?
Lie
Chart
vs
“Agile
Planning”
Crea8ng
Awareness
&
Desire
Remote
Team
Percep8on
Be?er
Transparency
on
Work
Looking
for
&
Building
Trust

13. Crea8ng
Awareness
&
Desire

14. Crea8ng
Awareness
&
Desire
The
Scenario
It
is
May
2012.
You
are
in
a
room
with
the
key
people
from
Krakow
and
Zurich.
They
know
things
have
to
improve.
But
don’t
know
where
to
start.
Your
Task
Discuss
how
you
would
get
them
to:
1. Share
&
agree
on
their
pains
2. Want
to
address
the
pains
3. Agree
on
the
most
important
changes?

15. Crea8ng
Awareness
&
Desire
Step
1:
Brainstorm
to
Visualise
“Tensions”

16. Crea8ng
Awareness
&
Desire
Step
2:
Run
a
Normal
Retrospec8ves
Session
Categories
What
went
well?
What
do
we
need
to
start?
What
do
we
need
to
stop?
What
do
we
need
to
improve?
Out-­‐of-­‐the-­‐box
innova8ve
ideas

17. Crea8ng
Awareness
&
Desire
Step
3:
Which
Tensions
could
be
Resolved
and
Examine
Lem-­‐overs
3b)
Re-­‐examine
any
lem-­‐overs
3a)
Place
“tensions”
on
top

18. Crea8ng
Awareness
&
Desire
Step
4:
Group
&
Name
B
C
A
D
F
E

19. Crea8ng
Awareness
&
Desire
Step
5:
Priori8se
B
Priority
C
A
B
E
C
F
D
F
1.
2.
3.
4.
E
Each
Team-­‐member
has
3
votes.
Take
5
minutes
to
vote.
Facilitator
checks
and
summarizes
the
vo8ng.
Debate
results.
D
A

20. Crea8ng
Awareness
&
Desire
Step
6:
Assign
Owner
B
Priority
Owner
C
B
John
E
Mary
C
Mark
F
A
Paul
D
D
F
A
Don’t
do
low
prio
stuff!
E
As
a
peer-­‐group
they
have
iden8fied
their
tensions,
priori8zed
and
assigned
owners.
By
default
they
are
aware
and
have
the
focus
and
desire
to
change.

21. Crea8ng
Awareness
&
Desire
Project
Methodology
Stop
Classic
BA
process
Start
Have
a
board
with
projects
and
priori8es
visible
to
everyone.
Stop
Having
every
task
a
top
priority
Start
Regular
structured
standups
Stop
Making
promises
without
consul8ng
execu8ng
party
Start
Get
the
UX
–
BA
–
DEV
process
working
Everything
is
a
priority
to
everyone
in
GWM
Maintenance
burden
of
“old”
vs
developing
new
Improve
Set
up
common
rules
for
running
a
project
Improve
Intera8ve:
Get
feedback
more
omen,
earlier
Improve
Priori8za8on
and
deadline
serng
Improve
Be
persistant
with
things
we
have
started.
Do
not
abandon
things.
Well
Projects
where
we
have
a
clear
deliverables
schedule
Improve
Planning
and
Priori8za8on
Improve
Working
on
deadlines
together
Well
Projects
with
weekly
mee8ngs
to
followup
on
overall
status
Improve
PM
ISDC
GWH
Well
Doing
the
scope
planning
together
Well
Structuring
the
Work
(Basecamp)

22. Managing
Prima
Donnas

23. Managing
Prima
Donnas
The
Scenario
Krakow
has
a
number
of
Individuals
that
are
“prima-­‐donnas”…
Your
Task
Discuss
and
list
your
thoughts
on
:
• The
risks
of
prima-­‐donnas
to
the
teams,
department
&
company.
• How
you
could
get
the
knowledge
of
the
individual
prima-­‐donnas
shared.

24. Managing
Prima
Donnas
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Bo?leneck
for
the
teams
Difficult
to
plan
Create
dependencies
in
a
sprint
Burn
out
Cause
resentment
“Under
a
bus”
syndrome
Like
to
keep
know-­‐how
Poor
team
members

25. Managing
Prima
Donnas
Typical
Solu8on
Alterna8vely
Two
or
more
teams
share:
50%
But
s8ll:
• Bo?leneck
• Difficult
to
plan
• Create
dependencies
in
a
sprint
• Burn
out
• Cause
resentment
• “Under
a
bus”
syndrome
• Insecure
–
like
to
keep
know-­‐how
• Poor
team
members
• Make
them
free-­‐agents
• No
longer
responsible
for
deliverables
• Now
responsible
for
coaching
&
suppor8ng
team
members
who
deliver
Thus
• Know-­‐how
transfer
happens
• Can
support
many
people
• Ego
is
not
damaged
;-­‐)

26. Be?er
Transparency
on
Work

27. Be?er
Transparency
on
Work
The
Scenario
• Zurich
has
no
idea
who
is
working
on
what
or
why
people
are
working
on
things.
• Krakow
does
not
understand
the
priori8es,
as
they
constantly
change.
• Krakow
do
not
know
what
to
work
on
or
why
it
is
suddenly
“important”.
Your
Task
List
your
thoughts
on
how
to
gain
transparency
on:
1. Why
work
is
important
(Purpose)?
2. What
is
coming
(Future
stuff)?
3. Who
is
working
now
on
what?
It
is
important
that
both
Krakow
and
Zurich
see
the
same
informa8on.

28. Be?er
Transparency
on
Work
Step
1:
Define
Phases
that
Projects
are
“in”
Based
on
DSDM:
Pre-­‐Project,
Feasibility,
Founda8ons,
Explora8on
&
Engineering
Idea
OpAons
High
Level
Plan
Features
A
long
10m
Wall
will
help!
Maintenance

29. Be?er
Transparency
on
Work
Step
2:
Map
Projects
to
the
Phases
and
the
Projects
to
Teams
Teams
can
start
to
PULL
work…

30. Be?er
Transparency
on
Work
Step
3:
Assign
People
to
Teams
&
Iterate
(Ac8on
Gaps!)

31. Be?er
Transparency
on
Work
Step
4:
Make
it
All
Accessible
to
All
(Zurich
&
Krakow)
All
the
Time
e.g.
Google
Drive
Docs

32. /
Gold
Pla8ng
=
Quality

33. /
Gold
Pla8ng
=
Quality
The
Scenario
Krakow
development
speed
is
slowed
due
to:
• Developers
gold-­‐pla8ng
• Poor
quality
Yet
developers
want
to
work
on
the
next
latest
sexiest
work.
Your
Task
What
do
developers
need
to
understand
to:
• reduce
gold-­‐pla8ng
• deliver
quality
• get
developer
working
on
the
next
sexy
project?

34. /
Gold
Pla8ng
=
Quality
ü Build
the
absolute
minimum.
ü Don’t
be
tempted
to
do
what
is
interes8ng.
ü Build
it
well.
ü Make
it
from
simple
stuff.
Ø Frees
developers
from
future
maintenance.
Ø Gives
8me
to
start
the
next
sexiest
job.

35. Remote
Team
Percep8on

36. Remote
Team
Percep8on
The
Scenario
• There
is
miscommunica8on
in
the
team
split
across
Zurich
&
Krakow.
• People
are
by-­‐passed
and
feel
unappreciated
• Others
have
to
much
to
do.
Business
Sponsor
Your
Task
Two
groups
will:
1. Read
their
team
descrip8ons
2. Put
names
to
the
Roles
(based
on
DSDM)
–
Flipchart
Provided
3. Reveal
the
results
“Spot
the
Difference”.
Business
Visionary
Project
Manager
Technical
Coordinator
“Expert
user”
Team
Leader
Business
Advisors
“End
user”
Solu8on
Developers
Business
Ambassadors
Business
Analysts
Solu8on
Testers

37. Remote
Team
Percep8on
SPOT
THE
DIFFERENCE

38. Remote
Team
Percep8on
Zurich’s
Percep8on
Mike
Mike
Business
Sponsor
????
Krakow’s
Percep8on
Business
Sponsor
Piotr
Nolan
Business
Visionary
Project
Manager
????
Technical
Coordinator
Nolan
Business
Visionary
Casper
Project
Manager
Technical
Coordinator
????
????
Team
Leader
Team
Leader
Business
Advisors
Casper
Casper
Solu8on
Developers
Lukas
Casper
Pawel
Business
Advisors
Business
Ambassadors
Claire
Solu8on
Developers
????
Lukas
Piotr
Pawel
Business
Ambassadors
Anna
Business
Analysts
Eloise
Solu8on
Testers
Business
Analysts
Eloise
SPOT
THE
DIFFERENCE
Solu8on
Testers

39. The
Gan?
Lie
Chart
vs
“Agile
Planning”

40. The
Gan?
Lie
Chart
vs
“Agile
Planning”
The
Scenario
• Scrum
&
sprints
are
perfect
for
systems
that
are
already
live.
• Zurich
however,
occasionally
want
to
launch
new
products.
• Some8mes
for
things
that
we
don’t
even
know
if
they
are
possible.
DSDM
is
great
for
star8ng
a
new
product…
• Take
an
idea
• Test
op8ons
and
feasibility
• Set
up
a
high-­‐level
plan
and
context
(JEDUF)
• Finally
to
launch
into
regular
sprints
/
Timeboxes.
Your
Task
What
could
the
context
be?
What
makes
sense
to
agree
before
development
starts,
especially
in
large
corporate
IT
environments?

41. •
•
•
•
•
•
•
“Agile
Planning”
Business
case,
vision,
assump8ons
Op8ons
considered
Recommended
op8on
Highlevel
plan
(ext
deadlines)
Indictor
of
poten8al
cost
Plan
+
cost
to
deliver
“High
level
planning”
Key
resources
AT
THIS
POINT
STILL
NO
DETAILED
SPEC
or
DESIGN
(JEDUF)
Idea!
•
•
•
•
High
Level
Planning
Op8ons
1-­‐Pager
Business
driver
V.
Highlevel
Objec8ves
Request
to
invest
$x
in
“Op8ons”
Increment
E
J,
A
Increment
H
G
Maintenance
strategy
Tes8ng
strategy
Non-­‐func8onal
needs
Audit
requirements
Regulatory
needs
Hardware,
somware,
middleware
•
•
•
•
•
•
Priori8sed
Highlevel
Requirements
Timebox
Plans
with
MoSCoW’d
requirements
Financial
cost
for
en8re
plan.
Repor8ng
Resources
Delivery
plan
(training
etc)
I
B
Deploy
•
•
•
•
•
•
• ROI,
Business
Case
• Risks,
assump8ons
C
Increment
D
Deploy
Assess
Benefits
F
Deploy
Decision
Point
(Go
on,
Stop)
PrioriAsed
Requirements
A
m
B
s
C
s
D
c
E
m
F
c
G
m
H
m
I
s
J
m
Timebox
Deploy
Into
produc8on
(Not
necessarily
switch-­‐on)

42. Looking
for
&
Building
Trust

43. Looking
for
&
Building
Trust
The
Theory:
The
Five
Dysfunc8ons
of
a
Team
(P.
Lencioni,
2002)
Ina?en8on
to
Results
Avoidance
of
Accountability
Lack
of
Commitment
Fear
of
Conflict
Absence
of
Trust
Status
&
Ego:
Individuals
put
own
or
department’s
needs
before
that
of
the
collec8ve
team’s
goal.
Low
Standards:
Don’t
challenge
peers
when
their
ac8ons
appear
counterproduc8ve.
Ambiguity:
Rarely,
if
ever,
buy-­‐in
and
commit
but
“pretend”
to
agree.
ArAficial
Harmony:
Incapable
of
unfiltered
and
passionate
debate.
Invulnerable:
Don’t
admit
mistakes
and
weaknesses.

44. Looking
for
&
Building
Trust
The
Scenario
• People
in
Zurich
have
started
to
distrust
those
in
Krakow.
• People
in
Krakow
have
started
to
distrust
those
in
Zurich.
• “Finger
poin8ng”
&
blame
has
started.
• There
is
an
absence
of
trust!
Your
Task
Agile
teams
have
perfect
moments
to
admit
mistakes
and
weaknesses.
Ø When
are
they?
Ø If
team-­‐members
do
trust
each
other,
what
do
you
hear
when
they
talk?

45. Looking
for
&
Building
Trust
ü Sprint
Planning
ü “I
need
help”
ü Standups
ü “I
made
a
mistake”
ü Review
ü “I
found
an
issue,
can
we
look
together”
ü Retrospec8ve
ü “Your
work
was
great”
ü Backlog
Grooming
ü “This
is
taking
longer
than
I
thought”
ü “Sorry,
my
assump8on
was
wrong”
ü “I
am
not
familiar
with
this
code,
who
can
help
me?”
ü “You
said
you’d
work
on
this…
why
have
you
not
done
so?”

46. Remote
Teamwork

47. Remote
Teamwork
The
Theory
Top-­‐Down
Control
from
ZH
Freedom
in
a
Framework
“Agile”
is
the
framework
Them
and
Us!
Bo?om
Up
Krakow
Autonomy

48. Remote
Teamwork
The
Scenario
Like
85%
of
teamwork,
this
team
is
remote
(Zurich
and
Krakow).
People
think
that
only
co-­‐located
teams
can
be
Agile.
Your
Task
Discuss
the
reality
that
85%
of
teams
are
not
co-­‐located.
Then
think
about:
Ø How
far
away
do
you
have
to
be,
to
be
“remote”?
Ø Why
is
being
Agile
actually
be?er
for
a
remote
team?

49. Remote
Teamwork
ü In
the
next
room
ü When
you
cannot
hear
a
conversa8on

50. Remote
Teamwork
Community
Decay
Trust
Mo8va8on
Face-­‐to-­‐face
event
Face-­‐to-­‐face
event
Time
50

51. Remote
Teamwork
Community
Decay
Trust
Mo8va8on
Face-­‐to-­‐face
event
Face-­‐to-­‐face
event
“Communica8on
Decay”
Time
51

52. Remote
Teamwork
How
Does
Agile
Help?
Trust
Mo8va8on
Face-­‐to-­‐face
event
Face-­‐to-­‐face
event
Time
Through
Frequent
Planning,
Standups,
Reviews,
Grooming
and
Retrospec8ves
52

53. Performance
Reviews

54. Performance
Reviews
The
Scenario
You
are
now
“Agile”
your
teams
are
working
well.
However,
people
s8ll
have
personal
goals
based
on
SMART
deliverables.
Your
Task
Discuss
the
reality
that
the
teams
cannot
“predict”
their
deliverables:
Ø What
could
be
reviewed
instead?
Ø Who
should
review
it?
Ø Do
we
s8ll
match
performance
to
bonus?

55. Performance
Reviews
ü Reward
good
“Agile”
behavior
ü Never
8e
performance
to
a
bonus
ü Manager
should
never
evaluate
Jurgen
Apello:
h?p://www.management30.com/workout/merit-­‐money/

56. Managing
Prima
Donnas
/
Gold
Pla8ng
=
Quality
Remote
Teamwork
Performance
Reviews
The
Gan?
Lie
Chart
vs
“Agile
Planning”
Crea8ng
Awareness
&
Desire
Remote
Team
Percep8on
Be?er
Transparency
on
Work
Looking
for
&
Building
Trust

57. /
Gold
Pla8ng
=
Quality
Managing
Prima
Donnas
Con8nuously
Review
Remote
Teamwork
Next
Week:
ATDD,
“Hardening”,
Planning
Performance
Reviews
Crea8ng
Awareness
&
Desire
Improve
Everything
The
Gan?
Lie
Chart
vs
“Agile
Planning”
We
are
S8ll
Improving…
Remote
Team
Percep8on
Be?er
Transparency
on
Work
Looking
for
&
Building
Trust

58. An
awesome
Website
needs
PEOPLE
to
deliver
RESULTS
Any
Ques8ons?

59. Stay
in
Contact
PlaNorm
Telephone
Link
+41
79
936
7060
Email
ma?hew.caine@mcpa.biz
Homepage
www.mcpa.biz
Library
www.mcpa.biz/blog
Xing
h?ps://www.xing.com/profile/Ma?hew_Caine
LinkedIn
h?p://ch.linkedin.com/in/ma?hewcaine
Twi?er
mc_mcpa
Skype
mc_mcpa
YouTube
h?p://www.youtube.com/MCPartnersAssociates

60. Support
Material

61. Remote
Team
Perspec8ves
• Team
1
–
Zurich’s
View
Mike
is
paying
for
the
work.
We
know
that
Nolan
is
responsible
for
the
whole
thing
with
lots
of
help
from
Claire
who
works
with
the
users.
Piotr
helped
to
define
the
architecture
together
with
Lukas,
Casper
and
Pawel
who
are
developers.
Claire
tests
and
Eloise
is
looking
amer
the
backlog.
Nolan
organises
the
retrospec8ves
and
Casper
is
running
the
daily
sprints
in
Krakow.

62. Remote
Team
Perspec8ves
• Team
2
–
Krakow’s
View
Mike
is
paying
for
the
work.
We
know
that
Nolan
is
responsible
for
the
whole
thing
and
gives
us
our
sprint
backlog.
Casper
is
our
team
leader
with
Lukas,
Piotr
and
Pawel
who
are
developers.
We
also
ask
Casper
for
help
with
the
technology.
Anna
tests
and
Eloise
is
our
BA.
Nolan
organises
the
retrospec8ves
and
Casper
is
running
the
daily
sprints
in
Krakow.