© Ken Power 2010 [email protected]
Refactoring the Organiza=on Design
© Ken Power 2010 [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
Remove Middle Man
• A class is doing too much simple delega=on • Get the Client to call the delegate directly
© Ken Power 2010 [email protected]
Collapse Hierarchy
• A superclass and a subclass are not very different
• Merge them together
© Ken Power 2010 [email protected]
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
© Ken Power 2010 [email protected]
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 [email protected]
Core Framework vs. Toolbox
Core Framework
Toolbox
Common Baseline
Sets of prac=ces
© Ken Power 2010 [email protected]
Refactoring Toolshed
© Ken Power 2010 [email protected]
© Ken Power 2010 [email protected]
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 [email protected]
Typical Sta
© Ken Power 2010 [email protected]
STAKEHOLDERS
Any group or individual who can affect or is affected by the achievement of the organiza=on’s objec=ves
© Ken Power 2010 [email protected]
What is a ‘resource’?
© Ken Power 2010 [email protected]
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
© Ken Power 2010 [email protected]
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
© Ken Power 2010 [email protected]
Stakeholder groups
© Ken Power 2010 [email protected]
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
© Ken Power 2010 [email protected]
STAKEHOLDER MAPPING
© Ken Power 2010 [email protected]
© Ken Power 2010 [email protected]
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
© Ken Power 2010 [email protected]
© Ken Power 2010 [email protected]
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.
© Ken Power 2010 [email protected]
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)
© Ken Power 2010 [email protected]
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
© Ken Power 2010 [email protected]
Itera=
on
Product Increment
Full Product Release Release Rhythm
Project Rhythm
Stakeholder Engagement Rhythm
© Ken Power 2010 [email protected]
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 [email protected]
© Ken Power 2010 [email protected]
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 [email protected]
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
© Ken Power 2010 [email protected]
Concept genera=on
Product planning
Product engineering
Process engineering
Produc=on process
Product
An industrial making process
© Ken Power 2010 [email protected]
An ArFul Making Process
Talk with customer about product
Repeat
Expose customer to product
Generate Product
© Ken Power 2010 [email protected]
RELEASE
A method of control that accepts wide varia=on within known parameters. Release contrasts with Restraint, the usual method of industrial control.
© Ken Power 2010 [email protected]
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.
© Ken Power 2010 [email protected]
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.
© Ken Power 2010 [email protected]
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.
© Ken Power 2010 [email protected]
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)
© Ken Power 2010 [email protected]
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 [email protected]
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 [email protected]