Downloaded 906 times
Uploaded byMike Cottmeyer
Exploring Agile Transformation and Scaling Patterns
The document discusses strategies for enterprise agile transformation, contrasting agile adoption with transformation, and emphasizes the importance of organizational, personal, and delivery practices in achieving sustainable change. It includes competency models, case studies, and outlines the iterative approach necessary for long-term success in agile practices. Key considerations include fostering an adaptable organization, enabling teamwork, and focusing on delivering business outcomes rather than just implementing agile practices.
In this document
Powered by AI
Introduction to Agile Transformation, featuring coaches Mike Cottmeyer and Dennis Stevens.
The agenda outlines key topics like Agile Adoption vs Transformation, goals, competency models, and case studies.
Differentiation between Agile Adoption (practices) and Transformation (core identity).
Details on the iterative process of adopting Agile methodologies while addressing personal and organizational change.
Identifies common pitfalls such as maintaining functional silos and ineffective team structures.
The primary aim is to enhance business outcomes, not merely to adopt frameworks.
Focus on delivering value through product definition, planning, coordination, practices, and organizational support.
Discusses competency models for effective product definition, planning, coordination, and achieving organizational enablement.
Explores competency models across different frequencies and scales, highlighting 125 possible combinations.Focus on assessment results over time to foster continuous improvement within the organization.
Defines incremental and iterative methodologies for enhanced value delivery and project management.Phases of delivery focusing on product definition, continuous improvement, and organizational enablement.
Introduction to case studies examining Agile transformations within various organizations.
Assessment and plan for transformation focused on organizational design patterns and developing competency improvements.
Assessment and engagement to improve predictability and integration of various organizational aspects.
Challenges and plans to improve organizational alignment and reduce dependency issues affecting delivery.
Engagement strategy focusing on team structure, trust issues, and aligning objectives across departments.
Summarizes the importance of incremental Agile introduction, addressing organizational structures, practices, and competencies.
More Related Content
Similar to Exploring Agile Transformation and Scaling Patterns
Exploring Agile Transformation and Scaling Patterns
- 1. Exploring Enterprise AgileTransformation StrategiesMike Cottmeyer, Agile CoachLeadingAgile, LLCDennis Stevens, Agile CoachSynaptus
- 2.
- 3.
- 4.
- 5. AgendaThe difference betweenAgile Adoption and Agile Transformation
- 6. AgendaThe difference betweenAgile Adoption and Agile TransformationThe real goal of Agile change initiatives
- 7. AgendaThe difference betweenAgile Adoption and Agile TransformationThe real goal of Agile change initiativesCompetency models, our competency model, and how to choose practices specific practices against the model
- 8. AgendaThe difference betweenAgile Adoption and Agile TransformationThe real goal of Agile change initiativesCompetency models, our competency model, and how to choose practices specific practices against the modelAdapting practices for different frequency intervals in your organization
- 9. AgendaThe difference betweenAgile Adoption and Agile TransformationThe real goal of Agile change initiativesCompetency models, our competency model, and how to choose practices specific practices against the modelAdapting practices for different frequency intervals in your organizationAdapting practices for different levels of scale within your organization
- 10. AgendaThe difference betweenAgile Adoption and Agile TransformationThe real goal of Agile change initiativesCompetency models, our competency model, and how to choose practices specific practices against the modelAdapting practices for different frequency intervals in your organizationAdapting practices for different levels of scale within your organizationCase studies (4 in total)
- 11. Agile Adoption vs.Agile Transformation
- 12. Adoption vs. TransformationAgileAdoption is more about what you do… practices, tools, techniques, and habitsAgile Transformation is more about who you are… reflected in both the structure of the organization and who you are as people
- 13. Adoption/Transformation CycleIntroducing Agileis Iterative and IncrementalChanging some of the physical structures in our organization
- 14. Teaching people newways of working together
- 15. Helping people internalizehow and why agile really works… living the value systemAdoption/Transformation CycleOrganizationalTransformationEstablish a top-down organizational design pattern and roadmap
- 16. Make incremental changesto the structure of the organization, build Agile teams
- 17. Establish policies andworking agreementsAdoption/Transformation CycleAdopt PracticesInstantiate sprint planning, daily standups, reviews & retrospectives
- 18. Identify a ScrumMasterand Product Owner
- 19. Start doing TDDand Continuous Integration
- 20. Story Mapping andAgile Requirements decompositionAdoption/Transformation CyclePersonal TransformationDevelop a greater ability to deal with ambiguity and inspect and adapt
- 21. Help people towork together toward common goals
- 22. Demonstrate greater understandingand empathy amongst individuals
- 23. TeamworkYou have toaddress all three aspects to achieve sustainable organizational change…
- 24. Common Anti-PatternsEstablishing teamswithout breaking down the strict functional silos and rigid role definitionsRunning daily standup meetings that devolve into status updates for the project managerComing back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices
- 25. Common Anti-PatternsEstablishing teamswithout breaking down the strict functional silos and rigid role definitionsRunning daily standup meetings that devolve into status updates for the project managerComing back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices
- 26. Common Anti-PatternsEstablishing teamswithout breaking down the strict functional silos and rigid role definitionsRunning daily standup meetings that devolve into status updates for the project managerComing back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices
- 27. Common Anti-PatternsEstablishing teamswithout breaking down the strict functional silos and rigid role definitionsRunning daily standup meetings that devolve into status updates for the project managerComing back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices
- 28. The problem withAgile Transformation is that the goal is never to adopt agile…
- 29. …Scrum and XPprovide specific frameworks to help us deliver better software…
- 30. …The goal isto improve business outcomes!
- 31. Value DeliveryDelivery GoalsFasterTime to Market… frequent, smaller releases
- 32. High quality products…low number of escaped defects
- 33.
- 34. Predictability… deliver whatwe say we are going to deliver
- 35. Happy CustomersProduct DefinitionPlanning& CoordinationContinuous ImprovementDelivery PracticesOrganizational Enablement25
- 36. Value DeliveryProduct DefinitionExtremelyclear product vision
- 37. Well articulated productroadmap
- 38. Decompose product themesinto fine grained product features
- 39. Define detailed acceptancecriteria and make trade-offs
- 40. Accurately estimate effortand durationProduct DefinitionPlanning & CoordinationContinuous ImprovementDelivery PracticesOrganizational Enablement26
- 41. Value DeliveryPlanning &CoordinationEstablish a regular planning cadence
- 42. Break down featuresinto tasks and define acceptance tests
- 43. Establish a cadenceof delivering working tested features
- 44. Limit the amountof work in process
- 45. Regularly make andmeet commitments
- 46. Continually adapt theplanProduct DefinitionPlanning & CoordinationContinuous ImprovementDelivery PracticesOrganizational Enablement27
- 47. Value DeliveryDelivery PracticesEmergentArchitecture and Design
- 48. Rapid delivery ofsmall features into the product
- 49. Continuous testing ofthe product
- 50. Clean code andfixing defects as we go
- 51. Deploy the solutioneither internally or externally on demandProduct DefinitionPlanning & CoordinationContinuous ImprovementDelivery PracticesOrganizational Enablement28
- 52. Value DeliveryContinuous ImprovementMetricsand Reporting
- 53. Teams that havea stable velocity
- 54. Retrospectives at alllevels of the organization
- 55.
- 56.
- 57. Lead and managechangeProduct DefinitionPlanning & CoordinationContinuous ImprovementDelivery PracticesOrganizational Enablement29
- 58.
- 59. Regular checkpoints tomake sure everyone is on the same page
- 60. People work togetherto solve problems
- 61. People are empoweredto make decisions
- 62. High levels oftrust between coworkersValue DeliveryProduct DefinitionPlanning & CoordinationContinuous ImprovementDelivery PracticesOrganizational Enablement30
- 63. Focus less onimplementing specific agile practices…
- 64. …and more ondeveloping situationally specific strategies to solve business problems.
- 65. Competency Models… andour Competency Model
- 66. Product DefinitionEstablish theProduct VisionThe ability to determine and clearly communicate the product’s primary customer base, it’s competitive differentiators, and competitive alternatives. At the release level, it’s the ability to determine why we are building this product, whom it is for, and why the release is important. Define the Product RoadmapThe product roadmap is the strategic plan for how the Product Vision will be executed. In an agile organization, this roadmap should be at the Epic level and show when various Epics need to be in market. The Product Roadmap should be supported with either Epic size or budget, and be validated against proven capacity to deliver. Epics are generally 1-3 months in size. Decompose FeaturesThe ability to decompose features means to break Epics into high-level feature functions that can be communicated and/or committed to customers. Features follow the same format as user stories, but are at a higher level of abstraction, much like use cases, or use case scenarios. Features are generally take 2-4 weeks to deliverEstimate Size and EffortDoes the organization have the ability to accurately estimate the size and effort of a given Epic, Feature, or User Story? Are these estimates generated using team based, collaborative techniques? Are these estimates validated with empirical evidence gathered from actual delivery of working software?Define Acceptance CriteriaDoes the team have clear guidance on what is the definition of done? Do they know what it will take to meet the business requirements defined by the product owner? 34
- 67. Planning & CoordinationEstablisha Planning Cadence Is there a release train in place? Is there a regular release-planning cadence? Do the teams meet regularly with their Product Owner to plan sprints? Does the organization do strategic planning and roadmap planning? Perform Activity BreakdownDo the teams break user stories into sufficiently small increments that they can be incrementally delivered and tracked through the sprint? If not, do the teams break larger user stories down into tasks and tests that can be tackled by more than one team member at a time Establish Delivery CadenceDoes the team have a pattern of delivering working, tested software every sprint? Do multi-team projects show a pattern of coming together to deliver an integrated increment of software on a regular, periodic basis? Does the organization show a pattern of early delivery of whole Epics in a release cycle?Limit Work in ProcessDoes the organization, release architecture, or team have the ability to limit the number of Epics, Features, or User Stories they are working on concurrently? Does the organization value completing work rather than getting new work started? Are teams allowed to focus on one thing until delivery, or are they constantly pulled onto other, higher priority initiatives. Do priorities change often? Make and Meet CommitmentsDoes the organization, release, or team regularly do what it says it will do? Do they have the ability to make and meet commitments on short time-boxed intervals? 35
- 68. Delivery PracticesDefine theSolution Does the team have the capability to allow architectures and designs to change as we learn more about the emerging product? Do the team use agile modeling techniques? Is there a desire to plan everything before we start building any working product? Does the team use a value and risk driven approach to working out the systems architecture and design. Build the SolutionDo the developers have the tools necessary to build an increment of working software? Can software be checked in and validated on a continuous basis. Are the teams doing unit testing? Are the tests run in a test harness at check in? Are the developers confident working in the code base? Is the code safe to change? Test the SolutionIs there a mechanism in place to incrementally test and validate the software as it is being built? Is all software tested before it is accepted? Is all software tested before it is put into production? Are the number of ‘hardening sprints’ equal to or greater than the number of sprints it took to build the product? Are the teams using continuous integration and TDD? Technical Debt and DefectsAre defects routinely carried over from sprint to sprint and handled toward the end of the release? Do teams have difficulty estimating work due to unexpected defects and code that is difficult to understand and maintain? Deploy the SolutionIs there an ability to incrementally deliver the solution, either to an internal customer for review, or to an external customer that will actually use the product?36
- 69. Continuous Improvement Metricsand ReportingDoes the organization have a package of agile metrics that support team level up to executive level decision-making? Are there processes in place for gathering these metrics and reporting them to the appropriate stakeholders? Establish Stable VelocityCan the organization, at the enterprise, release, or team levels; reliably and predictably deliver a known quantity of working software at every iteration or release boundary? Conduct RetrospectivesDoes the organization regularly conduct reviews and retrospectives at the end of every iteration or release boundary? Is there a mechanism for acting on lessons learned and new opportunities discovered in these sessions? Update the Release BacklogIs there a mechanism in place for quickly updating the release backlog when new information is learned about the emerging product or when business priorities change? Enable Process ImprovementIs there a mechanism in place for quickly updating organizational processes in the face of impediments that might impact product delivery? 37
- 70. Organizational EnablementTeam BasedDelivery Is the organization formed around agile teams? Do the teams have everything they need to successfully deliver an increment of working tested software? Are members constantly pulled away from teams and assigned to other initiatives. Is there team level accountability for sprint outcomes? Is there team level accountability for release level outcomes? CommunicationHow well do people talk to each other and communicate the right level of information? Do teams openly an honestly share information that could help the organization be more successful? CollaborationDo cross-functional teams regularly work together to define requirements, architectures, designs, test plans, etc.? Do team members often work in silos with limited communication amongst team members? EmpowermentAre people and teams authorized to make decisions within their established constraints or within pre-defined guidelines? Are decisions routinely overturned? Are the right stakeholders present when decisions are made? TrustIs there open and honest communication between team members? Is it safe to share bad news? Does management ‘shoot the messenger’ when bad news in delivered? Do people feel they can openly and honestly give negative feedback? 38
- 71. Applying the CompetencyModel at Different Frequencies
- 72.
- 73.
- 74.
- 75.
- 76.
- 77. Applying the CompetencyModel at Different Levels of Scale
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85. How do thethree dimensions Fit Together?
- 86.
- 87. Create Situationally SpecificStrategies for Each Competency, Frequency & Scale Combination
- 88. 125 Possible Combinations Competency:Continuous IntegrationFrequency: Daily BuildScale: Across Multiple Teams
- 89. 125 Possible Combinations Competency:Continuous IntegrationFrequency: DailyScale: Across Multiple TeamsCompetency: Continuous IntegrationFrequency: ReleaseScale: At the Portfolio Level
- 90. 125 Possible Combinations Competency:Define the ProductFrequency: Iteration PlanningScale: Single Team
- 91. 125 Possible Combinations Competency:Define the ProductFrequency: Iteration PlanningScale: Single TeamCompetency: Define the ProductFrequency: Strategic PlanningScale: Entire Enterprise
- 92. 125 Possible Combinations Competency:Explore Improvement OptionsFrequency: Iteration PlanningScale: Single Team
- 93. 125 Possible Combinations Competency:Explore Improvement OptionsFrequency: Daily PlanningScale: Single TeamCompetency: Explore Improvement OptionsFrequency: Release PlanningScale: Portfolio Management
- 94. Assessing the Organizationand Getting Better Over Time
- 95. Assessment Results –at Start63
- 96. Assessment Results –at Month One64
- 97. Assessment Results –at Month Two65
- 98. Leading Change byIncrementing and Iterating Through the Organization
- 99. Incremental and IterativeDeliveryIncrementalVarious parts of the system are developed at different times or rates, and integrated as they are completed. You can do this in a waterfall project or an iterative project.IterativeGo back over parts of the system to revise and improve the system. In iterative development testing and/or user feedback is used to revise the targets of the successive deliverables. The practice of iterations arises from a desire to coordinate feedback from increments to revise a future deliverable.Courtesy of Jeff Patton
- 100. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesPhase ICultural FactorsOrganizational Enablement68
- 101. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesProduct DefinitionPlanning CoordinationContinuous ImprovementDelivery PracticesPhase IProduct DefinitionContinuous ImprovementPlanning CoordinationDelivery PracticesOrganizational Enablement69
- 102. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesPhase IProduct DefinitionContinuous ImprovementPlanning CoordinationDelivery PracticesOrganizational Enablement70
- 103. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesPhase IProduct DefinitionContinuous ImprovementPlanning CoordinationDelivery PracticesOrganizational Enablement71
- 104. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesProduct DefinitionPlanning CoordinationContinuous ImprovementDelivery PracticesPhase IIProduct DefinitionContinuous ImprovementPlanning CoordinationDelivery PracticesOrganizational Enablement72
- 105. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesProduct DefinitionPhase IIPlanning CoordinationContinuous ImprovementDelivery PracticesOrganizational Enablement73
- 106. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesProduct DefinitionPhase IIPlanning CoordinationContinuous ImprovementDelivery PracticesOrganizational Enablement74
- 107. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesContinuous ImprovementProduct DefinitionPlanning CoordinationContinuous ImprovementDelivery PracticesProduct DefinitionPlanning CoordinationDelivery PracticesPhase IIIOrganizational Enablement75
- 108. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesProduct DefinitionPlanning CoordinationContinuous ImprovementDelivery PracticesPhase IIIOrganizational Enablement76
- 109. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesProduct DefinitionPlanning CoordinationContinuous ImprovementDelivery PracticesPhase IIIOrganizational Enablement77
- 110. Value DeliveryProduct DefinitionPlanningCoordinationContinuous ImprovementDelivery PracticesProduct DefinitionPlanning CoordinationContinuous ImprovementDelivery PracticesSustainabilityOrganizational Enablement78
- 111. Case Study #1– Large Federal Lending Institution
- 112. Case Study: SituationFinancial services firm350 employees-70 in IT Software DevelopmentSupport customer facing, internal systems and integrations to third-party applicationsTrack record of late unpredictable delivery and high demand for production support – recent two year project took four years to partially complete
- 113. Case Study: AssessmentPlanningand coordinationLow transparencySignificant WIP and individual multi-taskingGranular detail required up-frontOrganizational EnablementLow trust and collaborationDelivery PracticesSignificant rework
- 114. Case Study: PlanOrganizationalDesign Patterns5 stable delivery teams w/ a support teamConvert Configuration Management to DevOpsEstablish consolidated Value ManagementConvert PMO from day to day tasking to operate at the audit and governance levelRoad-mapJanuary: Stand up a delivery teamJanuary: Stand up a DevOpsteamFebruary: Stand up the product support teamMarch: Stand up remaining teamsMarch: Migrate CRM-BA model to consolidated Value ManagementMay: Integrate with the PMO
- 115. January: Pilot adelivery teamEstablished Team and Co-located everyone
- 116. Got an exceptionfrom the existing governance process
- 117. Conducted Agile TeamTraining and TDD Training
- 118. Co-located with theteam and coached them daily (planned 3 sprints)January: Expand to Multiple TeamsSupportDelivery TeamsStood up all the teams from the original design
- 119. Conducted training forall developers
- 120. Prepared all theremaining backlogs
- 121. Pushed production supportthrough the support teamJanuary: Expand to Multiple TeamsDelivery LeadershipSupportDelivery Leadership TeamDelivery TeamsEstablished internal mentoring and coaching
- 122. Focus on establishingnew policies and working agreements
- 123.
- 124. Established and alignedCommunities of ExcellenceJanuary: Expand to Multiple TeamsDev OpsSupportDev OpsDelivery Leadership TeamDelivery TeamsRapid environment managementStood up DevOps / CM Team
- 125. Addressed internal policyconstraints on automation
- 126. Moved to automationto rapidly provision environments
- 127. Coached the DevOpsTeam and Production SupportMarch: Begin Competency Improvement TeamJumped to the Enterprise level – Engaging the enterprise and driving efforts from the strategic plan
- 128. Support cross functionaland cross organizational change
- 129. Run transformation asan enterprise project
- 130. Updating control objectives- coaching audit and compliance
- 131. Change management iscriticalDev OpsSupportDelivery Leadership TeamDelivery TeamsPlanImplementFollow upBacklogPrepareCompetency Improvement Team
- 132. April: Align withStrategyEvaluateVerifyExploreDeliverPortfolio ManagementPortfolio LevelUpdated steering committee approach and governance model
- 133. Balance demand againstcapacityDev OpsSupportDelivery LeadershipDelivery TeamsPlanImplementFollow upBacklogPrepareCapability Improvement
- 134. April: Align withStrategyEvaluateVerifyExploreDeliverProgram levelCRM / PO role transitions to the PMOPortfolio ManagementProduceMake ReadyInitiateUATValue ManagementDev OpsSupportDelivery LeadershipDelivery TeamsPlanImplementFollow upBacklogPrepareCapability Improvement
- 135. Lessons LearnedGet startedon the automation earlierChange management must be intentional – managing resistance and organizational inertiaGained momentum when we involved the overall organization in the transformation – business management drove the value proposition
- 136. Cast Study #2– Network Security Appliance Company
- 137. Company ProfileBased inthe United States125 employees located across 4 major cities in the US and CanadaGrowing through acquisition
- 138. Problem StatementFunctional separationbetween Development and QAAd-hoc waterfall based processes not able to scaleToo many projects in queue Teams are not predictableHave not been able to realize their most strategic goal to integrate all the products into a single suite
- 139. Engagement ApproachConducted acompetency assessment on the entire organizationCollaborated on a top-down plan led by the VP of Engineering with full support from the CTO and CEOStarted with the products in Atlanta and systematically moved through other geographies
- 140. Engagement Approach –Phase ITeam Level and Multi-Team AdoptionFocused on Product Definition, Planning & Coordination, and Organizational Enablement Competencies firstMostly at the Daily, Iteration, and Release levels
- 141. Engagement Approach –Phase 2Skipped the Program Management layer and went straight to Portfolio & StrategyFocusing on Product Definition, Planning & Coordination, and Organizational Enablement CompetenciesBegan addressing Delivery Practices and Continuous Improvement Mostly at the Daily, Iteration, and Release levelsTrained Marketing, Sales, and Senior Leadership
- 142. Engagement Approach –Phase 3Filled in the Portfolio LevelStill focusing on Product Definition, Planning & Coordination, and Organizational Enablement CompetenciesBegan addressing Delivery Practices and Continuous Improvement Started addressing some of the strategic planning issues
- 143.
- 144.
- 145.
- 146.
- 147.
- 148.
- 149.
- 150. Story BacklogIn ProcessTaskDoneTask BacklogStory BacklogTier 1 - Scrum
- 151. ConstructionTransitionElaborationInceptionTier 3 -KanbanStory BacklogIn ProcessTask DoneTask BacklogStory BacklogTier 1 - Scrum
- 152. ConstructionTransitionElaborationInceptionTier 3 -KanbanDeployBuild Test DesignAnalysisTier 2 - KanbanStory BacklogIn ProcessTask DoneTask BacklogStory BacklogTier 1 - Scrum
- 153. Lessons LearnedHaving buy-inand support up to the CEO makes things a lot easierThe sequence of events is not always intuitiveSometimes it is better to rough in something and come back to it later than try to get it perfect the first timeSpeed can be limited by individual resistance and the rate of organizational learning
- 154. Case Study #3– Financial Service Company
- 155. Case Study: SituationFinancial Software Services Provider19,000 employees-1,000 in target divisionProvider of technology solutions to the financial worldVery successful but long release cycles and low release predictability impact future strategy
- 156. Case Study: AssessmentProductDefinitionChallenges decomposing road-map into clearly defined features and storiesAcceptance criteria evolve after developmentDelivery PracticesQuality was not a foundational practiceCode was developed in large chunks with long feedback cyclesPlanning and coordinationPredictability is difficult due to support demand on teamsChallenges making and keeping commitmentsToo much WIP – the entire release is active simultaneouslyOrganizational EnablementDevelopment teams formed around technology layers and QA and Development are not aligned in the same sprintsSupporting team members (architects, analysts) can be spread across multiple features and services
- 157. Case Study: PlanOrganizationalDesign PatternsAlign Delivery Teams with the Product ArchitectureAlign QA, BA, and Architect with the Delivery Teams Establish clear PO for each feature in Value Management and clarify feature elaborationLimit WIP and make work flow through the organizationRoad-mapGet cross technology development teams created and working from a single backlogEstablish Competency Improvement TeamGet BA and QA aligned with Development teams (dedicated to a team and in the same cadence)Get clarity around the PO’s role and establish effective elaborationAlign the product road-map with the business strategy
- 158. Structure development tomatch the product architectureAlign all teams with product architecture
- 159. Conduct training forall developers
- 160. Prepare the backlogsand get teams to flowDelivery Teams
- 161. Competency Improvement TeamEstablisha broad coalition around the transformation.
- 162. Identified the nextmost important area and enlisted change management support for the transformation Delivery TeamsPlanImplementFollow upBacklogPrepareCompetency Improvement Team
- 163. Move from developmentto delivery teamsDedicate QA and BA to specific teams
- 164. Train on theflow of work through the teams
- 165. Work from asingle backlogValue Management TeamProgram levelValue Management Team with PO per Feature
- 166. Align PMO approachwith Feature level deliveryProduceMake ReadyInitiateUATValue ManagementDelivery TeamsPlanImplementFollow upBacklogPrepareCompetency Improvement Team
- 167. Future: Align withStrategy, SupportPortfolio LevelUse Business Architecture to align and prioritize requirements with the services platformEvaluateVerifyExploreDeliverPortfolio ManagementProduceMake ReadyMultiple Team LevelSupport team (or dedicated performers) to improve predictabilityInitiateUATValue ManagementSupportDelivery TeamsPlanImplementFollow upBacklogPrepareCapability Improvement
- 168. Lessons LearnedAligning developmentinto stable teams with a clear backlog and then introducing QA and BA into the existing teams was organizationally easier – but we have to form all the teams twiceThe guiding coalition and a focus on change management is critical to the transformationThe production support demands from technical debt and the historic approach makes predictability very difficult to achieveMoving PMO attention to the Feature Level made transitioning the governance model easier
- 169. Case Study #4– Energy Management Company
- 170. Company ProfileEuropean companywith offices across the United StatesThousands of employees worldwide, several hundred in the USSignificant amount of product development work done offshore in India
- 171. Problem StatementAdopted Scrumseveral years ago, not getting the expected business benefitReleases are constantly delivered with significantly less features than planned and are often behind scheduleHardware and firmware delivery out of sync with the management console softwarePretty significant trust issues between senior leaders and their direct reports.
- 172. Engagement ApproachConducted acompetency assessment on the entire divisionCollaborated on a top-down plan led by the Director of Quality & Process with full support from the CTOStarted with the teams in Atlanta and are currently moving through other geographies
- 173. Engagement Approach –Phase IAgile teams were in place, but did not stay together over time. First step we formed persistent teamsRequirements decomposition was not happening, so we build a Product Owner team to develop the backlog Focused on Product Definition, Planning & Coordination, and Organizational Enablement Competencies firstExclusively at the Release level to start
- 174. Engagement Approach –Phase 2Continued to ignore the teams and went for Portfolio & StrategyEstablished an Agile Release TrainStill focusing on Product Definition, Planning & Coordination, and Organizational Enablement CompetenciesUncovered significant trust issues between senior level managers within engineering and product management
- 175. Engagement Approach –Phase 3Started addressing performance of the teamsStarted addressing cultural issues around trust and transparency at all levels of the organization Next steps address Delivery Practices and Continuous Improvement Started to revise the roadmap by modeling the entire flow of value from Sales through Product Development into Support and OperationsTighter integration of hardware and firmware
- 176.
- 177.
- 178.
- 179.
- 180.
- 181.
- 182.
- 183.
- 184.
- 185.
- 186. ConstructionTransitionElaborationInceptionTier 3 -KanbanDeployBuild Test DesignAnalysisTier 2 - Kanban
- 187. Story BacklogIn ProcessTaskDoneTask BacklogStory BacklogTier 1 - Scrum
- 188. ConstructionTransitionElaborationInceptionTier 3 -KanbanDeployBuild Test DesignAnalysisTier 2 - KanbanStory BacklogIn ProcessTask DoneTask BacklogStory BacklogTier 1 - Scrum
- 189. Lessons LearnedEngineering onlychange initiatives are likely to struggleEffectively integrating with non-Agile work streams can make or break a transformation effortUnderstanding the flow of value across the entire organization is criticalStarting with teams isn’t always the most strategic approach
- 190. Key Takeaways Introducing Agileat Scale is best done incrementally and iterativelyTo lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organizationOrganizational agility is not about adopting a specific set of practicesbut developing strategies to address competencies at different frequencies and different scales
- 191. Key Takeaways Introducing Agileat Scale is best done incrementally and iterativelyTo lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organizationOrganizational agility is not about adopting a specific set of practicesbut developing strategies to address competencies at different frequencies and different scales
- 192. Key Takeaways Introducing Agileat Scale is best done incrementally and iterativelyTo lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organizationOrganizational agility is not about adopting a specific set of practicesbut developing strategies to address competencies at different frequencies and different scales
- 193. Key Takeaways Introducing Agileat Scale is best done incrementally and iterativelyTo lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organizationOrganizational agility is not about adopting a specific set of practicesbut developing strategies to address competencies at different frequencies and different scales
- 194.
Editor's Notes
- #3 So, before we get started, a little about me. My name is Mike Cottmeyer, I am an agile transformation coach with Pillar technology. Before I joined Pillar I was a trainer and consultant with VersionOne. Before that I ran a pretty large agile portfolio of projects for CheckFree (now Fiserv). Pillar Technology has been around for about 13 years and is just about 100 people strong. Pillar specializes in agile transformation and project delivery. We can bring in agile coaches on the leadership and project management side. We can bring in coaches to help you with TDD. We can spin up teams and help you deliver projects.
- #4 So, before we get started, a little about me. My name is Mike Cottmeyer, I am an agile transformation coach with Pillar technology. Before I joined Pillar I was a trainer and consultant with VersionOne. Before that I ran a pretty large agile portfolio of projects for CheckFree (now Fiserv). Pillar Technology has been around for about 13 years and is just about 100 people strong. Pillar specializes in agile transformation and project delivery. We can bring in agile coaches on the leadership and project management side. We can bring in coaches to help you with TDD. We can spin up teams and help you deliver projects.
- #26 Better Estimation & Release Planning
- #69 Better Estimation & Release Planning
- #70 Better Estimation & Release Planning
- #71 Better Estimation & Release Planning
- #72 Better Estimation & Release Planning
- #73 Better Estimation & Release Planning
- #74 Better Estimation & Release Planning
- #75 Better Estimation & Release Planning
- #76 Better Estimation & Release Planning
- #77 Better Estimation & Release Planning
- #78 Better Estimation & Release Planning
- #79 Better Estimation & Release Planning
- #84 Stable teams with everything needed to deliver an increment of value will more rapidly and predictable deliver high quality work.Stood up FloridaConducted Agile trainingConducted Unit Testing training
- #85 Moved quickly from Pilot to all teams – Findur ended leaving a limited amount of WIP. Had opportunity to create fully capable teams including test and BA.Multiple teams all working from a clear backlog results in a very stable system.Stood up multiple teams
- #86 Multiple teams all working from a clear backlog results in a very stable system. A delivery leadership team is needed to coordinate across the teams, provide mentoring and help share expertise, and to protect the overall capacity of the system. Stood up multiple teamsStood up DelawareMoved quickly from Pilot to all teams – Findur ended leaving a limited amount of WIP. Had opportunity to create fully capable teams including test and BA.
- #87 Dev Ops provide the necessary automation to deliverrapid environment standup, deployment, and testing frameworks in support of Agile Delivery Teams.Started Maryland team with the intention of deliveringrapid deployment
- #88 Improvements to the organization need to be done with a focus on enabling flow across the teams – not the local improvement of a specific functional specialty (BA, Dev, QA, DevOps). Also, the improvement needs to be focused on the next most important problem for the organization to resolve – and it needs to be thoroughly implemented.Launched Delaware Capability Improvement efforts. Started building Capability Improvement efforts through Operations reviews and Project Management Metrics. Building out reporting mechanism and beginning to manage use of Version one to delivery meaningful metrics.
- #89 With the Agile Delivery Team Cadence and effective value management – the governance model may change significantly. Update the governance model to support gaining maximum return for the organizations investment.Tracy revamps portfolio approach and ITGC interface
- #90 With the Agile Delivery Team Cadence and effective value management – the governance model may change significantly. Update the governance model to support gaining maximum return for the organizations investment.Tracy revamps portfolio approach and ITGC interface
- #114 Improvements to the organization need to be done with a focus on enabling flow across the teams – not the local improvement of a specific functional specialty (BA, Dev, QA, DevOps). Also, the improvement needs to be focused on the next most important problem for the organization to resolve – and it needs to be thoroughly implemented.Launched Delaware Capability Improvement efforts. Started building Capability Improvement efforts through Operations reviews and Project Management Metrics. Building out reporting mechanism and beginning to manage use of Version one to delivery meaningful metrics.
- #115 Improvements to the organization need to be done with a focus on enabling flow across the teams – not the local improvement of a specific functional specialty (BA, Dev, QA, DevOps). Also, the improvement needs to be focused on the next most important problem for the organization to resolve – and it needs to be thoroughly implemented.Launched Delaware Capability Improvement efforts. Started building Capability Improvement efforts through Operations reviews and Project Management Metrics. Building out reporting mechanism and beginning to manage use of Version one to delivery meaningful metrics.
- #116 Stable teams with everything needed to deliver an increment of value will more rapidly and predictable deliver high quality work.Stood up FloridaConducted Agile trainingConducted Unit Testing training
- #117 Improvements to the organization need to be done with a focus on enabling flow across the teams – not the local improvement of a specific functional specialty (BA, Dev, QA, DevOps). Also, the improvement needs to be focused on the next most important problem for the organization to resolve – and it needs to be thoroughly implemented.Launched Delaware Capability Improvement efforts. Started building Capability Improvement efforts through Operations reviews and Project Management Metrics. Building out reporting mechanism and beginning to manage use of Version one to delivery meaningful metrics.
- #118 With the Agile Delivery Team Cadence and effective value management – the governance model may change significantly. Update the governance model to support gaining maximum return for the organizations investment.Tracy revamps portfolio approach and ITGC interface
- #145 So, before we get started, a little about me. My name is Mike Cottmeyer, I am an agile transformation coach with Pillar technology. Before I joined Pillar I was a trainer and consultant with VersionOne. Before that I ran a pretty large agile portfolio of projects for CheckFree (now Fiserv). Pillar Technology has been around for about 13 years and is just about 100 people strong. Pillar specializes in agile transformation and project delivery. We can bring in agile coaches on the leadership and project management side. We can bring in coaches to help you with TDD. We can spin up teams and help you deliver projects.