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.
CNIC Information System with Pakdata Cf In Pakistan
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
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.
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
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
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
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.
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
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.