Refactoring the Organization Design (LESS2010)
3 likes4,161 views
The document discusses the principles of refactoring organizational design to enhance motivation and performance in agile and lean environments, emphasizing the importance of autonomy, mastery, and purpose. It outlines roles of various stakeholders in software development and highlights best practices for effective stakeholder management. The text also explores using metaphors, such as jazz improvisation, to understand complex interactions among stakeholders and to communicate the purpose of organizational change.
Refactoring the Organization Design (LESS2010)
- 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