These are the presentation slides from a presentation I gave at the Lean Enterprise Software and Systems Conference 2010 (LESS 2010, http://less2010.leanssc.org/). The presentation is based around the paper I submitted that is published in the proceedings. From the paper abstract: Every organization has a design. As an organization grows, that design evolves. A decision to embrace agile and lean methods can expose weaknesses in the design. The concept of refactoring as applied to software design helps to improve the overall structure of the product or system. Principles of refactoring can also be applied to organization design. As with software design, the design of our organization can benefit from deliberate improvement efforts, but those efforts must have a purpose, and must serve the broad community of stakeholders that affect, or are affected by, the organization. Refactoring to agile and lean organizations demands that we have a shared vision of what the refactoring needs to achieve, and that we optimize the organization around the people doing the work.

1. Refactoring
the
Organiza=on
Design
©
Ken
Power
2010
ken.power@gmail.com

2. Mo=va=on
3.0
and
the
Type
I
Toolkit
Carrots
and
s=cks
work,
but
only
in
a
surprisingly
narrow
band
of
circumstances.
For
enduring
mo=va=on
and
high
performance,
autonomy,
mastery,
and
purpose
are
much
beLer.
Get
back
to
first
principles:
deligh2ng
customers,
challenging
employees,
and
making
a
contribu2on.
©
Ken
Power
2010
ken.power@gmail.com

3. Refactoring
• Mar=n
Fowler
“Refactoring:
Improving
the
Design
of
Exis7ng
Code”
(1999)
– “Behavior-­‐preserving
transforma=on
that
improves
the
design
of
exis=ng
code”
• Joshua
Kerievsky
“Refactoring
to
Pa;erns”(2004)
– Suggests
that
using
paLerns
to
improve
an
exis=ng
design
is
beLer
than
using
paLerns
early
in
a
new
design
• Whether
code
is
years
old
or
minutes
old
– “We
improve
designs
with
paLerns
by
applying
sequences
of
low-­‐level
design
transforma=ons,
known
as
refactorings.”
©
Ken
Power
2010
ken.power@gmail.com

4. Tease
Apart
Hierarchies
• You
have
an
inheritance
hierarchy
that
is
doing
two
jobs
at
once
• Create
two
hierarchies
and
use
delega7on
to
invoke
one
from
the
other
©
Ken
Power
2010
ken.power@gmail.com

5. Remove
Middle
Man
• A
class
is
doing
too
much
simple
delega=on
• Get
the
Client
to
call
the
delegate
directly
©
Ken
Power
2010
ken.power@gmail.com

6. Collapse
Hierarchy
• A
superclass
and
a
subclass
are
not
very
different
• Merge
them
together
©
Ken
Power
2010
ken.power@gmail.com

7. Transi=on
Journey
scale
Agile
Company
Working
Group
Role
Pilot
Program
Defini=ons
Performance,
Reviews
Agile
Release
Lean
Group
Transi=on
Team
PorFolio
Train
Thinking
Management
Systems
Pilot
Program
Systems
Of
Communi=es
Kanban
Systems
Systems
For
Systems
Forums
Agile
Value
Stream
Office
Mapping
Business
Agile
Lean
Agile
Transi=on
Team
Thinking
PMO
Unit
PorFolio
Kanban
Management
For
Reusable
Con=nuous
Kanban
Components
Improvement
More
Programs
Pilots
Majority
of
Program
Pilot
Program
Projects
and
Programs
Kanban
Select
More
Projects
Pilots
Kanban
Agile
Project
Pilot
Projects
More
Projects
For
Support
Feature
Individual
Teams
Individuals
Evangelists
2008
2009
2010
2011+
=me
©
Ken
Power
2010
ken.power@gmail.com

8. Challenges
• Gaps
in
training
–
not
a
subs=tute
for
experience
• Integra=ng
people
and
groups
outside
the
development/QA
teams
• Integra=ng
User
Experience
groups
• The
role
of
managers
• Understanding
and
managing
dependencies
across
complex
systems
• Customer
engagement
for
mass-­‐market
products
and
systems
• Rewards,
incen=ves,
performance
management
©
Ken
Power
2010
ken.power@gmail.com

9. Core
Framework
vs.
Toolbox
Toolbox
Sets
of
prac=ces
Core
Common
Framework
Baseline
©
Ken
Power
2010
ken.power@gmail.com

10. Refactoring
Toolshed
©
Ken
Power
2010
ken.power@gmail.com

11. ©
Ken
Power
2010
ken.power@gmail.com

12. How
many
people
…
• …
are
in
a
single
Scrum
Team?
• …
does
it
take
to
build
and
deliver
a
product?
• …
does
it
take
to
ship
a
product?
• …
does
it
take
to
ship
a
system?
©
Ken
Power
2010
ken.power@gmail.com

13. Typical
Sta
©
Ken
Power
2010
ken.power@gmail.com

14. Any
group
or
individual
who
can
affect
or
is
affected
by
the
achievement
of
the
organiza=on’s
objec=ves
STAKEHOLDERS
©
Ken
Power
2010
ken.power@gmail.com

15. What
is
a
‘resource’?
©
Ken
Power
2010
ken.power@gmail.com

16. Freeman’s
Basic
2-­‐=er
model
The
Firm
Government
Primary
Stakeholders
Compe=tors
Media
Communi=es
Customers
Secondary
Stakeholders
Financiers
Employees
Suppliers
Special
Interest
Customer
Groups
Advocate
Groups
©
Ken
Power
2010
ken.power@gmail.com

17. Example:
Product
Architecture
Product
Architecture
Client
Development
Teams:
‘Late
integrators’
Primary
Stakeholders
3rd
Party
Developers
Customers
Client
Development
Media
Teams:
‘Early
Integrators’
Architecture
Teams
Secondary
Stakeholders
User
Experience
Teams
Other
Product
Business
Management
Units
API
QA
Client
Teams
Applica=on
Tech
QA
API
Development
Support
Teams
Team
Team
Special
Interest
Test
Automa=on
Groups
Team
System
Test
Team
©
Ken
Power
2010
ken.power@gmail.com

18. Stakeholder
groups
©
Ken
Power
2010
ken.power@gmail.com

19. Stakeholders
in
a
So@ware
Product
Development
effort
• Responsible
for
managing
the
Program
projects
that
are
part
of
the
Sorware
Development
Engineer
User
Experience
program.
Core
• Repor=ng
progress,
QA
Engineer
Universi=es,
Colleges
interfacing
with
the
wider
Team
organiza=on,
and
generally
Test
Automa=on
Research
Ins=tutes
keeping
the
project
on
track.
Feature
Test
Technical
Writer
• People
who
have
a
stake
in
System
Test
Development
Manager
Product
guiding
the
end
deliverable,
Owner
either
through
providing
Performance
Test
QA
Manager
Team
input
or
reviewing/approving
the
output.
Alpha
Test
Product
Manager
Early
Field
Trials
Program
Manager
Marke=ng
System
Architect
• Anyone
that
has
a
stake
in
Enterprise
Architect
Release
Manager
Product
building
the
product.
Delivery
• Generally
responsible
for
Security
analyst
Account
Manager
Team
comple=ng
tasks
that
belong
to
User
Stories.
HR,
Recruiter
Technical
Support
• People
who
have
a
stake
in
Customers
Regulatory
Bodies
evalua=ng,
buying,
or
using
the
product
that
we
build
and
Lawyer
Accountant
in
determining
how
it
fits
with
the
strategic
direc=on
of
Director
Sales
Product
their
own
organiza=on.
Consumers
• Responsibili=es
include
Vice
President,
Senior
VP
Solu=on
Architect
evalua=ng
the
product,
purchasing
the
product,
using
Compe=tors,
Partners
Lab
Administrator
it,
providing
feedback,
and
providing
input
to
the
President
Scrum
Master
/
Agile
Coach
product
direc=on.
CxO
Sorware
Architect
• Anyone
who
has
a
stake
in
Porqolio
the
product
and
how
it
fits
Open
Source
community
Standards
Bodies
Council
with
the
strategic
direc=on
of
our
organiza=on.
3rd
Party
Developers
Media
©
Ken
Power
2010
ken.power@gmail.com

20. STAKEHOLDER
MAPPING
©
Ken
Power
2010
ken.power@gmail.com

21. ©
Ken
Power
2010
ken.power@gmail.com

22. Scrum
Master
Product
Cross-­‐Func=onal
Owner
Delivery
Team
Scrum
Team
Product
Owner
Team
System
User
Porqolio
Experience
Extended
Delivery
Team
Council
Team
Other
Business
Units
Product
Development
Beta
TME
Manager
Manager
GB
Channel
UE
Ramp
Program
Product
Lead
Alpha
Manager
Early
Sales
Access
Architect
Support
QA
Program
Manager
Engineers
Tech
Customer
Support
Engagement
Team
Product
Team
Marke=ng
©
Ken
Power
2010
ken.power@gmail.com

23. ©
Ken
Power
2010
ken.power@gmail.com

24. Stakeholder
Management
Principles
1. Stakeholder
interests
need
to
go
6. We
need
intensive
communica=on
together
over
=me.
and
dialogue
with
stakeholders
–
2. We
need
a
philosophy
of
not
just
those
who
are
friendly.
volunteerism
–
to
engage
7. Stakeholders
consist
of
real
people
stakeholders
and
manage
with
names
and
faces
and
children.
rela=onships
ourselves
rather
than
They
are
complex.
leave
it
to
government.
8. We
need
to
generalize
the
3. We
need
to
find
solu=ons
to
issues
marke=ng
approach.
that
sa=sfy
mul=ple
stakeholders
9. We
engage
with
both
primary
and
simultaneously.
secondary
stakeholders.
4. Everything
that
we
do
serves
10. We
constantly
monitor
and
stakeholders.
We
never
trade
off
redesign
processes
to
make
them
the
interests
of
one
versus
the
beLer
serve
our
stakeholders.
other
con=nuously
over
=me.
5. We
act
with
purpose
that
fulfills
our
commitment
to
stakeholders.
We
act
with
aspira=on
towards
fulfilling
our
dreams
and
theirs.
©
Ken
Power
2010
ken.power@gmail.com

25. The
role
of
manager
• “Whatever
the
magnitude
of
their
stake,
each
stakeholder
is
a
part
of
the
nexus
of
implicit
and
explicit
contracts
that
cons7tutes
the
firm.
However,
as
a
group,
managers
are
unique
in
this
respect
because
of
their
posi7on
at
the
centre
of
the
nexus
of
contracts.
Managers
are
the
only
groups
of
stakeholders
who
enter
into
a
contractual
rela7onship
with
all
other
stakeholders.
Managers
are
also
the
only
direct
control
over
the
group
of
stakeholders
with
decision-­‐making
apparatus
of
the
firm.”
– (Hill
&
Jones,
1992:
134)
©
Ken
Power
2010
ken.power@gmail.com

26. Crea=ng
the
right
environment
Product
Organiza=on
• Build
organiza=on
• Org
strategy
Directors
• Remove
barriers
at
org,
cross-­‐ Product
product
level
Product
Owner
Team
Product
Owner
Product
(CUCIMOC)
Owner
Team
• Build
teams
Product
2nd
Line
• Product
strategy
Product
aster
Scrum
M
Owner
(CUCIMOC)
Managers
• Remove
barriers
at
product,
Owner
Team
cross-­‐team
level
Owner
Product
Scrum
Master
Delivery
Scrum
Team
Master
Product
Delivery
• Develop
people
1st
Line
• Release
strategy
Team
Delivery
Managers
• Remove
barriers
at
release,
Team
team
level
©
Ken
Power
2010
ken.power@gmail.com

27. Stakeholder
Engagement
Rhythm
Full
Product
Release
Release
Rhythm
Project Product
Rhythm
Increment
Itera=on
©
Ken
Power
2010
ken.power@gmail.com

28. Metaphors
• “Each
metaphor
gives
us
some
insight,
and
taken
together
they
show
what
a
complex
concept
learning
really
is.
No
one
metaphor
is
“correct”,
but
each
represents
a
different
understanding.”
Mul2ple
Metaphors
for
Learning
by
Gary
Woodill
In
“Learning
and
organiza,ons:
towards
cross-­‐metaphor
conversa,ons”
©
Ken
Power
2010
ken.power@gmail.com

29. ©
Ken
Power
2010
ken.power@gmail.com

30. Jazz
Improvisa=on
• Provoca=ve
competence:
Deliberate
efforts
to
interrupt
habit
paKerns
• Embracing
errors
as
a
source
of
learning
• Shared
orienta=on
toward
minimal
structures
that
allow
maximum
flexibility
• Distributed
task:
con2nual
nego2a2on
and
dialogue
toward
dynamic
synchroniza=on
• Reliance
on
retrospec2ve
sense-­‐making
• "Hanging
out":
Membership
in
a
community
of
prac2ce
• Taking
turns
soloing
and
suppor=ng
“Crea,vity
and
Improvisa,on
in
Jazz
and
Organiza,ons:
Implica,ons
for
Organiza,onal
Learning”
-­‐
Frank
J.
BarreL
"Organiza2on
Science"
/
Vol
9,
No.5.
September-­‐October
1998
©
Ken
Power
2010
ken.power@gmail.com

31. Arqul
Making
–
Ch.
1:
What’s
really
different
about
knowledge
work
AS
BUSINESS
BECOMES
MORE
DEPENDENT
ON
KNOWLEDGE
TO
CREATE
VALUE,
WORK
BECOMES
MORE
LIKE
ART.
©
Ken
Power
2010
ken.power@gmail.com

32. An
industrial
making
process
Concept
genera=on
Product
planning
Product
engineering
Process
engineering
Produc=on
process
Product
©
Ken
Power
2010
ken.power@gmail.com

33. An
ArFul
Making
Process
Generate
Product
Talk
with
Repeat
customer
about
product
Expose
customer
to
product
©
Ken
Power
2010
ken.power@gmail.com

34. Release
Collabora=on
Ensemble
Play
4
QUALITIES
OF
ARTFUL
MAKING
©
Ken
Power
2010
ken.power@gmail.com

35. A
method
of
control
that
accepts
wide
varia=on
within
known
parameters.
Release
contrasts
with
Restraint,
the
usual
method
of
industrial
control.
RELEASE
©
Ken
Power
2010
ken.power@gmail.com

36. The
quality
exhibited
by
conversa=on,
in
language
and
behavior,
during
which
each
party,
released
from
vanity,
inhibi=on,
and
preconcep=ons,
treats
the
contribu=ons
of
other
par=es
as
material
to
make
with,
not
as
posi=ons
to
argue
with,
so
that
new
and
unpredictable
ideas
emerge.
COLLABORATION
©
Ken
Power
2010
ken.power@gmail.com

37. The
quality
exhibited
by
the
work
of
a
group
dedicated
to
a
collabora=on
in
which
individual
members
relinquish
sovereignty
over
their
work
and
thus
create
something
none
could
have
made
alone:
a
whole
greater
than
the
sum
of
its
parts.
ENSEMBLE
©
Ken
Power
2010
ken.power@gmail.com

38. The
quality
exhibited
by
a
produc=on
while
it
is
playing
for
an
audience;
or
the
quality
exhibited
by
interac=on
among
members
of
a
business
group,
and
ul=mately
between
the
group
and
the
customer.
PLAY
©
Ken
Power
2010
ken.power@gmail.com

39. So@ware
Development
Play
Making
Itera=ve
Cycle
Product
build
and
test;
try
Rehearsal
different
op=ons
Distributed,
independent,
Individual
developers
at
work
Individual
actors
preparing
simultaneous
inven=on
on
design
or
source
code
between
runs
Unifying
ac=on
A
product
build
A
rehearsal
run
A
director
who
facilitates
The
Scrum
Master
or
project
The
director
coherent
chaos
manager
Forum
for
conversa=on
Mee=ngs,
technology-­‐based
The
rehearsal
room
collabora=ve
forums,
Daily
Standup,
Itera=on
Review,
Pair
Programming,
Retrospec=ves,
…
Way
of
sezng
structure
Code
holds
structure
Actors
enact
structure
External
characteris7cs
of
ArFul
Making
in
Agile
SoYware
Development
and
Play
Making
(slightly
modified)
©
Ken
Power
2010
ken.power@gmail.com

40. Organiza=on
PaLerns
• The
organiza=on
paLerns
iden=fied
by
Coplien
and
Harrison
address
specific
stakeholders,
and
the
rela=onships
between
stakeholders
• Provide
guidance
on
building
effec=ve
stakeholder
rela=onships
within
sorware
development
organiza=ons
• Consider
an
organiza=on
as
a
social
system
with
structures
• Iden=fy
paLerns
that
have
helped
sorware
companies
to
achieve
improved
efficiencies
in
organiza=on
and
performance.
• Four
paLern
languages
– project
management
– growth
of
the
product
and
process
– organiza=on
style
and
role
rela=onships
– people
and
code
©
Ken
Power
2010
ken.power@gmail.com

41. Summary
• Agile
and
Lean
lead
to
organiza=onal
change
• Organiza=on
design
can
benefit
from
principles
of
refactoring
• Our
organiza=ons
have
stakeholders
– Take
a
broad
view
of
stakeholders
– The
principles
of
stakeholder
management
help
us
to
iden=fy,
understand
and
engage
with
the
many
diverse
range
of
stakeholders.
• When
refactoring
an
organiza=on’s
design
to
support
agile
and
lean
development,
we
aim
to
op=mize
the
structures
of
the
organiza=on
around
the
people
who
are
doing
the
work
• To
be
meaningful,
refactoring
must
have
a
purpose.
– Metaphors
provide
a
useful
tool
to
communicate
that
purpose.
– Jazz
improvisa=on
and
Arqul
Making
are
two
useful
enabling
metaphors
for
understanding
the
rich
and
complex
interac=ons
between
the
many
and
varied
stakeholders
in
a
product
development
organiza=on.
• Organiza=on
PaLerns
provide
a
rich
body
of
knowledge
that
compliments
agile
and
lean,
and
that
provides
proven
paLerns
for
engaging
stakeholders
and
guiding
changes
in
the
design
of
our
organiza=on.
©
Ken
Power
2010
ken.power@gmail.com

42. ©
Ken
Power
2010
ken.power@gmail.com