Refactoring the Organization Design (LESS2010)

© Ken Power 2010 [email protected]

Refactoring the Organiza=on Design


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.


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.”


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


Remove Middle Man

•  A class is doing too much simple delega=on •  Get the Client to call the delegate directly


Collapse Hierarchy

•  A superclass and a subclass are not very different

•  Merge them together


scale

=me

Project

Individuals

Program

Business Unit

Group

Company

2008 2009 2010 2011+

Agile Transi=on Team

Select Pilot Projects

Individual Evangelists

Pilot Program

Systems

Agile Transi=on Team

Agile Working Group

Agile Office

Release Train

Systems Of

Systems

PorFolio Management

PorFolio Management

Role Defini=ons

Performance, Reviews

More Projects More Projects

Communi=es

Forums

More Programs

Systems

Majority of Projects and Programs

Agile

Feature Teams

Kanban Pilots

Kanban Pilots

Kanban For Support

Kanban For Systems

Lean Thinking

Lean Thinking

Agile PMO

Value Stream Mapping

Transi=on Journey

Kanban For Reusable Components

Con=nuous Improvement

Pilot Program

Pilot Program


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


Core Framework vs. Toolbox

Core Framework

Toolbox

Common Baseline

Sets of prac=ces


Refactoring Toolshed


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?


Typical Sta


STAKEHOLDERS

Any group or individual who can affect or is affected by the achievement of the organiza=on’s objec=ves


What is a ‘resource’?


The Firm

Primary Stakeholders

Secondary Stakeholders

Communi=es

Financiers

Suppliers

Employees

Customers

Customer Advocate Groups

Special Interest Groups

Media

Government

Compe=tors

Freeman’s Basic 2-‐=er model


Product Architecture

Primary Stakeholders

Secondary Stakeholders Architecture Teams

Client Development Teams: ‘Early Integrators’

API Development Team

API QA Teams

Product Management

Test Automa=on Team

Special Interest Groups

Media

3rd Party Developers

Customers

User Experience Teams

System Test Team

Client Development Teams: ‘Late integrators’

Other Business Units

Client Applica=on

QA Teams

Tech Support Team

Example: Product Architecture


Stakeholder groups


Program

Core

Team

• Responsible for managing the projects that are part of the program. • Repor=ng progress, interfacing with the wider organiza=on, and generally keeping the project on track.

Product Owner Team

• People who have a stake in guiding the end deliverable, either through providing input or reviewing/approving the output.

Product Delivery Team

• Anyone that has a stake in building the product. • Generally responsible for comple=ng tasks that belong to User Stories.

Product

Consumers

• People who have a stake in evalua=ng, buying, or using the product that we build and in determining how it fits with the strategic direc=on of their own organiza=on. • Responsibili=es include evalua=ng the product, purchasing the product, using it, providing feedback, and providing input to the product direc=on.

Porqolio

Council

• Anyone who has a stake in the product and how it fits with the strategic direc=on of our organiza=on.

Stakeholders in a So@ware Product Development effort

Sorware Development Engineer User Experience

QA Engineer Universi=es, Colleges

Test Automa=on Research Ins=tutes

Feature Test Technical Writer

System Test Development Manager

Performance Test QA Manager

Alpha Test Product Manager

Early Field Trials Program Manager

Marke=ng System Architect

Enterprise Architect Release Manager

Security analyst Account Manager

HR, Recruiter Technical Support

Customers Regulatory Bodies

Lawyer Accountant

Director Sales

Vice President, Senior VP Solu=on Architect

Compe=tors, Partners Lab Administrator

President Scrum Master / Agile Coach

CxO Sorware Architect

Open Source community Standards Bodies

3rd Party Developers Media


STAKEHOLDER MAPPING


Cross-‐Func=onal Delivery Team

Scrum Master

Product Owner

Scrum Team

Product Manager

QA Manager

Development Manager

Program Manager

Alpha

Beta TME

Early Access Program

User Experience

Team

Product Marke=ng

Channel Ramp

Other Business Units

GB

Tech Support Team

Product Owner Team

Extended Delivery Team

Product

System Porqolio Council

Sales Support Engineers

Customer Engagement

Team

UE Lead

Architect


Stakeholder Management Principles

1.  Stakeholder interests need to go together over =me.

2.  We need a philosophy of volunteerism – to engage stakeholders and manage rela=onships ourselves rather than leave it to government.

3.  We need to find solu=ons to issues that sa=sfy mul=ple stakeholders simultaneously.

4.  Everything that we do serves stakeholders. We never trade off the interests of one versus the 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.

6.  We need intensive communica=on and dialogue with stakeholders – not just those who are friendly.

7.  Stakeholders consist of real people with names and faces and children. They are complex.

8.  We need to generalize the marke=ng approach.

9.  We engage with both primary and secondary stakeholders.

10.  We constantly monitor and redesign processes to make them beLer serve our stakeholders.


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

group of stakeholders with direct control over the decision-‐making apparatus of the firm.” –  (Hill & Jones, 1992: 134)


Crea=ng the right environment

Product Owner Team (CUCIMOC)

Scrum Master Product Delivery Team

Product Owner

• Build organiza=on • Org strategy • Remove barriers at org, cross-‐product level

Directors

• Build teams • Product strategy • Remove barriers at product, cross-‐team level

2nd Line Managers

• Develop people • Release strategy • Remove barriers at release, team level

1st Line Managers

Product Organiza=on

Product Owner Team (CUCIMOC)

Scrum Master Product Delivery Team

Product Owner

Product Owner Team

Scrum Master

Delivery Team

Product Owner


Itera=

on

Product Increment

Full Product Release Release Rhythm

Project Rhythm

Stakeholder Engagement Rhythm


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”


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


AS BUSINESS BECOMES MORE DEPENDENT ON KNOWLEDGE TO

CREATE VALUE, WORK BECOMES MORE LIKE ART.

Arqul Making – Ch. 1: What’s really different about knowledge work


Concept genera=on

Product planning

Product engineering

Process engineering

Produc=on process

Product

An industrial making process


An ArFul Making Process

Talk with customer about product

Repeat

Expose customer to product

Generate Product


4 QUALITIES OF ARTFUL MAKING

Release

Collabora=on

Ensemble

Play


RELEASE

A method of control that accepts wide varia=on within known parameters. Release contrasts with Restraint, the usual method of industrial control.


COLLABORATION

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.


ENSEMBLE

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.


PLAY

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.


So@ware Development Play Making

Itera=ve Cycle Product build and test; try different op=ons

Rehearsal

Distributed, independent, simultaneous inven=on

Individual developers at work on design or source code

Individual actors preparing between runs

Unifying ac=on A product build A rehearsal run

A director who facilitates coherent chaos

The Scrum Master or project manager

The director

Forum for conversa=on Mee=ngs, technology-‐based collabora=ve forums, Daily Standup, Itera=on Review, Pair Programming, Retrospec=ves, …

The rehearsal room

Way of sezng structure Code holds structure Actors enact structure

External characteris7cs of ArFul Making in Agile SoYware Development and Play Making (slightly modified)


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


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.

Refactoring the Organization Design (LESS2010)

Business

Transcript of Refactoring the Organization Design (LESS2010)