The goal of any enterprise agile adoption strategy is NOT to adopt agile. Companies adopt agile to achieve better business outcomes. Large organizations have no time for dogma and one-size-fits-all thinking when it comes to introducing agile practices. These companies need pragmatic guidance for safely and incrementally introducing structure, principles, and ultimately practices that will result in greater long term, sustainable business results. This talk will introduce a framework for safely, pragmatically, and incrementally introducing agile to help you achieve your business goals.

1. Exploring Enterprise Agile Transformation Strategies Mike Cottmeyer, Agile Coach LeadingAgile, LLC Dennis Stevens, Agile Coach Synaptus

2. Mike CottmeyerLeadingAgilemike@leadingagile.com 1.404.312.1471www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer

3. Dennis StevensSynaptusdennis.stevens@synaptus.com770.851.8025www.synaptus.comtwitter.com/dennisstevens

4. Agenda

5. Agenda The difference between Agile Adoption and Agile Transformation

6. Agenda The difference between Agile Adoption and Agile Transformation The real goal of Agile change initiatives

7. Agenda The difference between Agile Adoption and Agile Transformation The real goal of Agile change initiatives Competency models, our competency model, and how to choose practices specific practices against the model

8. Agenda The difference between Agile Adoption and Agile Transformation The real goal of Agile change initiatives Competency models, our competency model, and how to choose practices specific practices against the model Adapting practices for different frequency intervals in your organization

9. Agenda The difference between Agile Adoption and Agile Transformation The real goal of Agile change initiatives Competency models, our competency model, and how to choose practices specific practices against the model Adapting practices for different frequency intervals in your organization Adapting practices for different levels of scale within your organization

10. Agenda The difference between Agile Adoption and Agile Transformation The real goal of Agile change initiatives Competency models, our competency model, and how to choose practices specific practices against the model Adapting practices for different frequency intervals in your organization Adapting practices for different levels of scale within your organization Case studies (4 in total)

11. Agile Adoption vs. Agile Transformation

12. Adoption vs. Transformation Agile Adoption is more about what you do… practices, tools, techniques, and habits Agile Transformation is more about who you are… reflected in both the structure of the organization and who you are as people

14. Teaching people new ways of working together

16. Make incremental changes to the structure of the organization, build Agile teams

18. Identify a ScrumMaster and Product Owner

19. Start doing TDD and Continuous Integration

21. Help people to work together toward common goals

22. Demonstrate greater understanding and empathy amongst individuals

24. Common Anti-Patterns Establishing teams without breaking down the strict functional silos and rigid role definitions Running daily standup meetings that devolve into status updates for the project manager Coming 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-Patterns Establishing teams without breaking down the strict functional silos and rigid role definitions Running daily standup meetings that devolve into status updates for the project manager Coming 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-Patterns Establishing teams without breaking down the strict functional silos and rigid role definitions Running daily standup meetings that devolve into status updates for the project manager Coming 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-Patterns Establishing teams without breaking down the strict functional silos and rigid role definitions Running daily standup meetings that devolve into status updates for the project manager Coming 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 with Agile Transformation is that the goal is never to adopt agile…

29. …Scrum and XP provide specific frameworks to help us deliver better software…

30. …The goal is to improve business outcomes!

32. High quality products… low number of escaped defects

33. Efficient delivery… minimize waste

34. Predictability… deliver what we say we are going to deliver

35. Happy CustomersProduct Definition Planning & Coordination Continuous Improvement Delivery Practices Organizational Enablement 25

37. Well articulated product roadmap

38. Decompose product themes into fine grained product features

39. Define detailed acceptance criteria and make trade-offs

40. Accurately estimate effort and durationProduct Definition Planning & Coordination Continuous Improvement Delivery Practices Organizational Enablement 26

42. Break down features into tasks and define acceptance tests

43. Establish a cadence of delivering working tested features

44. Limit the amount of work in process

45. Regularly make and meet commitments

46. Continually adapt the planProduct Definition Planning & Coordination Continuous Improvement Delivery Practices Organizational Enablement 27

48. Rapid delivery of small features into the product

49. Continuous testing of the product

50. Clean code and fixing defects as we go

51. Deploy the solution either internally or externally on demandProduct Definition Planning & Coordination Continuous Improvement Delivery Practices Organizational Enablement 28

53. Teams that have a stable velocity

54. Retrospectives at all levels of the organization

55. Manage stakeholder expectations

56. Enable process improvement

57. Lead and manage changeProduct Definition Planning & Coordination Continuous Improvement Delivery Practices Organizational Enablement 29

59. Regular checkpoints to make sure everyone is on the same page

60. People work together to solve problems

61. People are empowered to make decisions

62. High levels of trust between coworkersValue Delivery Product Definition Planning & Coordination Continuous Improvement Delivery Practices Organizational Enablement 30

63. Focus less on implementing specific agile practices…

64. …and more on developing situationally specific strategies to solve business problems.

65. Competency Models… and our Competency Model

66. Product Definition Establish the Product Vision The 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 Roadmap The 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 Features The 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 deliver Estimate Size and Effort Does 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 Criteria Does 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 & Coordination Establish a 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 Breakdown Do 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 Cadence Does 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 Process Does 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 Commitments Does 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 Practices Define the Solution 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 Solution Do 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 Solution Is 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 Defects Are 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 Solution Is 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 Metrics and Reporting Does 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 Velocity Can 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 Retrospectives Does 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 Backlog Is 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 Improvement Is there a mechanism in place for quickly updating organizational processes in the face of impediments that might impact product delivery? 37

70. Organizational Enablement Team Based Delivery 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? Communication How 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? Collaboration Do 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? Empowerment Are 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? Trust Is 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 Competency Model at Different Frequencies

72. Strategic Release Iteration Daily Continuous Continuous

73. Strategic Release Iteration Daily Continuous Daily

74. Strategic Release Iteration Daily Continuous Iteration

75. Strategic Release Iteration Daily Continuous Release

76. Strategic Release Iteration Daily Continuous Strategic

77. Applying the Competency Model at Different Levels of Scale

78. Team

79. Multi-Team

80. Multi-Team

81. Multi-Team

82. Program Management

83. Portfolio Management

84. Enterprise Agility

85. How do the three dimensions Fit Together?

86. Frequency Competencies Scale

87. Create Situationally Specific Strategies for Each Competency, Frequency & Scale Combination

88. 125 Possible Combinations Competency: Continuous Integration Frequency: Daily Build Scale: Across Multiple Teams

89. 125 Possible Combinations Competency: Continuous Integration Frequency: Daily Scale: Across Multiple Teams Competency: Continuous Integration Frequency: Release Scale: At the Portfolio Level

90. 125 Possible Combinations Competency: Define the Product Frequency: Iteration Planning Scale: Single Team

91. 125 Possible Combinations Competency: Define the Product Frequency: Iteration Planning Scale: Single Team Competency: Define the Product Frequency: Strategic Planning Scale: Entire Enterprise

92. 125 Possible Combinations Competency: Explore Improvement Options Frequency: Iteration Planning Scale: Single Team

93. 125 Possible Combinations Competency: Explore Improvement Options Frequency: Daily Planning Scale: Single Team Competency: Explore Improvement Options Frequency: Release Planning Scale: Portfolio Management

94. Assessing the Organization and Getting Better Over Time

95. Assessment Results – at Start 63

96. Assessment Results – at Month One 64

97. Assessment Results – at Month Two 65

98. Leading Change by Incrementing and Iterating Through the Organization

99. Incremental and Iterative Delivery Incremental Various 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. Iterative Go 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 Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Phase I Cultural Factors Organizational Enablement 68

101. Value Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Product Definition Planning Coordination Continuous Improvement Delivery Practices Phase I Product Definition Continuous Improvement Planning Coordination Delivery Practices Organizational Enablement 69

102. Value Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Phase I Product Definition Continuous Improvement Planning Coordination Delivery Practices Organizational Enablement 70

103. Value Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Phase I Product Definition Continuous Improvement Planning Coordination Delivery Practices Organizational Enablement 71

104. Value Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Product Definition Planning Coordination Continuous Improvement Delivery Practices Phase II Product Definition Continuous Improvement Planning Coordination Delivery Practices Organizational Enablement 72

105. Value Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Product Definition Phase II Planning Coordination Continuous Improvement Delivery Practices Organizational Enablement 73

106. Value Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Product Definition Phase II Planning Coordination Continuous Improvement Delivery Practices Organizational Enablement 74

107. Value Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Continuous Improvement Product Definition Planning Coordination Continuous Improvement Delivery Practices Product Definition Planning Coordination Delivery Practices Phase III Organizational Enablement 75

108. Value Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Product Definition Planning Coordination Continuous Improvement Delivery Practices Phase III Organizational Enablement 76

109. Value Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Product Definition Planning Coordination Continuous Improvement Delivery Practices Phase III Organizational Enablement 77

110. Value Delivery Product Definition Planning Coordination Continuous Improvement Delivery Practices Product Definition Planning Coordination Continuous Improvement Delivery Practices Sustainability Organizational Enablement 78

111. Case Study #1 – Large Federal Lending Institution

112. Case Study: Situation Financial services firm 350 employees-70 in IT Software Development Support customer facing, internal systems and integrations to third-party applications Track record of late unpredictable delivery and high demand for production support – recent two year project took four years to partially complete

113. Case Study: Assessment Planning and coordination Low transparency Significant WIP and individual multi-tasking Granular detail required up-front Organizational Enablement Low trust and collaboration Delivery Practices Significant rework

114. Case Study: Plan Organizational Design Patterns 5 stable delivery teams w/ a support team Convert Configuration Management to DevOps Establish consolidated Value Management Convert PMO from day to day tasking to operate at the audit and governance level Road-map January: Stand up a delivery team January: Stand up a DevOpsteam February: Stand up the product support team March: Stand up remaining teams March: Migrate CRM-BA model to consolidated Value Management May: Integrate with the PMO

116. Got an exception from the existing governance process

117. Conducted Agile Team Training and TDD Training

119. Conducted training for all developers

120. Prepared all the remaining backlogs

122. Focus on establishing new policies and working agreements

123. Protect team capacity

125. Addressed internal policy constraints on automation

126. Moved to automation to rapidly provision environments

128. Support cross functional and cross organizational change

129. Run transformation as an enterprise project

130. Updating control objectives - coaching audit and compliance

131. Change management is criticalDev Ops Support Delivery Leadership Team Delivery Teams Plan Implement Follow up Backlog Prepare Competency Improvement Team

133. Balance demand against capacityDev Ops Support Delivery Leadership Delivery Teams Plan Implement Follow up Backlog Prepare Capability Improvement

135. Lessons Learned Get started on the automation earlier Change management must be intentional – managing resistance and organizational inertia Gained 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 Profile Based in the United States 125 employees located across 4 major cities in the US and Canada Growing through acquisition

138. Problem Statement Functional separation between Development and QA Ad-hoc waterfall based processes not able to scale Too many projects in queue Teams are not predictable Have not been able to realize their most strategic goal to integrate all the products into a single suite

139. Engagement Approach Conducted a competency assessment on the entire organization Collaborated on a top-down plan led by the VP of Engineering with full support from the CTO and CEO Started with the products in Atlanta and systematically moved through other geographies

140. Engagement Approach – Phase I Team Level and Multi-Team Adoption Focused on Product Definition, Planning & Coordination, and Organizational Enablement Competencies first Mostly at the Daily, Iteration, and Release levels

141. Engagement Approach – Phase 2 Skipped the Program Management layer and went straight to Portfolio & Strategy Focusing on Product Definition, Planning & Coordination, and Organizational Enablement Competencies Began addressing Delivery Practices and Continuous Improvement Mostly at the Daily, Iteration, and Release levels Trained Marketing, Sales, and Senior Leadership

142. Engagement Approach – Phase 3 Filled in the Portfolio Level Still focusing on Product Definition, Planning & Coordination, and Organizational Enablement Competencies Began addressing Delivery Practices and Continuous Improvement Started addressing some of the strategic planning issues

143. Team

144. Multi-Team

145. Multi-Team

146. Multi-Team

147. Portfolio Management

148. Enterprise Agility

149. Program Management

150. Story Backlog In Process Task Done Task Backlog Story Backlog Tier 1 - Scrum

151. Construction Transition Elaboration Inception Tier 3 - Kanban Story Backlog In Process Task Done Task Backlog Story Backlog Tier 1 - Scrum

152. Construction Transition Elaboration Inception Tier 3 - Kanban Deploy Build Test Design Analysis Tier 2 - Kanban Story Backlog In Process Task Done Task Backlog Story Backlog Tier 1 - Scrum

153. Lessons Learned Having buy-in and support up to the CEO makes things a lot easier The sequence of events is not always intuitive Sometimes it is better to rough in something and come back to it later than try to get it perfect the first time Speed can be limited by individual resistance and the rate of organizational learning

154. Case Study #3 – Financial Service Company

155. Case Study: Situation Financial Software Services Provider 19,000 employees-1,000 in target division Provider of technology solutions to the financial world Very successful but long release cycles and low release predictability impact future strategy

156. Case Study: Assessment Product Definition Challenges decomposing road-map into clearly defined features and stories Acceptance criteria evolve after development Delivery Practices Quality was not a foundational practice Code was developed in large chunks with long feedback cycles Planning and coordination Predictability is difficult due to support demand on teams Challenges making and keeping commitments Too much WIP – the entire release is active simultaneously Organizational Enablement Development teams formed around technology layers and QA and Development are not aligned in the same sprints Supporting team members (architects, analysts) can be spread across multiple features and services

157. Case Study: Plan Organizational Design Patterns Align Delivery Teams with the Product Architecture Align QA, BA, and Architect with the Delivery Teams Establish clear PO for each feature in Value Management and clarify feature elaboration Limit WIP and make work flow through the organization Road-map Get cross technology development teams created and working from a single backlog Establish Competency Improvement Team Get 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 elaboration Align the product road-map with the business strategy

159. Conduct training for all developers

160. Prepare the backlogs and get teams to flowDelivery Teams

162. Identified the next most important area and enlisted change management support for the transformation Delivery Teams Plan Implement Follow up Backlog Prepare Competency Improvement Team

164. Train on the flow of work through the teams

166. Align PMO approach with Feature level deliveryProduce Make Ready Initiate UAT Value Management Delivery Teams Plan Implement Follow up Backlog Prepare Competency Improvement Team

168. Lessons Learned Aligning development into 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 twice The guiding coalition and a focus on change management is critical to the transformation The production support demands from technical debt and the historic approach makes predictability very difficult to achieve Moving PMO attention to the Feature Level made transitioning the governance model easier

169. Case Study #4 – Energy Management Company

170. Company Profile European company with offices across the United States Thousands of employees worldwide, several hundred in the US Significant amount of product development work done offshore in India

171. Problem Statement Adopted Scrum several years ago, not getting the expected business benefit Releases are constantly delivered with significantly less features than planned and are often behind schedule Hardware and firmware delivery out of sync with the management console software Pretty significant trust issues between senior leaders and their direct reports.

172. Engagement Approach Conducted a competency assessment on the entire division Collaborated on a top-down plan led by the Director of Quality & Process with full support from the CTO Started with the teams in Atlanta and are currently moving through other geographies

173. Engagement Approach – Phase I Agile teams were in place, but did not stay together over time. First step we formed persistent teams Requirements 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 first Exclusively at the Release level to start

174. Engagement Approach – Phase 2 Continued to ignore the teams and went for Portfolio & Strategy Established an Agile Release Train Still focusing on Product Definition, Planning & Coordination, and Organizational Enablement Competencies Uncovered significant trust issues between senior level managers within engineering and product management

175. Engagement Approach – Phase 3 Started addressing performance of the teams Started 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 Operations Tighter integration of hardware and firmware

176. Team

177. Multi-Team

178. Multi-Team

179. Multi-Team

180. Program Management

181. Program Management

182. Portfolio & Team

183. Program Management

184. Multi-Team

185. Enterprise Agility?

186. Construction Transition Elaboration Inception Tier 3 - Kanban Deploy Build Test Design Analysis Tier 2 - Kanban

187. Story Backlog In Process Task Done Task Backlog Story Backlog Tier 1 - Scrum

188. Construction Transition Elaboration Inception Tier 3 - Kanban Deploy Build Test Design Analysis Tier 2 - Kanban Story Backlog In Process Task Done Task Backlog Story Backlog Tier 1 - Scrum

189. Lessons Learned Engineering only change initiatives are likely to struggle Effectively integrating with non-Agile work streams can make or break a transformation effort Understanding the flow of value across the entire organization is critical Starting with teams isn’t always the most strategic approach

190. Key Takeaways Introducing Agile at Scale is best done incrementally and iteratively To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization Organizational 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 Agile at Scale is best done incrementally and iteratively To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization Organizational 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 Agile at Scale is best done incrementally and iteratively To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization Organizational 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 Agile at Scale is best done incrementally and iteratively To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization Organizational agility is not about adopting a specific set of practicesbut developing strategies to address competencies at different frequencies and different scales

194. Mike CottmeyerLeadingAgilemike@leadingagile.com 1.404.312.1471www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer Dennis StevensSynaptusdennis.stevens@synaptus.com 770.851.8025www.synaptus.comtwitter.com/dennisstevens