Scaling Agile Past the Team
•Download as PPTX, PDF•
6 likes•24,528 views
This is the talk I am doing at the 2010 SQE Better Software/Agile Development Practices Conference in Vegas this week. Not much new, but this is a combination of several ideas from many of my existing presentations.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Scaling Agile Past the Team
Similar to Scaling Agile Past the Team (20)
More from Mike Cottmeyer
More from Mike Cottmeyer (18)
Recently uploaded
Recently uploaded (20)
Scaling Agile Past the Team
- 1. Scaling Agile Past the Team Presented by: Mike Cottmeyer Pillar Technology Group
- 2. “Pragmatic agile adoption & scaling patterns for large complex organizations that aren’t well suited for for a full blown Scrum transformation”
- 3. mike cottmeyervp delivery, senior agile coachmcottmeyer@pillartechnology.com404.312.1471www.pillartechnology.comwww.leadingagile.com
- 4. Scaling Agile Explore common guidance for an enterprise agile transformation What happens when that guidance hits real life organizations and products The goal of enterprise agility when transformation isn’t possible Patterns and tools for pragmatically scaling agile to the enterprise
- 5. Scaling Agile Explore common guidance for an enterprise agile transformation What happens when that guidance hits real life organizations and products The goal of enterprise agility when transformation isn’t possible Patterns and tools for pragmatically scaling agile to the enterprise
- 6. Scaling Agile Explore common guidance for an enterprise agile transformation What happens when that guidancehits real life organizations and products The goal of enterprise agility when transformation isn’t possible Patterns and tools for pragmatically scaling agile to the enterprise
- 7. Scaling Agile Explore common guidance for an enterprise agile transformation What happens when that guidance hits real life organizations and products The goal of enterprise agility when transformation isn’t possible Patterns and tools for pragmatically scaling agile to the enterprise
- 8. Scaling Agile Explore common guidance for an enterprise agile transformation What happens when that guidance hits real life organizations and products The goal of enterprise agility when transformation isn’t possible Patterns and tools for pragmatically scaling agile to the enterprise
- 9. Why Teams?
- 10. Team
- 11. Developers
- 14. Analyst CSM Testers Developers
- 15. Product Owner Analyst CSM Testers Developers
- 16. Team
- 17. Team Features
- 18. Team Backlog
- 20. Team Predictable Velocity Backlog
- 21. Team Predictable Trust Velocity Backlog
- 22. User Story Screen User Story Team User Story Report User Story User Story Database User Story User Story
- 23. User Story Screen User Story Team User Story Report User Story User Story Database User Story User Story
- 24. Teams of Teams
- 25. Team 1
- 26. Team 2 Team 1
- 27. Team 3 Team 2 Team 1
- 28. Team 1 Team 2 Team 3
- 29. Team 1 Team 2 Team 3 Team 5 Team 4 Team 6 Scrum of Scrums
- 30. Team 1 Team 2 Team 3 Team 5 Team 4 Team 6 Scrum of Scrums Encapsulate Teams
- 31. Lessons from Scaling Agile Cross-functional features teams that can operate independently of each other under the guidance of a single product owner Quantifiable business value can be created by each team at the end of a single sprint.
- 32. Lessons from Scaling Agile Cross-functional features teams that can operate independently of each other under the guidance of a single product owner Quantifiable business value can be created by each team at the end of a single sprint.
- 33. Lessons from Scaling Agile Cross-functional features teams that can operate independently of each other under the guidance of a single product owner Quantifiable business value can be created by each team at the end of a single sprint.
- 35. The Transformation Problem Functional Silos Over specialization Complex products Cultural challenges
- 36. The Transformation Problem Functional Silos Over specialization Complex products Cultural challenges
- 37. The Transformation Problem Functional Silos Over specialization Complex products Cultural challenges
- 38. The Transformation Problem Functional Silos Over specialization Complex products Cultural challenges
- 39. The Transformation Problem Functional Silos Over specialization Complex products Cultural challenges
- 40. Functional Silos
- 41. Dev.
- 42. QA Dev.
- 43. QA BA Dev.
- 44. QA BA Dev. PM
- 45. QA BA Dev. PM PO
- 46. QA BA Dev. PM PO The Team
- 48. UI
- 49. API UI
- 50. API DBA UI
- 51. API DBA UI RPT
- 52. API DBA UI RPT EDI
- 53. API DBA UI RPT EDI The Team
- 54. Complex Products
- 56. Biller Transactions Fin Inst. Transactions Credit Card Payments ACH Payments Fraud/Risk Identity/ Enrollment SAS SAP Corporate Billing Web IVR Payments Risk Business Intelligence Corporate Financials Partner Communication Bus Intel/ Reporting
- 57. Biller Transactions Fin Inst. Transactions Credit Card Payments ACH Payments Fraud/Risk Identity/ Enrollment SAS SAP Corporate Billing Web IVR Payments Risk Business Intelligence Corporate Financials Partner Communication Bus Intel/ Reporting
- 58. Biller Transactions Fin Inst. Transactions Credit Card Payments ACH Payments Fraud/Risk Identity/ Enrollment SAS SAP Corporate Billing Web IVR Payments Risk Business Intelligence Corporate Financials Partner Communication Bus Intel/ Reporting
- 59. Biller Transactions Fin Inst. Transactions Credit Card Payments ACH Payments Fraud/Risk Identity/ Enrollment SAS SAP Corporate Billing Web IVR Payments Risk Business Intelligence Corporate Financials Partner Communication Bus Intel/ Reporting
- 60. Biller Transactions Fin Inst. Transactions Credit Card Payments ACH Payments Fraud/Risk Identity/ Enrollment SAS SAP Corporate Billing Web IVR Payments Risk Business Intelligence Corporate Financials Partner Communication Bus Intel/ Reporting
- 61. Biller Transactions Fin Inst. Transactions Credit Card Payments ACH Payments Fraud/Risk Identity/ Enrollment SAS SAP Corporate Billing Web IVR Payments Risk Business Intelligence Corporate Financials Partner Communication Bus Intel/ Reporting
- 63. Credit Card Payments ACH Payments Payments
- 64. Managers Credit Card Payments ACH Payments Payments
- 65. Managers Credit Card Payments ACH Payments Payments Accountability
- 66. Managers Authority Credit Card Payments ACH Payments Payments Accountability
- 67. Managers Authority Credit Card Payments ACH Payments Payments People Accountability
- 68. Managers Authority Credit Card Payments ACH Payments Power Payments People Accountability
- 69. Managers Authority Credit Card Payments ACH Payments Control Power Payments People Accountability
- 70. The Transformation Problem Teams are the building blocks of agile organizations, but a single team might not be able to deliver an increment of business value. Technology and domain expertise can limit the the degree to which a team can have all the skills necessary to deliver working software
- 71. The Transformation Problem Teams are the building blocks of agile organizations, but a single team might not be able to deliver an increment of business value. Technology and domain expertise can limit the the degree to which a team can have all the skills necessary to deliver working software
- 72. The Transformation Problem Teams are the building blocks of agile organizations, but a single team might not be able to deliver an increment of business value. Technology and domain expertise can limit the the degree to which a team can have all the skills necessary to deliver working software
- 73. The Transformation Problem Technology constraints can initiallylimit the degree to which you can make shared code ownership a reality Breaking down all silos and reporting relationships can make ownership and accountability issues a nightmare through the transition
- 74. The Transformation Problem Technology constraints can initially limit the degree to which you can make shared code ownership a reality Breaking down all silos and reporting relationships can make ownership and accountability issues a nightmare through the transition
- 75. The Transformation Problem Technology constraints can initiallylimit the degree to which you can make shared code ownership a reality Breaking down all silos and reporting relationships can make ownership and accountability issues a nightmare through the transition
- 77. How Good?
- 78. How Fast?
- 79. What Are You Willing to Give Up to Get there?
- 80. Incremental Agile Adoption Start with the idea that you are going to organize around capabilities Build agile teams around those capabilities that are most constrained from a delivery perspective Spread agile systematically based on business need Learn how to coordinate teams
- 81. Incremental Agile Adoption Start with the idea that you are going to organize around capabilities Build agile teams around those capabilities that are most constrained from a delivery perspective Spread agile systematically based on business need Learn how to coordinate teams
- 82. Incremental Agile Adoption Start with the idea that you are going to organize around capabilities Build agile teams around those capabilities that are most constrained from a delivery perspective Spread agile systematically based on business need Learn how to coordinate teams
- 83. Incremental Agile Adoption Start with the idea that you are going to organize around capabilities Build agile teams around those capabilities that are most constrained from a delivery perspective Spread agile systematically based on business need Learn how to coordinate teams
- 84. Incremental Agile Adoption Start with the idea that you are going to organize around capabilities Build agile teams around those capabilities that are most constrained from a delivery perspective Spread agile systematically based on business need Learn how to coordinate teams
- 85. Incremental Agile Adoption Bottom up implementation with top down intent Focus on constrained capabilities first, taking lessons learned and applying them to other capability teams Create feature teams to integrate the services delivered from the capability teams
- 86. Incremental Agile Adoption Bottom up implementation with top down intent Focus on constrained capabilities first, taking lessons learned and applying them to other capability teams Create feature teams to integrate the services delivered from the capability teams
- 87. Incremental Agile Adoption Bottom up implementation with top down intent Focus on constrained capabilities first, taking lessons learned and applying them to other capability teams Create feature teams to integrate the services delivered from the capability teams
- 88. Incremental Agile Adoption Bottom up implementation with top down intent Focus on constrained capabilities first, taking lessons learned and applying them to other capability teams Create feature teams to integrate the services delivered from the capability teams
- 89. Scaling/Adoption Framework Team based agility
- 90. Scaling/Adoption Framework Team based agility Multi-team agile
- 91. Scaling/Adoption Framework Team based agility Multi-team agile Multi-team projects
- 92. Scaling/Adoption Framework Team based agility Multi-team agile Multi-team projects Multi-project portfolios
- 93. Scaling/Adoption Framework Team based agility Multi-team agile Multi-team projects Multi-project portfolios Enterprise agile
- 94. Team Based Agile Biller Transactions Fin Inst. Transactions Credit Card Payments ACH Payments Fraud/Risk Identity/ Enrollment SAS SAP Corporate Billing Web IVR Payments Risk Business Intelligence Corporate Financials Partner Communication Bus Intel/ Reporting
- 95. Team Based Agile Cross-functional feature team with a limited scope of value delivery relative to the enterprise Special attention to integrating with legacy processes… subordinate the team to the system if necessary
- 96. Team Based Agile Cross-functional feature team with a limited scope of value delivery relative to the enterprise Special attention to integrating with legacy processes… subordinate the team to the system if necessary
- 97. Team Based Agile Cross-functional feature team with a limited scope of value delivery relative to the enterprise Special attention to integrating with legacy processes… subordinate the team to the system if necessary
- 98. Multi-team Agility Biller Transactions Fin Inst. Transactions Credit Card Payments ACH Payments Fraud/Risk Identity/ Enrollment SAS SAP Corporate Billing Web IVR Payments Risk Business Intelligence Corporate Financials Partner Communication Bus Intel/ Reporting
- 99. Multi-team Agility Cross-functional feature team with a limited scope of value delivery relative to the enterprise Special attention to integrating with legacy processes… subordinate the team to the system if necessary Low dependency between teams, manage with Scrum of Scrums
- 100. Multi-team Agility Cross-functional feature team with a limited scope of value delivery relative to the enterprise Special attention to integrating with legacy processes… subordinate the team to the system if necessary Low dependency between teams, manage with Scrum of Scrums
- 101. Multi-team Agility Cross-functional feature team with a limited scope of value delivery relative to the enterprise Special attention to integrating with legacy processes… subordinate the team to the system if necessary Low dependency between teams, manage with Scrum of Scrums
- 102. Multi-team Agility Cross-functional feature team with a limited scope of value delivery relative to the enterprise Special attention to integrating with legacy processes… subordinate the team to the system if necessary Low dependency between teams, manage with Scrum of Scrums
- 103. Multi-Team Projects Biller Transactions Fin Inst. Transactions Credit Card Payments ACH Payments Fraud/Risk Identity/ Enrollment SAS SAP Corporate Billing Web IVR Payments Risk Business Intelligence Corporate Financials Partner Communication Bus Intel/ Reporting
- 104. Multi-Team Projects Introduces requirements or architectural dependencies between Scrum teams Teams have to coordinate to deliver an increment of business value Work has to be coordinated so one team doesn’t get too far ahead of the other teams.
- 105. Multi-Team Projects Introduces requirements or architectural dependencies between Scrum teams Teams have to coordinate to deliver an increment of business value Work has to be coordinated so one team doesn’t get too far ahead of the other teams.
- 106. Multi-Team Projects Introduces requirements or architectural dependencies between Scrum teams Teams have to coordinate to deliver an increment of business value Work has to be coordinated so one team doesn’t get too far ahead of the other teams.
- 107. Multi-Team Projects Introduces requirements or architectural dependencies between Scrum teams Teams have to coordinate to deliver an increment of business value Work has to be coordinated so one team doesn’t get too far ahead of the other teams.
- 108. Value Story Value Story Value Story Value Story
- 109. Feature Value Story Feature Feature Feature Value Story Feature Value Story Feature Value Story
- 110. Team 1 User Story Feature Value Story User Story Feature User Story Team 2 Feature User Story Feature Value Story User Story User Story Feature Value Story User Story Feature Team 3 User Story User Story Value Story User Story
- 111. Team 1 Team 2 Team 3 Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A
- 112. Team 1 Team 2 Team 3 Story A Story A Story A Story A Story A Story B Story A Story A Story B Story A Story B Story B Story A Story A Story B Story A Story A Story B
- 113. Team 1 Team 2 Team 3 Story A Story A Story A Story A Story A Story B Story A Story A Story B Story A Story B Story B Story A Story A Story B Story A Story A Story B Story B Story B Story B Story B Story B Story B Story B Story B
- 114. Team 1 Team 2 Team 3 Story A Story A Story A Story A Story A Story B Story A Story A Story B Story A Story B Story B Story A Story A Story B Story A Story A Story B Story B Story B Story C Story B Story B Story C Story B Story C Story C Story B Story B Story B
- 115. Team 1 Team 2 Team 3 Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A
- 116. Team 1 Team 2 Team 3 Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A
- 117. Team 1 Team 2 Team 3 Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A
- 118. Team 1 Team 2 Team 3 Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A Story B Story B Story B Story B Story B Story B Story B
- 119. Team 1 Team 2 Team 3 Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A Story B Story B Story B Story B Story B Story B Story B Story C Story C Story C Story C Story C Story C Story C Story C Story C
- 120. Team 1 Team 2 Team 3 Story A Story A Story A Story A Story A Story A Story A Story A Story A Story A Story B Story B Story B Story B Story B Story B Story B Story C Story C Story C Story C Story C Story C Story C Story C Story C
- 121. Multi-Project Portfolios Biller Transactions Fin Inst. Transactions Credit Card Payments ACH Payments Fraud/Risk Identity/ Enrollment SAS SAP Corporate Billing Web IVR Payments Risk Business Intelligence Corporate Financials Partner Communication Bus Intel/ Reporting
- 122. Multi-Project Portfolios Shared capability teams must support multiple projects in a portfolio Project decomposition and portfolio decomposition become critical success factors Focus on getting projects done faster rather than starting new projects
- 123. Multi-Project Portfolios Shared capability teams must support multiple projects in a portfolio Project decomposition and portfolio decomposition become critical success factors Focus on getting projects done faster rather than starting new projects
- 124. Multi-Project Portfolios Shared capability teams must support multiple projects in a portfolio Project decomposition and portfolio decomposition become critical success factors Focus on getting projects done faster rather than starting new projects
- 125. Multi-Project Portfolios Shared capability teams must support multiple projects in a portfolio Project decomposition and portfolio decomposition become critical success factors Focus on getting projects done faster rather than starting new projects
- 126. Team 1 Team 2 Team 3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A
- 127. Team 1 Team 2 Team 3 Project A Project A Project A Project A Project A Project B Project A Project A Project B Project A Project B Project B Project A Project A Project B Project A Project A Project B
- 128. Team 1 Team 2 Team 3 Project A Project A Project A Project A Project A Project B Project A Project A Project B Project A Project B Project B Project A Project A Project B Project A Project A Project B Project B Project B Project B Project B Project B Project B Project B Project B
- 129. Team 1 Team 2 Team 3 Project A Project A Project A Project A Project A Project B Project A Project A Project B Project A Project B Project B Project A Project A Project B Project A Project A Project B Project B Project B Project C Project B Project B Project C Project B Project C Project C Project B Project B Project B
- 130. Team 1 Team 2 Team 3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A
- 131. Team 1 Team 2 Team 3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A
- 132. Team 1 Team 2 Team 3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A
- 133. Team 1 Team 2 Team 3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project B Project B Project B Project B Project B Project B Project B
- 134. Team 1 Team 2 Team 3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project B Project B Project B Project B Project B Project B Project B Project C Project C Project C Project C Project C Project C Project C Project C Project C
- 135. Team 1 Team 2 Team 3 Project A Project A Project A Project A Project A Project A Project A Project A Project A Project A Project B Project B Project B Project B Project B Project B Project B Project C Project C Project C Project C Project C Project C Project C Project C Project C
- 136. Enterprise Agility Incorporate upstream and downstream processes that enable and support product delivery Enable the enterprise to make strategic business decisions by establishing constraints Provide feedback early and often to enable course correction
- 137. Enterprise Agility Incorporate upstream and downstream processes that enable and support product delivery Enable the enterprise to make strategic business decisions by establishing constraints Provide feedback early and often to enable course correction
- 138. Enterprise Agility Incorporate upstream and downstream processes that enable and support product delivery Enable the enterprise to make strategic business decisions by establishing constraints Provide feedback early and often to enable course correction
- 139. Enterprise Agility Incorporate upstream and downstream processes that enable and support product delivery Enable the enterprise to make strategic business decisions by establishing constraints Provide feedback early and often to enable course correction
- 140. Not the entire business Product Delivery
- 141. Product Delivery Strategy
- 142. Support Product Delivery Strategy
- 143. PMO
- 144. Project Team PMO
- 145. Capability Team ProjectTeam PMO
- 146. Capability Team ProjectTeam PMO Enterprise Architecture & Value Stories
- 147. Capability Team ProjectTeam PMO Enterprise Architecture & Value Stories Solutions Architecture & Features
- 148. Capability Team ProjectTeam PMO Enterprise Architecture & Value Stories Solutions Architecture & Features Detailed Design & User Stories
- 149. Guidance Capability Team ProjectTeam PMO
- 150. Feedback Capability Team ProjectTeam PMO
- 151. The Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 152. The Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 153. The Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 154. The Pillar Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 155. The Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 156. The Approach Baseline agility assessments Enterprise value modeling Current reality diagrams Coaching and training Control teams
- 157. Conclusion & Wrap-up Team agility is important, but business agility is more important Value is measured more strategically We cannot turn a large, complicated organization on its head overnight Systematically introducing agile around static capability teams is away of responsibly introducing change
- 158. Conclusion & Wrap-up Team agility is important, but business agility is more important Value is measured more strategically We cannot turn a large, complicated organization on its head overnight Systematically introducing agile around static capability teams is away of responsibly introducing change
- 159. Conclusion & Wrap-up Team agility is important, but business agility is more important Value is measured more strategically We cannot turn a large, complicated organization on its head overnight Systematically introducing agile around static capability teams is away of responsibly introducing change
- 160. Conclusion & Wrap-up Team agility is important, but business agility is more important Value is measured more strategically We cannot turn a large, complicated organization on its head overnight Systematically introducing agile around static capability teams is away of responsibly introducing change
- 161. Conclusion & Wrap-up Team agility is important, but business agility is more important Value is measured more strategically We cannot turn a large, complicated organization on its head overnight Systematically introducing agile around static capability teams is a way of responsibly introducing change
- 162. mike cottmeyervp delivery, senior agile coachmcottmeyer@pillartechnology.com404.312.1471www.pillartechnology.comwww.leadingagile.com
- 163. Scaling Agile Past the Team Presented by: Mike Cottmeyer Pillar Technology Group
Editor's Notes
- I want to set this up as a discussion. This is a problem I’m seeing in a very specific domain of scaling agile. I think we’ve got AN answer. Not sure it is the answer. What do I mean by scaling agile. When more than one team has to integrate their activities to deliver something of value to the business.
- I get to spend a lot of time in the community and hear people’s reactions to this. Is it Scrumbut? If we could only do scrum better we could be succesful
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- So here is our small agile team.
- Agile teams are cross functional units that have everything they need to deliver some increment of business value. In a software organization… the agile team is going to have one or more developers…
- They will have one or more QA testers. Sometimes teams have technical testers that are responsible for writing unit tests… sometimes this is left up to the developers. Sometimes teams have manual testers… possibly exercising the UI. Many teams will do both kinds of testing.
- Sometimes a team will someone playing the role of business analyst. This can be a dedicated position on the team… or it might be blended with some other role… maybe a lead developer. Often times teams will have a BA that is serving as a proxy product owner for the real customer or product owner. Dedicated or blended Custome proxy
- Agile teams will usually have someone in the role of ScrumMaster or Agile process coordinator. This can be a dedicated position on the team or a role that is shared with another role on the team. Sometimes you have a dedicated ScrumMaster but they are working with more than one agile team at a time.
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorties, and othewise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- So here is our small agile team.
- The literature says that agile teams build features… features are thin vertical slices of system functionality that span the entire software architecture. Features are things like ‘login to the system’ or ‘make a payment’. They are not tasks… they are not requirements or specifications… they are written in language that is valuable to and end user. Writing requirements this way is great for small teams. The team has everything… they have every role… they need to build the solution. The team is made up of folks that are specializing generalists… there is shared code ownership… team members level the work… it solves many of the project portfolio problems we talked about earlier in the presentation. It eliminates all the dependenies with the rest of the organzation. The problem is that at some level of scale this guidance is not going to hold. The largest program I managed had 17 large scale architectural components. Aside from the organizational issues we were facing… and the degree of specialization amongst the teams… a cross functional feature team would have had over 20 people to deliver a single customer facing feature. That is a pretty big agile team… and just wasn’t conducive to how the organization did business. In effect we were building a large scale system of systems. Each system was a product in its own right. Organizations struggle when they try to build these feature teams when that model is not conducive to their organzations.
- When we start thinking in terms of capabilitiesIt is the responsibility of the larger organization to provide teams with the right stuff to work on, in the right order, with the right level of specificity such that they can produce the valuable outcomes that the business is expecting. Scrum assigns this responsibility to the product owner… this is fine in a small environment… but what many midsized organzations are learning is that the PO role is too big for a single person and are assigning this role to a team of people. The point is that we don’t have to be constrained by the limitations imposed by scrum. What the team needs is well groomed product backlog… if that can come from a single person… great… what we really need to do is to make sure that the team is always working on the highest value backlog items in synchronization with the rest of the business.
- When a team has a well groomed backlog… and you allow that team to stay together over time… that teams begins to establish a stable velocity. Velocity is the rate of flow through the team. How fast the team can deliver value back to the business.
- When I have a well groomed backlog and a stable velocity… the team becomes predictable. It establishes a predictable throughput. I can begin to predict when things will be done so I can effectively coordinate the activities of several teams working together on larger initiatives.
- And when teams become predictable, they establish trust with the rest of the organization. The business knows and understands it capacity and knows what it can commit to. If we want to know what the organization is capable of delivering… we have to first establish what the team is capable of delivering.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 12. Our goal is to recognize, that on projects where we have a tremendous amount of uncertainty... we don't want to create plans that don't reflect our current understanding of reality. We don't want to assume the process overhead of change management, when change is going to be the norm. Agile gives us a way to manage our projects, in the face of uncertainty, while aggressively working to reduce risk and uncertainty.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- We usually build teams of developers…. We have a team of folks that write the cobol code… another that does the .NET development… and yet another that build out the web services…and yet another to do the database work.
- We have a dedicated team of QA professionals that report to a VP of Quality…
- … and a team of BA’s that all report to their own manager.
- We put all our project managers under a director of project management and is tucked up nice and neatly under the PMO…
- Our Product Managers aren’t usually part of the team… they are in their own team. Quite often the Product Owners aren’t even part of IT… they are part of the business and only work with the developers early in the project during the requirements analysis phase.
- When it comes time to think about doing projects… we think through the requirements… and then we go out to each of the resource silos and build a “project team” from each of these various skillset groups. These teams don’t typically stay together… often they don’t really even work together. They write large specification documents and hand off large batches of work across these functional silos. Because each team is responsible for optimizing its particular function… we get really good at writing code… we get really good at writing test plans and documenting defects. We get really good at creating charter documents and Gannt charts. What we don’t usually get very good at is delivering projects… we don’t get good at building working software… or delivering value back to the business. Often the exact opposite happens. Project delivery becomes slow… we build walls between the functional silos… we create environments where we protect our own interests rather than those of the business or our customers. We build large specifications that protect ourselves from the very people that we need to be in partnership with.
- Our Product Managers aren’t usually part of the team… they are in their own team. Quite often the Product Owners aren’t even part of IT… they are part of the business and only work with the developers early in the project during the requirements analysis phase.
- Our Product Managers aren’t usually part of the team… they are in their own team. Quite often the Product Owners aren’t even part of IT… they are part of the business and only work with the developers early in the project during the requirements analysis phase.
- Our Product Managers aren’t usually part of the team… they are in their own team. Quite often the Product Owners aren’t even part of IT… they are part of the business and only work with the developers early in the project during the requirements analysis phase.
- Our Product Managers aren’t usually part of the team… they are in their own team. Quite often the Product Owners aren’t even part of IT… they are part of the business and only work with the developers early in the project during the requirements analysis phase.
- Our Product Managers aren’t usually part of the team… they are in their own team. Quite often the Product Owners aren’t even part of IT… they are part of the business and only work with the developers early in the project during the requirements analysis phase.
- When it comes time to think about doing projects… we think through the requirements… and then we go out to each of the resource silos and build a “project team” from each of these various skillset groups. These teams don’t typically stay together… often they don’t really even work together. They write large specification documents and hand off large batches of work across these functional silos. Because each team is responsible for optimizing its particular function… we get really good at writing code… we get really good at writing test plans and documenting defects. We get really good at creating charter documents and Gannt charts. What we don’t usually get very good at is delivering projects… we don’t get good at building working software… or delivering value back to the business. Often the exact opposite happens. Project delivery becomes slow… we build walls between the functional silos… we create environments where we protect our own interests rather than those of the business or our customers. We build large specifications that protect ourselves from the very people that we need to be in partnership with.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.
- This slide sequence is mainly to setup the talk. Prior to this I want to go through an introduction, talk about how this talk builds on the talk I did yesterday, how it is an experience report where I started developing and writing about some of these ideas around scaling agile across multiple teams.