Enterprise Agile Transformation Strategies

90,284 views
90,094 views

Published on

Agile2012 Version

Published in: Technology, Business
11 Comments
74 Likes
Statistics
Notes
No Downloads
Views
Total views
90,284
On SlideShare
0
From Embeds
0
Number of Embeds
31,687
Actions
Shares
0
Downloads
1,710
Comments
11
Likes
74
Embeds 0
No embeds

No notes for slide
  • \n
  • A little about me... my background.. why Agile is important\nStudied computer science... spent first 10 years doing infrastructure\nInfrastructure PM to software PM... close the loop\nStarting seeing a lot of organizational dysfunction... things that just didn’t make sense\nStarted consulting with V1... saw similar patterns repeated across the world\nLeft V1 to start developing my approach to transformation and help companies make lasting sustainable change\n\n\n
  • I want to explore a little the problem that I’m seeing. People get agile... to a large extent agile has gone mainstream. When I’m doing business development with a client, I don’t usually have to explain agile or convince people that agile is the way to do things. Often what I’m selling against is an oversimplification of agile... or a belief that the stuff we are doing with team level Scrum is sufficient for Agile at scale or agile in the enterprise\n
  • \n
  • \n
  • Examples:\n\n\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Talk about scales\n1 bad 5 good\n1 non-existent 5 sustainable\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Better Estimation & Release Planning\n
  • Better Estimation & Release Planning\n
  • Better Estimation & Release Planning\n
  • Better Estimation & Release Planning\n
  • Better Estimation & Release Planning\n
  • Better Estimation & Release Planning\n
  • Better Estimation & Release Planning\n
  • Better Estimation & Release Planning\n
  • Better Estimation & Release Planning\n
  • Better Estimation & Release Planning\n
  • Better Estimation & Release Planning\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Mobile Labs\n
  • Lancope\n\n
  • Surescripts & nCircle\n\n
  • Verint\n\n
  • CheckFree/Fiserv\n
  • \n
  • \n
  • A little about me... my background.. why Agile is important\nStudied computer science... spent first 10 years doing infrastructure\nInfrastructure PM to software PM... close the loop\nStarting seeing a lot of organizational dysfunction... things that just didn’t make sense\nStarted consulting with V1... saw similar patterns repeated across the world\nLeft V1 to start developing my approach to transformation and help companies make lasting sustainable change\n\n\n
  • Enterprise Agile Transformation Strategies

    1. 1. Exploring Enterprise AgileTransformation StrategiesMike Cottmeyer, Enterprise Agile CoachLeadingAgile, LLC
    2. 2. Mike Cottmeyermike@leadingagile.com404.312.1471www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer
    3. 3. The Problem...
    4. 4. The Problem... Having lots of agile teams in an enterprise isn’t enterprise agility • Sometimes organizations fall into the trap of thinking that having agile teams means they have an agile organization • Enterprise agility is when all the parts of the organization work together to create Agile outcomes • The entire delivery capability of the enterprise has to be focused on agile principles and execution
    5. 5. The Problem... Focusing only at the team level can result in local optima within your organization • Sometimes a team can perform well at Scrum, but the business doesn’t see any incremental value from their investment • Sometimes a high-performance team can disrupt other functions in the organization if the upstream and downstream processes are not able to work at the same pace
    6. 6. The Problem... Team level Agile practices are different from Agile practices at scale • The practices we put in place at the team level often don’t work when we apply them in larger organizations • Practices have to adapted at scale to accommodate more diverse groups of stakeholders and more complicated value streams
    7. 7. The Problem... Agile at scale requires a broader set of tools and techniques • Scrum and XP at the team level • Kanban and Lean at the program and portfolio level • RUP and Traditional Project Management at the Enterprise
    8. 8. We are just now starting toput all the pieces together...
    9. 9. The Solution...
    10. 10. The Solution... Part One First... we do have to get team level agile right. We are going to talk about some of the things you can do that will lead to successful team-level Agile transformations. • The fundamentals behind why Agile works • Common challenges that cause Agile to fail • What does it look like when things are really going well? • What is different about an enterprise-level Agile transformation?
    11. 11. The Solution... Part Two Next we will explore a safe, pragmatic, iterative and incremental framework for transforming any sized organization... • Define the organizational competencies required at all levels of the enterprise • How to adapt agile competencies for scale • How to adapt agile competencies for cadence
    12. 12. The Solution... Part Three We’ll discuss the three major areas you need to pay attention to in order to execute a safe and pragmatic enterprise Agile transformation... • Establishing an agile org structure • Introducing disciplined Agile practices • Intentionally addressing people and culture
    13. 13. The Solution... Part Four Finally, as we begin to wrap-up the talk, we’ll explore a few things that will help you put all of this together... • Overview of the model end-to-end • If we have time... case studies
    14. 14. The Solution... Part OneHow Does Agile Workand Why Does it Fail?
    15. 15. What Makes Agile Work?
    16. 16. What Makes Agile Work? Teams stay together and are highly engaged • Agile practices are built around cross- functional teams that have everything necessary to deliver an increment of value to the organization • Teams that stay together over time tend to be more productive than teams that are constantly forming and reforming • Empowered self-directed teams are able to own the solution and creatively solve
    17. 17. What Makes Agile Work? Teams are focused on a queue of projects or product enhancements • Rather than forming teams to deliver projects, agile methods leave teams together and funnel project through teams • The project list is basically a prioritized backlog of work that a team is responsible for delivering
    18. 18. What Makes Agile Work? Minimize dependencies and strive for loose coupling between teams • The more coupling we have between teams, the more difficult it is to change direction when we learn something new about the emerging product • Teams that have external dependencies are not able to make and meet commitments because they don’t have everything necessary to own the commitment
    19. 19. What Makes Agile Work? Fully engaged business partners • Many organizations are guilty of throwing ill- defined requirements over to the delivery teams, constantly changing direction through the life of the project, and holding teams accountable for on-time delivery • Agile is geared for change, but requires close collaboration between stakeholders and teams to make real-time tradeoffs as the product is in development
    20. 20. What Makes Agile Work? Attention to getting done and completing work before new work is started • Delivering an increment of working, tested, potentially shippable software on regular time intervals assures that we can measure progress against real, measurable product outcomes
    21. 21. What Makes Agile Work? Technical excellence and continuous attention to product quality • The underlying health of the system is a critical success factor for running successful agile projects • Defects and technical debt impact product delivery in unpredictable ways making it nearly impossible to reliably make and meet commitments
    22. 22. What Makes Agile Fail?
    23. 23. What Makes Agile Fail? Agile team is a local optimization and out of alignment with the rest of the business • Pilot teams are formed and given everything they need to be successful at the expense of the rest of the delivery organization • Teams can deliver product faster than the organization can consume it • Teams starve the requirements queue because Strategy and Product Management can’t keep up
    24. 24. What Makes Agile Fail? Project driven organizations or uneven investment across product lines • Very difficult to keep cross-functional teams together over time because the investment mix is constantly changing • Organizations tend to want to matrix people across multiple teams at the same time
    25. 25. What Makes Agile Fail? Value is either too broadly defined or too narrowly defined • Overly vague requirements lead the development team to fill in the gaps based in their own knowledge and experience • Overly specified requirements lead to an activity based mentality rather than a value based mentality
    26. 26. What Makes Agile Fail? Organizational structures and product architectures work against establishing cross functional teams • Matrix organizations and functional silos make it very challenging to create high-performing agile teams • Tightly coupled legacy architectures make it difficult to organize teams around feature groups or components within the solution framework
    27. 27. What Makes Agile Fail? Overly political cultures and lack of trust • Command and control leadership • Micromanagement • Disempowering language
    28. 28. What Makes Agile Fail? Inability to balance capacity and demand • Invalid and inaccurate estimates • Inability to make and meet commitments • More work than the teams can possibly deliver in the timeframes expected
    29. 29. What Makes Agile Fail? Looking at agile as a process overlay rather than a transformative event in your organization • Agile is just something that the developers do • Not recognizing the broad organizational change necessary to make an agile transformation sustainable
    30. 30. A Well Formed Agile Organization
    31. 31. A Well Formed Agile Organization Cross functional teams aligned directly to solve business problems • Products • Features • Programs • Components • Services • Business Capabilities
    32. 32. A Well Formed Agile Organization Clear voice of the business and a willingness to make tradeoffs to meet time and cost constraints • Highly engaged product ownership • Willingness to deal with reality • Focus on maximizing value and reducing risk
    33. 33. A Well Formed Agile Organization Individual empowerment and shared accountability for outcomes • Establish boundaries and ownership but empower within those boundaries • Teams own outcomes not activities
    34. 34. A Well Formed Agile Organization Disciplined attention to technical excellence and product quality • Technical excellence stabilizes the requirements delivery function
    35. 35. A Well Formed Agile Organization Predictable, accountable, able to consistently make and meet commitments • Teams have the ability to consistently do what they say they are going to do • Predictable agile teams are the foundational element of a predictable agile enterprise
    36. 36. Reinventing Agile Situationally specific strategies at scale to solve these problems and maintain business agility • How do team level competencies need to be adapted to take into consideration issues of scale and the different planning horizons required in larger enterprises • How do you build the necessary organization, introduce new practices, and start shifting the culture in a way that leads to sustainable organizational change
    37. 37. The Solution... Part TwoCompetencies,Frequency, and Scale
    38. 38. Agile Competencies• Product Definition• Planning & Coordination• Delivery Practices• Continuous Improvement• Organizational Enablement
    39. 39. Agile Competencies• Product Definition• Planning & Coordination• Delivery Practices• Continuous Improvement• Organizational Enablement
    40. 40. Agile Competencies• Product Definition• Planning & Coordination• Delivery Practices• Continuous Improvement• Organizational Enablement
    41. 41. Agile Competencies• Product Definition• Planning & Coordination• Delivery Practices• Continuous Improvement• Organizational Enablement
    42. 42. Agile Competencies• Product Definition• Planning & Coordination• Delivery Practices• Continuous Improvement• Organizational Enablement
    43. 43. Agile Competencies• Product Definition• Planning & Coordination• Delivery Practices• Continuous Improvement• Organizational Enablement
    44. 44. Product Definition• Establish the product vision• Define the product roadmap• Decompose features• Estimate size and effort• Define acceptance criteria
    45. 45. Product Definition• Establish the product vision• Define the product roadmap• Decompose features• Estimate size and effort• Define acceptance criteria
    46. 46. Product Definition• Establish the product vision• Define the product roadmap• Decompose features• Estimate size and effort• Define acceptance criteria
    47. 47. Product Definition• Establish the product vision• Define the product roadmap• Decompose features• Estimate size and effort• Define acceptance criteria
    48. 48. Product Definition• Establish the product vision• Define the product roadmap• Decompose features• Estimate size and effort• Define acceptance criteria
    49. 49. Product Definition• Establish the product vision• Define the product roadmap• Decompose features• Estimate size and effort• Define acceptance criteria
    50. 50. Delivery Practices• Define the solution• Build the solution• Test the solution• Establish product quality• Deploy the solution
    51. 51. Delivery Practices• Define the solution• Build the solution• Test the solution• Establish product quality• Deploy the solution
    52. 52. Delivery Practices• Define the solution• Build the solution• Test the solution• Establish product quality• Deploy the solution
    53. 53. Delivery Practices• Define the solution• Build the solution• Test the solution• Establish product quality• Deploy the solution
    54. 54. Delivery Practices• Define the solution• Build the solution• Test the solution• Establish product quality• Deploy the solution
    55. 55. Delivery Practices• Define the solution• Build the solution• Test the solution• Establish product quality• Deploy the solution
    56. 56. Planning & Coordination• Establish a planning cadence• Perform activity breakdown• Establish a delivery cadence• Limit work in process• Make and meet commitments
    57. 57. Planning & Coordination• Establish a planning cadence• Perform activity breakdown• Establish a delivery cadence• Limit work in process• Make and meet commitments
    58. 58. Planning & Coordination• Establish a planning cadence• Perform activity breakdown• Establish a delivery cadence• Limit work in process• Make and meet commitments
    59. 59. Planning & Coordination• Establish a planning cadence• Perform activity breakdown• Establish a delivery cadence• Limit work in process• Make and meet commitments
    60. 60. Planning & Coordination• Establish a planning cadence• Perform activity breakdown• Establish a delivery cadence• Limit work in process• Make and meet commitments
    61. 61. Planning & Coordination• Establish a planning cadence• Perform activity breakdown• Establish a delivery cadence• Limit work in process• Make and meet commitments
    62. 62. Continuous Improvement• Metrics and reporting• Establish stable velocity• Conduct retrospectives• Update the backlog• Enable process improvement
    63. 63. Continuous Improvement• Metrics and reporting• Establish stable velocity• Conduct retrospectives• Update the backlog• Enable process improvement
    64. 64. Continuous Improvement• Metrics and reporting• Establish stable velocity• Conduct retrospectives• Update the backlog• Enable process improvement
    65. 65. Continuous Improvement• Metrics and reporting• Establish stable velocity• Conduct retrospectives• Update the backlog• Enable process improvement
    66. 66. Continuous Improvement• Metrics and reporting• Establish stable velocity• Conduct retrospectives• Update the backlog• Enable process improvement
    67. 67. Continuous Improvement• Metrics and reporting• Establish stable velocity• Conduct retrospectives• Update the backlog• Enable process improvement
    68. 68. Organizational Enablement• Establish teams• Effective communication• Effective collaboration• Empowerment• Trust
    69. 69. Organizational Enablement• Establish teams• Effective communication• Effective collaboration• Empowerment• Trust
    70. 70. Organizational Enablement• Establish teams• Effective communication• Effective collaboration• Empowerment• Trust
    71. 71. Organizational Enablement• Establish teams• Effective communication• Effective collaboration• Empowerment• Trust
    72. 72. Organizational Enablement• Establish teams• Effective communication• Effective collaboration• Empowerment• Trust
    73. 73. Organizational Enablement• Establish teams• Effective communication• Effective collaboration• Empowerment• Trust
    74. 74. Visualizing Improvement
    75. 75. Visualizing Improvement
    76. 76. Visualizing Improvement
    77. 77. Competencies at Scale• Team• Multi-Team• Program• Portfolio• Enterprise
    78. 78. Team Agility Scrum Team
    79. 79. Multi-Team Agility Scrum Scrum Team Team
    80. 80. Multi-Team Agility Scrum Scrum Scrum Team Team Team
    81. 81. Multi-Team Agility Scrum Scrum Scrum Scrum Team Team Team Team
    82. 82. Program Agility Product Team Scrum Scrum Scrum Scrum Team Team Team Team
    83. 83. Program Agility Product Product Team Team Scrum Scrum Scrum Scrum Team Team Team Team
    84. 84. Portfolio Agility Portfolio Team Product Product Team Team Scrum Scrum Scrum Scrum Team Team Team Team
    85. 85. Enterprise Agility Strategy Portfolio Team Team Product Product Team Team Scrum Scrum Scrum Scrum Team Team Team Team
    86. 86. Enterprise Agility Strategy Portfolio Support Team Team Team Product Product Team Team Scrum Scrum Scrum Scrum Team Team Team Team
    87. 87. Competencies in Time• Continuous• Daily• Strategic Iteration• Release Release• Strategic Iteration Daily Continuous
    88. 88. Competencies in Time• Continuous• Daily• Iteration Strategic• Release Release• Strategic Iteration Daily Continuous
    89. 89. Competencies in Time• Continuous• Daily• Iteration Strategic• Release Release• Strategic Iteration Daily Continuous
    90. 90. Competencies in Time• Continuous• Daily• Iteration Strategic• Release Release• Strategic Iteration Daily Continuous
    91. 91. Competencies in Time• Continuous• Daily• Iteration Strategic• Release Release• Strategic Iteration Daily Continuous
    92. 92. Competencies in Time• Continuous• Daily• Iteration Strategic• Release Release• Strategic Iteration Daily Continuous
    93. 93. The Solution... Part ThreeThe Agile Adoption andTransformation Lifecycle
    94. 94. Adoption vs. Transformation First... we want to untangle two words that sometimes can be used interchangeably • Agile Adoption is about what you do... practices, tools, techniques, ceremonies, and habits • Agile Transformation is about who you are... reflected in both the structure of the organization and who you are as people Long term results require both adoption and transformation to be successful
    95. 95. Adoption vs. Transformation Second... we want clearly articulate the three major focus areas that must be addressed interdependently • Organizational Structure is about how you create teams and how you organize them • Agile Practice is about the methods and tools you choose to introduce • People and Culture is about changing hearts and minds of the individuals in the organization All three aspects are essential to sustain agility
    96. 96. Incremental vs. Iterative Third... we want introduce the notion that introducing Agile is an iterative and incremental process for you organization • Iterative is when parts of the system are developed at different times and integrated as they are completed • Incremental is when you go back over parts of the system making improvements The strategy is to increment the organization by building teams and iterate the teams over time
    97. 97. Incremental vs. Iterative Courtesy of Jeff Patton
    98. 98. Incremental vs. Iterative Incremental Courtesy of Jeff Patton
    99. 99. Incremental vs. Iterative Incremental Iterative Courtesy of Jeff Patton
    100. 100. Adoption/Transformation Cycle Incrementing and Iterating the Agile Enterprise • Organiza(onal+ Change physical Transforma(on+ structures and introduce teams • Teach people new Personal+ Adopt++ practices and ways Transforma(on+ Prac(ces+ of working • Help people internalize the value system
    101. 101. Adoption/Transformation Cycle Organizational Transformation • Establish top to Organiza(onal+ bottom structure Transforma(on+ and roadmap • Incrementally make changes and Personal+ Adopt++ establish teams Transforma(on+ Prac(ces+ • Define policies and working agreements between teams
    102. 102. Adoption/Transformation Cycle Adopting Practices •Sprint planning, daily stand-ups, Organiza(onal+ product reviews, Transforma(on+ and retrospectives •Identify and train a Product Owner Personal+ Adopt++ and ScrumMaster Transforma(on+ Prac(ces+ •Teach TDD, CI, Story Maps, and MMF
    103. 103. Adoption/Transformation Cycle Personal Transformation • Develop an ability Organiza(onal+ to deal with Transforma(on+ uncertainty and adaptation • Help people work Personal+ Adopt++ toward common Transforma(on+ Prac(ces+ organizational goals • Help foster empathy, trust, and teamwork
    104. 104. 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 agile
    105. 105. 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 agile
    106. 106. 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 agile
    107. 107. 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 agile
    108. 108. The Solution... Part FourExploring theIntegrated Framework
    109. 109. Phase I - Structure Scrum Team
    110. 110. Phase I - Structure Scrum Scrum Team Team
    111. 111. Phase I - Structure Product Team Scrum Scrum Team Team
    112. 112. Phase 2 - Structure Product Team Scrum Scrum Scrum Team Team Team
    113. 113. Phase 2 - Structure Product Team Scrum Scrum Scrum Scrum Team Team Team Team
    114. 114. Phase 2 - Structure Product Product Team Team Scrum Scrum Scrum Scrum Team Team Team Team
    115. 115. Phase 3 - Structure Portfolio Team Product Product Team Team Scrum Scrum Scrum Scrum Team Team Team Team
    116. 116. Phase 3 - StructureStrategy Portfolio Team Team Product Product Team Team Scrum Scrum Scrum Scrum Team Team Team Team
    117. 117. Phase 3 - StructureStrategy Portfolio Support Team Team Product Product Team Team Scrum Scrum Scrum Scrum Team Team Team Team
    118. 118. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase I Product Planning Delivery Continuous Definition Coordination Practices Improvement OrganizationalFactors Cultural Enablement116
    119. 119. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase I Product Planning Delivery Continuous Definition Coordination Practices Improvement Organizational Enablement117
    120. 120. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase I Product Planning Delivery Continuous Definition Coordination Practices Improvement Organizational Enablement118
    121. 121. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase I Product Planning Delivery Continuous Definition Coordination Practices Improvement Organizational Enablement119
    122. 122. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase 2 Product Planning Delivery Continuous Definition Coordination Practices Improvement Organizational Enablement120
    123. 123. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase 2 Product Planning Delivery Continuous Definition Coordination Practices Improvement Organizational Enablement121
    124. 124. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase 2 Product Planning Delivery Continuous Definition Coordination Practices Improvement Organizational Enablement122
    125. 125. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase 3 Product Planning Delivery Continuous Definition Coordination Practices Improvement Organizational Enablement123
    126. 126. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase 3 Product Planning Delivery Continuous Definition Coordination Practices Improvement Organizational Enablement124
    127. 127. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase 3 Product Planning Delivery Continuous Definition Coordination Practices Improvement Organizational Enablement125
    128. 128. Organizationa l Transformatio Value Delivery Personal Adopt Transformatio Practices n Phase 3 Product Planning Delivery Continuous Definition Coordination Practices Improvement Organizational Enablement126
    129. 129. Phase I - Cadence Strategic Release Iteration Daily Continuous
    130. 130. Phase I - Cadence Strategic Release Iteration Daily Continuous
    131. 131. Phase I - Cadence Strategic Release Iteration Daily Continuous
    132. 132. Phase I - Cadence Strategic Release Iteration Daily Continuous
    133. 133. Phase I - Cadence Strategic Release Iteration Daily Continuous
    134. 134. Phase 2 - Cadence Strategic Release Iteration Daily Continuous
    135. 135. Phase 2 - Cadence Strategic Release Iteration Daily Continuous
    136. 136. Phase 2 - Cadence Strategic Release Iteration Daily Continuous
    137. 137. Phase 2 - Cadence Strategic Release Iteration Daily Continuous
    138. 138. Phase 3 - Cadence Strategic Release Iteration Daily Continuous
    139. 139. A Few Scenarios
    140. 140. Single Team/Single Product Sub 25 person product company and a start-up • Started with team level practices • Lots of attention early to team culture • Began engaging senior leaders on strategy and portfolio management • Currently integrating marketing, sales, and support
    141. 141. Multi-Team/Single Product Sub-100 person product company. 10 years old and privately owned. • Program level first.. established a PO team • 3 tightly integrated Scrum teams • Defined the portfolio governance layer • Established the relationship between strategy and support • Modeled the overall value stream and wrapped the Scrum process in a two-tiered Kanban
    142. 142. Multi-Team/Multi-Product Sub-300 person organization. 100 person development organization. 8 Scrum teams. • Big-bang team-level adoption • Teams aligned by products • Product ownership by product • Program and portfolio level views established • Limiting projects in progress • Solid release planning • Integration with upstream and downstream
    143. 143. Multi-Team/Multi-Product Large multi-national organization. Scope is a 500 person development organization with 55 Scrum teams. • Started with a basic view of the portfolio layer • Portfolio level value stream mapping, RACI • Built out the program management layer with PO teams to develop a requirements management capability • Program level value stream mapping, RACI, introduced agile tooling • Introduced Scrum at the team level
    144. 144. Products of Products Large multi-national company. Geographically dispersed. Products of products. • Scrum teams by product/component • Product Owner teams established • Portfolio level governance model • Lean/TOC planning model • Integration with a traditional PMO for metrics and reporting
    145. 145. Guitar Mummies Source: http://www2.gibson.com/news-lifestyle/features/en-us/219-gibson-custom.aspx
    146. 146. Agile Program andPortfolio Management9:00 AM | Thursday | Austin 1-3 | Mike Cottmeyer
    147. 147. Mike Cottmeyermike@leadingagile.com404.312.1471www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer Slides at www.leadingagile.com

    ×