Downloaded 193 times
Uploaded byMike Cottmeyer
Scaling Agile Past the Team
The document discusses pragmatic strategies for scaling agile practices within large and complex organizations, emphasizing the challenges of traditional transformations. It outlines a framework for incremental adoption of agile principles, focusing on organizing teams around capabilities and integrating cross-functional features. Key issues addressed include overcoming functional silos, building efficient multi-team coordination, and ensuring enterprise-wide agility through proper alignment of upstream and downstream processes.
More Related Content
Similar to Scaling Agile Past the Team
Scaling Agile Past the Team
- 1. Scaling Agile Pastthe TeamPresented by: Mike CottmeyerPillar 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 AgileExplore commonguidance for an enterprise agile transformationWhat happens when that guidance hits real life organizations and productsThe goal of enterprise agility when transformation isn’t possiblePatterns and tools for pragmatically scaling agile to the enterprise
- 5. Scaling AgileExplore commonguidance for an enterprise agile transformationWhat happens when that guidance hits real life organizations and productsThe goal of enterprise agility when transformation isn’t possiblePatterns and tools for pragmatically scaling agile to the enterprise
- 6. Scaling AgileExplore commonguidance for an enterprise agile transformationWhat happens when that guidancehits real life organizations and productsThe goal of enterprise agility when transformation isn’t possiblePatterns and tools for pragmatically scaling agile to the enterprise
- 7. Scaling AgileExplore commonguidance for an enterprise agile transformationWhat happens when that guidance hits real life organizations and productsThe goal of enterprise agility when transformation isn’t possiblePatterns and tools for pragmatically scaling agile to the enterprise
- 8. Scaling AgileExplore commonguidance for an enterprise agile transformationWhat happens when that guidance hits real life organizations and productsThe goal of enterprise agility when transformation isn’t possiblePatterns and tools for pragmatically scaling agile to the enterprise
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22. User StoryScreenUser StoryTeamUserStoryReportUser StoryUser StoryDatabaseUser StoryUser Story
- 23. User StoryScreenUser StoryTeamUserStoryReportUser StoryUser StoryDatabaseUser StoryUser Story
- 24.
- 25.
- 26.
- 27.
- 28.
- 29. Team 1Team 2Team3Team 5Team 4Team 6Scrum of Scrums
- 30. Team 1Team 2Team3Team 5Team 4Team 6Scrum of ScrumsEncapsulate Teams
- 31. Lessons from ScalingAgileCross-functional features teams that can operate independently of each other under the guidance of a single product ownerQuantifiable business value can be created by each team at the end of a single sprint.
- 32. Lessons from ScalingAgileCross-functional features teams that can operate independently of each other under the guidance of a single product ownerQuantifiable business value can be created by each team at the end of a single sprint.
- 33. Lessons from ScalingAgileCross-functional features teams that can operate independently of each other under the guidance of a single product ownerQuantifiable business value can be created by each team at the end of a single sprint.
- 34.
- 35. The Transformation ProblemFunctionalSilosOver specializationComplex productsCultural challenges
- 36. The Transformation ProblemFunctionalSilosOver specializationComplex productsCultural challenges
- 37. The Transformation ProblemFunctionalSilosOver specializationComplex productsCultural challenges
- 38. The Transformation ProblemFunctionalSilosOver specializationComplex productsCultural challenges
- 39. The Transformation ProblemFunctionalSilosOver specializationComplex productsCultural challenges
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56. Biller TransactionsFin Inst.TransactionsCredit Card PaymentsACH PaymentsFraud/RiskIdentity/ EnrollmentSASSAPCorporate BillingWebIVRPaymentsRiskBusiness IntelligenceCorporate FinancialsPartner CommunicationBus Intel/ Reporting
- 57. Biller TransactionsFin Inst.TransactionsCredit Card PaymentsACH PaymentsFraud/RiskIdentity/ EnrollmentSASSAPCorporate BillingWebIVRPaymentsRiskBusiness IntelligenceCorporate FinancialsPartner CommunicationBus Intel/ Reporting
- 58. Biller TransactionsFin Inst.TransactionsCredit Card PaymentsACH PaymentsFraud/RiskIdentity/ EnrollmentSASSAPCorporate BillingWebIVRPaymentsRiskBusiness IntelligenceCorporate FinancialsPartner CommunicationBus Intel/ Reporting
- 59. Biller TransactionsFin Inst.TransactionsCredit Card PaymentsACH PaymentsFraud/RiskIdentity/ EnrollmentSASSAPCorporate BillingWebIVRPaymentsRiskBusiness IntelligenceCorporate FinancialsPartner CommunicationBus Intel/ Reporting
- 60. Biller TransactionsFin Inst.TransactionsCredit Card PaymentsACH PaymentsFraud/RiskIdentity/ EnrollmentSASSAPCorporate BillingWebIVRPaymentsRiskBusiness IntelligenceCorporate FinancialsPartner CommunicationBus Intel/ Reporting
- 61. Biller TransactionsFin Inst.TransactionsCredit Card PaymentsACH PaymentsFraud/RiskIdentity/ EnrollmentSASSAPCorporate BillingWebIVRPaymentsRiskBusiness IntelligenceCorporate FinancialsPartner CommunicationBus Intel/ Reporting
- 62.
- 63. Credit Card PaymentsACHPaymentsPayments
- 64. ManagersCredit Card PaymentsACHPaymentsPayments
- 65. ManagersCredit Card PaymentsACHPaymentsPaymentsAccountability
- 66. ManagersAuthorityCredit Card PaymentsACHPaymentsPaymentsAccountability
- 67. ManagersAuthorityCredit Card PaymentsACHPaymentsPaymentsPeopleAccountability
- 68. ManagersAuthorityCredit Card PaymentsACHPaymentsPowerPaymentsPeopleAccountability
- 69. ManagersAuthorityCredit Card PaymentsACHPaymentsControlPowerPaymentsPeopleAccountability
- 70. The Transformation ProblemTeamsare 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 ProblemTeamsare 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 ProblemTeamsare 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 ProblemTechnologyconstraints can initiallylimit the degree to which you can make shared code ownership a realityBreaking down all silos and reporting relationships can make ownership and accountability issues a nightmare through the transition
- 74. The Transformation ProblemTechnologyconstraints can initially limit the degree to which you can make shared code ownership a realityBreaking down all silos and reporting relationships can make ownership and accountability issues a nightmare through the transition
- 75. The Transformation ProblemTechnologyconstraints can initiallylimit the degree to which you can make shared code ownership a realityBreaking down all silos and reporting relationships can make ownership and accountability issues a nightmare through the transition
- 76.
- 77.
- 78.
- 79. What Are YouWilling to Give Up to Get there?
- 80. Incremental Agile AdoptionStartwith the idea that you are going to organize around capabilitiesBuild agile teams around those capabilities that are most constrained from a delivery perspectiveSpread agile systematically based on business needLearn how to coordinate teams
- 81. Incremental Agile AdoptionStartwith the idea that you are going to organize around capabilitiesBuild agile teams around those capabilities that are most constrained from a delivery perspectiveSpread agile systematically based on business needLearn how to coordinate teams
- 82. Incremental Agile AdoptionStartwith the idea that you are going to organize around capabilitiesBuild agile teams around those capabilities that are most constrained from a delivery perspectiveSpread agile systematically based on business needLearn how to coordinate teams
- 83. Incremental Agile AdoptionStartwith the idea that you are going to organize around capabilitiesBuild agile teams around those capabilities that are most constrained from a delivery perspectiveSpread agile systematically based on business needLearn how to coordinate teams
- 84. Incremental Agile AdoptionStartwith the idea that you are going to organize around capabilitiesBuild agile teams around those capabilities that are most constrained from a delivery perspectiveSpread agile systematically based on business needLearn how to coordinate teams
- 85. Incremental Agile AdoptionBottomup implementation with top down intentFocus on constrained capabilities first, taking lessons learned and applying them to other capability teamsCreate feature teams to integrate the services delivered from the capability teams
- 86. Incremental Agile AdoptionBottomup implementation with top down intentFocus on constrained capabilities first, taking lessons learned and applying them to other capability teamsCreate feature teams to integrate the services delivered from the capability teams
- 87. Incremental Agile AdoptionBottomup implementation with top down intentFocus on constrained capabilities first, taking lessons learned and applying them to other capability teamsCreate feature teams to integrate the services delivered from the capability teams
- 88. Incremental Agile AdoptionBottomup implementation with top down intentFocus on constrained capabilities first, taking lessons learned and applying them to other capability teamsCreate feature teams to integrate the services delivered from the capability teams
- 89.
- 90. Scaling/Adoption FrameworkTeam basedagilityMulti-team agile
- 91. Scaling/Adoption FrameworkTeam basedagilityMulti-team agileMulti-team projects
- 92. Scaling/Adoption FrameworkTeam basedagilityMulti-team agileMulti-team projectsMulti-project portfolios
- 93. Scaling/Adoption FrameworkTeam basedagilityMulti-team agileMulti-team projectsMulti-project portfoliosEnterprise agile
- 94. Team Based AgileBillerTransactionsFin Inst. TransactionsCredit Card PaymentsACH PaymentsFraud/RiskIdentity/ EnrollmentSASSAPCorporate BillingWebIVRPaymentsRiskBusiness IntelligenceCorporate FinancialsPartner CommunicationBus Intel/ Reporting
- 95. Team Based AgileCross-functionalfeature team with a limited scope of value delivery relative to the enterpriseSpecial attention to integrating with legacy processes… subordinate the team to the system if necessary
- 96. Team Based AgileCross-functionalfeature team with a limited scope of value delivery relative to the enterpriseSpecial attention to integrating with legacy processes… subordinate the team to the system if necessary
- 97. Team Based AgileCross-functionalfeature team with a limited scope of value delivery relative to the enterpriseSpecial attention to integrating with legacy processes… subordinate the team to the system if necessary
- 98. Multi-team AgilityBiller TransactionsFinInst. TransactionsCredit Card PaymentsACH PaymentsFraud/RiskIdentity/ EnrollmentSASSAPCorporate BillingWebIVRPaymentsRiskBusiness IntelligenceCorporate FinancialsPartner CommunicationBus Intel/ Reporting
- 99. Multi-team AgilityCross-functional featureteam with a limited scope of value delivery relative to the enterpriseSpecial attention to integrating with legacy processes… subordinate the team to the system if necessaryLow dependency between teams, manage with Scrum of Scrums
- 100. Multi-team AgilityCross-functional featureteam with a limited scope of value delivery relative to the enterpriseSpecial attention to integrating with legacy processes… subordinate the team to the system if necessaryLow dependency between teams, manage with Scrum of Scrums
- 101. Multi-team AgilityCross-functional featureteam with a limited scope of value delivery relative to the enterpriseSpecial attention to integrating with legacy processes… subordinate the team to the system if necessaryLow dependency between teams, manage with Scrum of Scrums
- 102. Multi-team AgilityCross-functional featureteam with a limited scope of value delivery relative to the enterpriseSpecial attention to integrating with legacy processes… subordinate the team to the system if necessaryLow dependency between teams, manage with Scrum of Scrums
- 103. Multi-Team ProjectsBiller TransactionsFinInst. TransactionsCredit Card PaymentsACH PaymentsFraud/RiskIdentity/ EnrollmentSASSAPCorporate BillingWebIVRPaymentsRiskBusiness IntelligenceCorporate FinancialsPartner CommunicationBus Intel/ Reporting
- 104. Multi-Team ProjectsIntroduces requirementsor architectural dependencies between Scrum teamsTeams have to coordinate to deliver an increment of business valueWork has to be coordinated so one team doesn’t get too far ahead of the other teams.
- 105. Multi-Team ProjectsIntroduces requirementsor architectural dependencies between Scrum teamsTeams have to coordinate to deliver an increment of business valueWork has to be coordinated so one team doesn’t get too far ahead of the other teams.
- 106. Multi-Team ProjectsIntroduces requirementsor architectural dependencies between Scrum teamsTeams have to coordinate to deliver an increment of business valueWork has to be coordinated so one team doesn’t get too far ahead of the other teams.
- 107. Multi-Team ProjectsIntroduces requirementsor architectural dependencies between Scrum teamsTeams have to coordinate to deliver an increment of business valueWork has to be coordinated so one team doesn’t get too far ahead of the other teams.
- 108. Value StoryValue StoryValueStoryValue Story
- 109. FeatureValue StoryFeatureFeatureFeatureValue StoryFeatureValueStoryFeatureValue Story
- 110. Team 1User StoryFeatureValueStoryUser StoryFeatureUser StoryTeam 2FeatureUser StoryFeatureValue StoryUser StoryUser StoryFeatureValue StoryUser StoryFeatureTeam 3User StoryUser StoryValue StoryUser Story
- 111. Team 1Team 2Team3Story AStory AStory AStory AStory AStory AStory AStory AStory AStory AStory AStory A
- 112. Team 1Team 2Team3Story AStory AStory AStory AStory AStory BStory AStory AStory BStory AStory BStory BStory AStory AStory BStory AStory AStory B
- 113. Team 1Team 2Team3Story AStory AStory AStory AStory AStory BStory AStory AStory BStory AStory BStory BStory AStory AStory BStory AStory AStory BStory BStory BStory BStory BStory BStory BStory BStory B
- 114. Team 1Team 2Team3Story AStory AStory AStory AStory AStory BStory AStory AStory BStory AStory BStory BStory AStory AStory BStory AStory AStory BStory BStory BStory CStory BStory BStory CStory BStory CStory CStory BStory BStory B
- 115. Team 1Team 2Team3Story AStory AStory AStory AStory AStory AStory AStory AStory AStory AStory AStory A
- 116. Team 1Team 2Team3Story AStory AStory AStory AStory AStory AStory AStory AStory AStory AStory AStory A
- 117. Team 1Team 2Team3Story AStory AStory AStory AStory AStory AStory AStory AStory AStory A
- 118. Team 1Team 2Team3Story AStory AStory AStory AStory AStory AStory AStory AStory AStory AStory BStory BStory BStory BStory BStory BStory B
- 119. Team 1Team 2Team3Story AStory AStory AStory AStory AStory AStory AStory AStory AStory AStory BStory BStory BStory BStory BStory BStory BStory CStory CStory CStory CStory CStory CStory CStory CStory C
- 120. Team 1Team 2Team3Story AStory AStory AStory AStory AStory AStory AStory AStory AStory AStory BStory BStory BStory BStory BStory BStory BStory CStory CStory CStory CStory CStory CStory CStory CStory C
- 121. Multi-Project PortfoliosBiller TransactionsFinInst. TransactionsCredit Card PaymentsACH PaymentsFraud/RiskIdentity/ EnrollmentSASSAPCorporate BillingWebIVRPaymentsRiskBusiness IntelligenceCorporate FinancialsPartner CommunicationBus Intel/ Reporting
- 122. Multi-Project PortfoliosShared capabilityteams must support multiple projects in a portfolioProject decomposition and portfolio decomposition become critical success factorsFocus on getting projects done faster rather than starting new projects
- 123. Multi-Project PortfoliosShared capabilityteams must support multiple projects in a portfolioProject decomposition and portfolio decomposition become critical success factorsFocus on getting projects done faster rather than starting new projects
- 124. Multi-Project PortfoliosShared capabilityteams must support multiple projects in a portfolioProject decomposition and portfolio decomposition become critical success factorsFocus on getting projects done faster rather than starting new projects
- 125. Multi-Project PortfoliosShared capabilityteams must support multiple projects in a portfolioProject decomposition and portfolio decomposition become critical success factorsFocus on getting projects done faster rather than starting new projects
- 126. Team 1Team 2Team3Project AProject AProject AProject AProject AProject AProject AProject AProject AProject AProject AProject A
- 127. Team 1Team 2Team3Project AProject AProject AProject AProject AProject BProject AProject AProject BProject AProject BProject BProject AProject AProject BProject AProject AProject B
- 128. Team 1Team 2Team3Project AProject AProject AProject AProject AProject BProject AProject AProject BProject AProject BProject BProject AProject AProject BProject AProject AProject BProject BProject BProject BProject BProject BProject BProject BProject B
- 129. Team 1Team 2Team3Project AProject AProject AProject AProject AProject BProject AProject AProject BProject AProject BProject BProject AProject AProject BProject AProject AProject BProject BProject BProject CProject BProject BProject CProject BProject CProject CProject BProject BProject B
- 130. Team 1Team 2Team3Project AProject AProject AProject AProject AProject AProject AProject AProject AProject AProject AProject A
- 131. Team 1Team 2Team3Project AProject AProject AProject AProject AProject AProject AProject AProject AProject AProject AProject A
- 132. Team 1Team 2Team3Project AProject AProject AProject AProject AProject AProject AProject AProject AProject A
- 133. Team 1Team 2Team3Project AProject AProject AProject AProject AProject AProject AProject AProject AProject AProject BProject BProject BProject BProject BProject BProject B
- 134. Team 1Team 2Team3Project AProject AProject AProject AProject AProject AProject AProject AProject AProject AProject BProject BProject BProject BProject BProject BProject BProject CProject CProject CProject CProject CProject CProject CProject CProject C
- 135. Team 1Team 2Team3Project AProject AProject AProject AProject AProject AProject AProject AProject AProject AProject BProject BProject BProject BProject BProject BProject BProject CProject CProject CProject CProject CProject CProject CProject CProject C
- 136. Enterprise AgilityIncorporate upstreamand downstream processes that enable and support product deliveryEnable the enterprise to make strategic business decisions by establishing constraintsProvide feedback early and often to enable course correction
- 137. Enterprise AgilityIncorporate upstreamand downstream processes that enable and support product deliveryEnable the enterprise to make strategic business decisions by establishing constraintsProvide feedback early and often to enable course correction
- 138. Enterprise AgilityIncorporate upstreamand downstream processes that enable and support product deliveryEnable the enterprise to make strategic business decisions by establishing constraintsProvide feedback early and often to enable course correction
- 139. Enterprise AgilityIncorporate upstreamand downstream processes that enable and support product deliveryEnable the enterprise to make strategic business decisions by establishing constraintsProvide feedback early and often to enable course correction
- 140. Not the entirebusinessProductDelivery
- 141.
- 142.
- 143.
- 144.
- 145.
- 146.
- 147.
- 148.
- 149.
- 150.
- 151. The ApproachBaseline agilityassessmentsEnterprise value modelingCurrent reality diagramsCoaching and trainingControl teams
- 152. The ApproachBaseline agilityassessmentsEnterprise value modelingCurrent reality diagramsCoaching and trainingControl teams
- 153. The ApproachBaseline agilityassessmentsEnterprise value modelingCurrent reality diagramsCoaching and trainingControl teams
- 154. The Pillar ApproachBaselineagility assessmentsEnterprise value modelingCurrent reality diagramsCoaching and trainingControl teams
- 155. The ApproachBaseline agilityassessmentsEnterprise value modelingCurrent reality diagramsCoaching and trainingControl teams
- 156. The ApproachBaseline agilityassessmentsEnterprise value modelingCurrent reality diagramsCoaching and trainingControl teams
- 157. Conclusion & Wrap-upTeamagility is important, but business agility is more importantValue is measured more strategicallyWe cannot turn a large, complicated organization on its head overnightSystematically introducing agile around static capability teams is away of responsibly introducing change
- 158. Conclusion & Wrap-upTeamagility is important, but business agility is more importantValue is measured more strategicallyWe cannot turn a large, complicated organization on its head overnightSystematically introducing agile around static capability teams is away of responsibly introducing change
- 159. Conclusion & Wrap-upTeamagility is important, but business agility is more importantValue is measured more strategicallyWe cannot turn a large, complicated organization on its head overnightSystematically introducing agile around static capability teams is away of responsibly introducing change
- 160. Conclusion & Wrap-upTeamagility is important, but business agility is more importantValue is measured more strategicallyWe cannot turn a large, complicated organization on its head overnightSystematically introducing agile around static capability teams is away of responsibly introducing change
- 161. Conclusion & Wrap-upTeamagility is important, but business agility is more importantValue is measured more strategicallyWe cannot turn a large, complicated organization on its head overnightSystematically 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 Pastthe TeamPresented by: Mike CottmeyerPillar Technology Group
Editor's Notes
- #2 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.
- #3 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
- #5 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.
- #6 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.
- #7 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.
- #8 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.
- #9 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.
- #11 So here is our small agile team.
- #12 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…
- #13 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.
- #14 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
- #15 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.
- #16 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.
- #17 So here is our small agile team.
- #18 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.
- #19 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.
- #20 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.
- #21 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.
- #22 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.
- #23 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.
- #24 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.
- #32 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.
- #33 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.
- #34 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.
- #36 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.
- #37 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.
- #38 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.
- #39 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.
- #40 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.
- #42 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.
- #43 We have a dedicated team of QA professionals that report to a VP of Quality…
- #44 … and a team of BA’s that all report to their own manager.
- #45 We put all our project managers under a director of project management and is tucked up nice and neatly under the PMO…
- #46 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.
- #47 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.
- #49 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.
- #50 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.
- #51 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.
- #52 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.
- #53 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.
- #54 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.
- #56 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.
- #57 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.
- #58 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.
- #59 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.
- #60 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.
- #61 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.
- #62 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.
- #64 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.
- #65 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.
- #66 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.
- #67 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.
- #68 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.
- #69 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.
- #70 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.
- #71 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.
- #72 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.
- #73 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.
- #74 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.
- #75 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.
- #76 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.
- #81 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.
- #82 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.
- #83 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.
- #84 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.
- #85 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.
- #86 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.
- #87 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.
- #88 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.
- #89 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.
- #90 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.
- #91 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.
- #92 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.
- #93 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.
- #94 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.
- #95 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.
- #96 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.
- #97 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.
- #98 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.
- #99 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.
- #100 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.
- #101 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.
- #102 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.
- #103 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.
- #104 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.
- #105 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.
- #106 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.
- #107 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.
- #108 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.
- #122 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.
- #123 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.
- #124 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.
- #125 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.
- #126 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.
- #137 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.
- #138 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.
- #139 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.
- #140 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.
- #158 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.
- #159 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.
- #160 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.
- #161 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.
- #162 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.