Disciplined Agile Delivery: Extending Scrum to the Enterprise

1,103 views
851 views

Published on

Going far beyond the limits of a team approach to agile, Scott Ambler explores a disciplined, full-lifecycle methodology for agile software delivery. In this interactive hands-on session, learn how to initiate a large-scale agile project, exploring ways to extend Scrum's value-driven development approach to include both value and risk in the equation. Discover project governance practices that will increase your team's chance of success. Explore with Scott the agile practices—Extreme Programming, Agile Modeling, Agile Data, and the Unified Process—he has found most valuable for large agile teams. Throughout the session, learn to apply the Agile Scaling Model to determine what set of agile practices and techniques will work best for you and your organization. Bring your biggest agile challenges and be prepared to dig into ways to adjust your approach for greater success.

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,103
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
93
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Disciplined Agile Delivery: Extending Scrum to the Enterprise

  1. 1. MK PM Half day Tutorial 11/11/2013 1:00 PM "Disciplined Agile Delivery: Extending Scrum to the Enterprise" Presented by: Scott Ambler Scott Ambler + Associates Brought to you by: 340 Corporate Way, Suite 300, Orange Park, FL 32073 888 268 8770 904 278 0524 sqeinfo@sqe.com www.sqe.com
  2. 2. Scott Ambler Scott W. Ambler + Associates Scott Ambler works with organizations worldwide to help them improve their software processes. Scott is the founder of the Agile Modeling, Agile Data, Disciplined Agile Delivery, and Enterprise Unified Process methodologies, and creator of the Agile Scaling Model. A senior contributing editor with Dr. Dobb’s Journal, Scott is the coauthor of twentyone books, including Refactoring Databases, Agile Modeling, Agile Database Techniques, The Object Primer 3rd Edition, The Enterprise Unified Process, and Disciplined Agile Delivery. Visit his home page ScottAmbler.com and blog.
  3. 3. Disciplined Agile Delivery: Extending Scrum to the Enterprise Scott W. Ambler Senior Consulting Partner scott [at] scottambler.com @scottwambler © Scott Ambler + Associates 1
  4. 4. We’re going to cover a lot of ground © Scott Ambler + Associates 2
  5. 5. Ask questions at any time! © Scott Ambler + Associates 3
  6. 6. Agenda • • • • • • • • Disciplined Agile Delivery (DAD) You Have Choices What it Means to Scale Agile Delivery Governing Agile Teams Agile People at Scale Agile Practices at Scale Enterprise Agile Parting Thoughts © Scott Ambler + Associates 4
  7. 7. Disciplined Agile Delivery © Scott Ambler + Associates 5
  8. 8. Group Exercise: Sharing Agile Experiences • • • • • Organize into teams of 4-6 people Take a few minutes to introduce yourselves to one another For 5 minutes, discuss within the team: – Practical experiences on agile teams – What types of activities you do to initiate the project? (e.g. Did you do any initial modeling or planning? Did you need to get provide estimates go get funding? Other activities?) How long did it take? – What activities did you do during construction? (e.g. How did you approach documentation? Planning? Testing? Architecture?) – What did you need to do to deploy/release your solution into production? How long did it take? Someone needs to be a spokesperson for your team A spokesperson will share a few key learnings with the larger group © Scott Ambler + Associates 6
  9. 9. Important, Empirical Observations Solutions, not just software Stakeholders, not just customers The organizational ecosystem, not just development teams © Scott Ambler + Associates 7
  10. 10. Disciplined Agile Delivery (DAD) Disciplined Agile Delivery (DAD) is a process decision framework The key characteristics of DAD: – People-first – Goal-driven – Hybrid agile – Learning-oriented – Full delivery lifecycle – Solution focused – Risk-value lifecycle – Enterprise aware © Scott Ambler + Associates 8
  11. 11. DAD is a Hybrid Framework SAFe DevOps …and more Outside In Dev. “Traditional” Agile Data Extreme Unified Process Agile Modeling Programming Scrum Kanban Lean DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner. © Scott Ambler + Associates 9
  12. 12. A High Level Lifecycle © Scott Ambler + Associates 10
  13. 13. Scrum Construction Lifecycle A good start… © Scott Ambler + Associates 11
  14. 14. A Scrum Delivery Lifecycle …but this is how agile teams actually work… © Scott Ambler + Associates 12
  15. 15. Unbranded Agile Delivery Lifecycle …and it’s time to abandon the branding. © Scott Ambler + Associates 13
  16. 16. Governed Delivery Lifecycle Disciplined agile teams are guided by senior management… © Scott Ambler + Associates 14
  17. 17. Disciplined Agile Delivery: Basic Lifecycle …and realize they work in an organizational ecosystem. © Scott Ambler + Associates 15
  18. 18. Disciplined Agile Delivery: Lean Lifecycle DAD doesn’t prescribe a single lifecycle… © Scott Ambler + Associates 16
  19. 19. The Phases Disappear Over Time First release: Inception Second release: Third release: I I Construction Construction Construction Transition T T . . . Nth+ releases: C T C T C T C T …and promotes continuous learning and improvement. © Scott Ambler + Associates 17
  20. 20. Disciplined Agile Delivery: Lean Continuous Delivery Lifecycle A good end goal © Scott Ambler + Associates 18
  21. 21. Primary Roles on DAD Teams • Team Lead – Agile process expert, keeps team focused on achievement of goals, removes impediments • Product Owner – Owns the product vision, scope and priorities of the solution • Architecture Owner – Owns the architecture decisions and technical priorities, mitigates key technical risks • Team Member – Cross-functional team members that deliver the solution • Stakeholder – Includes the customer but also other stakeholders such as Project Sponsor, DevOps, architecture, database groups, governance bodies © Scott Ambler + Associates 19
  22. 22. Governance is Built Into DAD • Governance strategies built into DAD: – Risk-value lifecycle – Light-weight milestone reviews – “Standard” opportunities for increased visibility and to steer the team provided by agile – Enterprise awareness – Robust stakeholder definition © Scott Ambler + Associates 20
  23. 23. DevOps Through the DAD Lifecycle O&S staff stakeholders in initial modeling sessions Inception Initial release planning includes deployment O&S staff key Dev team decision makers implements O&S regarding production oriented readiness requirements O&S staff stakeholders throughout construction Construction Transition planning throughout construction Transition Deployment into production Support staff observes stakeholder satisfaction levels O&S = Operations & Support © Scott Ambler + Associates 21
  24. 24. DAD Teams Are Enterprise Aware • DAD teams strive to leverage and enhance the existing organizational eco system wherever possible • Implications: – Work closely with enterprise groups – Follow existing roadmap(s) where appropriate – Leverage existing assets – Enhance existing assets © Scott Ambler + Associates 22
  25. 25. What Does it Mean to Be Disciplined? • • In general, it requires discipline to follow many agile practices and philosophies But, it also requires discipline to: – Reduce the feedback cycle – Learn continuously – Deliver solutions incrementally – Be goal driven – Enterprise aware – Streamline Inception and Transition efforts – Adopt agile governance strategies © Scott Ambler + Associates 23
  26. 26. You Have Choices © Scott Ambler + Associates 24
  27. 27. Strategies for Initial Estimating • • • • • • Formal point counting Planning poker (wide-band delphi) Similar sized items Educated guess by the team Educated guess by an experienced individual Cost/schedule set by the stakeholders © Scott Ambler + Associates 25
  28. 28. Strategies for Funding Projects Fixed price/cost Stage-gate funding Time and materials (T&M) Low T&M plus delivery bonuses Continuous/Drip © Scott Ambler + Associates 26
  29. 29. Group Exercise: Exploring Project Funding • Choose one of the funding strategies from the previous slide For five minutes, discuss the implications of the strategy: • How will the team behave regarding changing requirements? • How will the team behave regarding schedule slippage? • How will quality of the end product potentially be affected? • What risks are being placed on IT? • What risks are being placed on the business? © Scott Ambler + Associates 27
  30. 30. Disciplined Agilists Take a Goal Driven Approach Goal * Issue * Option Default Option Advantages Disadvantages Considerations Indicates a preference for the options towards the top Explore the Initial Scope Form the Initial Team Address Changing Stakeholder Needs Source Team size Team structure Team members Geographic distribution Supporting the team Availability © Scott Ambler + Associates Co-located Partially dispersed Fully dispersed Distributed subteams 28
  31. 31. Goal: Secure Funding © Scott Ambler + Associates 29
  32. 32. Goal – Secure Funding © Scott Ambler + Associates 30
  33. 33. Goal – Secure Funding (cont.) © Scott Ambler + Associates 31
  34. 34. Strategies for Capturing Requirements Detail • • • • BRUF (detailed specifications) Requirements envisioning (lightweight specifications) Goals driven No modeling at all © Scott Ambler + Associates 32
  35. 35. Strategies for Functional Requirements © Scott Ambler + Associates 33
  36. 36. Goal: Explore the Initial Scope © Scott Ambler + Associates 34
  37. 37. Strategies for Change Management Formal Change Management © Scott Ambler + Associates 35
  38. 38. Goal: Address Changing Stakeholder Needs © Scott Ambler + Associates 36
  39. 39. DAD is Process Goal-Driven © Scott Ambler + Associates 37
  40. 40. Scaling Agile © Scott Ambler + Associates 38
  41. 41. What Does it Mean to Scale Agile? Team Size Two Hundreds Geographic Distribution Co-located Global Organizational Distribution Single division Outsourcing Compliance None Life critical Domain Complexity Straightforward Very complex Technical Complexity Straightforward Very complex http://disciplinedagiledelivery.wordpress.com/2013/03/15/sdcf/ © Scott Ambler + Associates 39
  42. 42. Scaling Requires… • • • • • • A disciplined approach – Full delivery lifecycle – Enterprise awareness – Goal-driven approach A bit more up-front thinking – Explore the initial scope a bit deeper – Identify the initial technical strategy in a bit more detail More sophisticated coordination – Individuals and interactions More sophisticated governance – The greater the risk, the greater the need for effective governance More sophisticated validation – Teams at scale are typically tackling harder problems More sophisticated tooling © Scott Ambler + Associates 40
  43. 43. Scaling From a Solid Foundation is Easier • With a DAD-based approach, scaling becomes straightforward because a handful of process goals take the brunt of the tailoring: – Explore initial scope – Identify initial technical strategy – Move closer to a deployable release – Coordinate activities © Scott Ambler + Associates 41
  44. 44. Governing Disciplined Agile Teams © Scott Ambler + Associates 42
  45. 45. Some Bold Claims Regarding Governance Claim #1: Agile teams are being governed today Claim #2: In many organizations the governance strategy is badly misaligned with agile Claim #3: You deserve to be governed effectively Claim #4: When you provide a coherent governance strategy to senior management you are much more likely to be governed effectively © Scott Ambler + Associates 43
  46. 46. Governance Should Address a Range of Issues • • • • • • • • • • • • • Team roles and responsibilities Individual roles and responsibilities Decision rights and decision making process Governing body Exceptions and escalation processes Knowledge sharing processes Metrics strategy Risk mitigation Reward structure Status reporting Audit processes Policies, standards, and guidelines Artifacts and their lifecycles © Scott Ambler + Associates 44
  47. 47. Why is Governance Important? • • • • Sustain and extend your IT strategies and objectives, which in turn should reflect your corporate strategies and objectives Determine how the company will execute its strategy by selecting and prioritizing the most valuable initiatives to undertake Empower teams to carry out their work Help to ensure that delivery teams: – Regularly and consistently create real business value – Provide appropriate return on investment (ROI) – Deliver consumable solutions in a timely and relevant manner – Work effectively with their project stakeholders – Work effectively with their IT colleagues – Adopt processes and organizational structures that encourage successful IT solution delivery – Present accurate and timely information to project stakeholders – Mitigate the risks associated with the project © Scott Ambler + Associates 45
  48. 48. Why Traditional Governance Strategies Won’t Work Traditional assumptions that conflict with agile: – You can judge team progress from generation of artifacts – Delivery teams should work in a serial manner – You want teams to follow a common, repeatable process – Projects should be driven by senior IT management © Scott Ambler + Associates 46
  49. 49. Exercise: I Don’t Want to Be Governed • This is a role playing exercise • Pair up • One person is an agile developer who doesn’t believe that governance is necessary • The other person is a senior manager who will argue for the need for agile governance • For five minutes, have a back and forth discussion with your pair • At the end, identify three solid points that favor governing agile teams and three solid points against doing so © Scott Ambler + Associates 47
  50. 50. Principles of Agile Governance Collaboration over conformance Enablement over inspection Continuous monitoring over quality gates Transparency over management reporting © Scott Ambler + Associates 48
  51. 51. DAD Milestones Milestone Fundamental Question Asked Stakeholder vision Do stakeholders agree with your strategy? Proven architecture Can you actually build this? Project viability Does the project still make sense? Sufficient functionality Does it make sense to release the current solution? Production ready Will the solution work in production? Delighted stakeholders Are stakeholders happy with the deployed solution? © Scott Ambler + Associates 49
  52. 52. DAD Practices that Support Governance • “Standard” agile practices: – Coordination meeting – Iteration demonstrations – All-hands demonstrations – Retrospective – Information radiators/Visual management • Disciplined practices: – Risk-value lifecycle – Explicit light-weight milestones – Follow enterprise development guidelines – Work closely with enterprise professionals – Development intelligence via automated dashboards © Scott Ambler + Associates 50
  53. 53. Agile People at Scale © Scott Ambler + Associates 51
  54. 54. Secondary Roles on DAD Teams • “The secondary” DAD roles typically occur at scale • Specialist – Someone in a specialist role, such as business analyst, program manager, or enterprise architect • Domain Expert – Someone with deep knowledge of the domain, such as a legal expert or marketing expert who is brought in as needed to share their expertise • Technical Expert – Someone with deep technical knowledge, such as a security engineer or user experience (UX) professional, whose help is needed for a short period • Independent Tester – A test/quality professional outside of the team who validates their work. • Integrator – Someone responsible for the operation of the overall team build © Scott Ambler + Associates 52
  55. 55. Large Teams Organizational options: • Feature teams: A subteam works on a feature from end to end. • Component teams: A subteam does all the work for a specific component. • Internal open source: A component is developed via open source techniques. © Scott Ambler + Associates 53
  56. 56. Leadership Teams • For large teams there are several coordination subteams: – Architecture Owners – Responsible for technical coordination – Product Owners – Responsible for requirements coordination – Project Management – Responsible for team coordination and management • How it works: – Early in the project the respective visions are agreed to by key members of each coordination team (plus others) – Throughout the project these teams coordinate their respective issues on a regular basis with one another © Scott Ambler + Associates 54
  57. 57. Geographically Distributed/Dispersed Teams © Scott Ambler + Associates 55
  58. 58. Group Exercise: Enterprise Teams • Get back together into your groups • Take 5 minutes to discuss: – How do your agile delivery teams interact with enterprise teams that provide cross-team services? – Consider enterprise teams such as: • Enterprise Architecture • Portfolio management • Reuse/asset management • Infrastructure/operations and support • Data management © Scott Ambler + Associates 56
  59. 59. Pattern: Enterprise Team • Individuals are members of both a delivery team and an enterprise team • Common examples include: – Architecture Ownership Team (Enterprise Architecture) – Product Ownership Team (Product Management) – Product Delivery Office (Portfolio Management) • The delivery teams determine who will be in the enterprise role for them • Delivery Team Potential scheduling challenges for the people in the enterprise roles due to multi-team commitments • Enterprise Team The leaders of each enterprise team may be a full time position © Scott Ambler + Associates 57
  60. 60. Enterprise Team Example: Enterprise Architecture • • • • Responsible for developing the architecture/technology roadmap for your organization Delivery teams will determine who the architecture owner (AO) is, and that person becomes part of the AO team The AO team meets regularly to evolve the roadmap based on the hands-on learnings from the AOs Often called the enterprise architecture team © Scott Ambler + Associates 58
  61. 61. Pattern: Specialized Services Team • Specialized services teams fulfill requests from delivery teams • Common examples of specialized services: – Infrastructure/network – Database administration – Security – Facilities • The specialized services team will often have a service level agreement (SLA) that the work to • Specialized Service Team Delivery Team Service Potential for the services team to become a bottleneck • Service Request They may supply specialists on a short term basis to some delivery teams © Scott Ambler + Associates 59
  62. 62. Services Team Example: Database Administration (DBA) Team • • Responsible for supporting database development and database operation in production The delivery team submits a request, the DBA Team prioritizes it and then fulfills it © Scott Ambler + Associates 60
  63. 63. Communities of Excellence (CoE) • A CoE focuses on sharing and enhancing skills within a group of like-minded people organized on a volunteer basis • Individuals will choose to join zero or more CoEs • Potential CoEs: – Agile – Architecture – Testing – Leadership – Security • CoEs may adopt common strategies include internal discussion forums, training sessions, “brownbag lunches”, and even certification. © Scott Ambler + Associates 61
  64. 64. Release train Multiple “backlogs” IT intelligence Development intelligence Continuous documentation Requirements envisioning Consumable solutions API first Continuous architecture “Scaling” Practices Work item pools Work item lists Parallel independent testing Test suite API Architecture envisioning Active stakeholder participation Continuous deployment © Scott Ambler + Associates 62
  65. 65. “Common” Agile Practices that Support Scaling • • • • • Continuous Coordination – Coordination meetings – e.g. “Daily stand ups” – Development intelligence – Demos Short iterations/sprints Regularly producing a potentially consumable solution – e.g. Potentially shippable software in Scrum Continuous integration – Better yet continuous deployment Agile planning – Initial high-level release planning – Just in time (JIT) detailed planning – e.g. Iteration/sprint planning – Look-ahead planning © Scott Ambler + Associates 63
  66. 66. Agile Modeling’s Best Practices © Scott Ambler + Associates 64
  67. 67. API First/Test Suite API • When there are many people developing a shared set of components you should invest time at the beginning of the project to identify the components and define the interfaces to those components – “Component” is used to indicate any shared technical resource such as a set of web services, a shared data source, a programming library, a framework, and so on – Many teams will choose to write the interface stubs and tests at this time so that they have something to integrate • Effectively a rigorous application of Agile Model’s Architecture Envisioning and Just Barely Good Enough practices • API First is a practice of The Eclipse Way • Also known as Contract Model in Agile Modeling © Scott Ambler + Associates 65
  68. 68. Continuous Deployment (CD) © Scott Ambler + Associates 66
  69. 69. Parallel Independent Testing © Scott Ambler + Associates 67
  70. 70. Multiple Backlogs • There are dependencies between work items (including requirements) • When large teams are separated into subteams, and if each subteam has its own work items, then these dependencies need to be managed • Product Owners are responsible for the work items, therefore they need to coordinate dependencies with one another © Scott Ambler + Associates 68
  71. 71. Enterprise Agile © Scott Ambler + Associates 69
  72. 72. IT is More than Solution Delivery Solution Delivery Operations and Support People Management Portfolio Management Programme Management IT Governance Enterprise Architecture Asset Management Information Management © Scott Ambler + Associates 70
  73. 73. Your Organization is More Than IT Information Technology Department Your Organization © Scott Ambler + Associates 71
  74. 74. Agile/Scrum is a Good Starting Point • • • • • Construction focus Value driven lifecycle Self-organizing teams Prescriptive Project team aware © Scott Ambler + Associates 72
  75. 75. DAD Solidifies the Foundation • • • • • Delivery focus Risk-value driven lifecycle Self-organization with appropriate governance Goal driven Enterprise aware © Scott Ambler + Associates 73
  76. 76. Agility at Scale • • • • • • Large teams Geographically distributed teams Compliance Domain or technical complexity Cultural issues Organizational distribution © Scott Ambler + Associates 74
  77. 77. Individuals Become Agile Individuals to be able to become a truly agile practitioner within the evolving context of the situation that they face They will require training, education and coaching © Scott Ambler + Associates 75
  78. 78. Teams Build Solutions Teams will self organize their work strategy, their structure, and their collaboration paths to reflect the context of the situation that they find themselves in They will require guidance to do so effectively © Scott Ambler + Associates 76
  79. 79. IT Departments Become Agile IT departments are often sophisticated entities with teams addressing a wide range of situations and a wide range of goals Agile delivery teams are just part of the overall mix, as are operations teams, architecture teams, portfolio management teams, and many more IT organizations will need to adopt a wide range of strategies that reflect the challenges that they face © Scott Ambler + Associates 77
  80. 80. The Agile Enterprise An agile enterprise has two key characteristics*: • Response ability – The physical ability to act is derived from two sources, an organizational structure that enables change and an organizational culture that facilitates change • Knowledge management – The intellectual ability to find appropriate things to act on and encompasses both top-down knowledge portfolio management (KPM) and bottom-up collaborative learning * Response Ability by Rick Dove, 2001. © Scott Ambler + Associates 78
  81. 81. © Scott Ambler + Associates 79
  82. 82. © Scott Ambler + Associates 80
  83. 83. What Does it Mean to Be Disciplined? • • In general, it requires discipline to follow many agile practices and philosophies But, it also requires discipline to: – Reduce the feedback cycle – Learn continuously – Deliver solutions incrementally – Be goal driven – Enterprise aware – Streamline Inception and Transition efforts – Adopt agile governance strategies © Scott Ambler + Associates 81
  84. 84. Disciplined Agile Delivery: The Foundation for Scaling Agile Compliance Domain Complexity Technical Complexity Geographic Distribution Team Size Organizational Distribution Outside In Dev. SAFe XP Scrum And more… Agile Modeling Kanban Lean Disciplined Agile Delivery (DAD) DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner. © Scott Ambler + Associates 82
  85. 85. A Disciplined Ending…. Please… – Take the opportunity to thank your teammates – we all learned together – Fill out the workshop evaluation form(s) – Turn in the evaluation(s) to the instructor © Scott Ambler + Associates 83
  86. 86. Got Discipline? DisciplinedAgileConsortium.org DisciplinedAgileDelivery.com ScottAmbler.com © Scott Ambler + Associates 84
  87. 87. Thank You! scott [at] scottambler.com @scottwambler AgileModeling.com AgileData.org Ambysoft.com DisciplinedAgileConsortium.org DisciplinedAgileDelivery.com ScottAmbler.com Disciplined Agile Delivery Disciplined Agile Delivery © Scott Ambler + Associates 85
  88. 88. DAD Certification: DisciplinedAgileConsortium.org Disciplined Agile Yellow Belt – Indication that the person is new to disciplined agile but eager to learn – Validate basic knowledge via a test Disciplined Agile Green Belt – Indication that the person is striving to be a professional – Potential to be a junior coach – Difficult test and several years of proven experience Disciplined Agile Black Belt – Indication that the person is an expert – Often a senior coach, instructor, or agile transformation lead – Board-level certification © Scott Ambler + Associates 86
  89. 89. Recommended Resources © Scott Ambler + Associates 87
  90. 90. Backup Slides © Scott Ambler + Associates 88
  91. 91. Agile Experiences with Team Size On your (un)successful agile projects, how many IT team members were there? Source: 2012 Agile Scaling Survey www.ambysoft.com/surveys/ © Scott Ambler + Associates 89
  92. 92. Agile Experiences with Geographic Distribution On your (un)successful agile projects, how distributed were team members? Source: 2012 Agile Scaling Survey www.ambysoft.com/surveys/ © Scott Ambler + Associates 90
  93. 93. Agile Experiences with Compliance On your (un)successful agile projects, was compliance applicable? Note: Self imposed = CMMI, ISO, … Source: 2012 Agile Scaling Survey www.ambysoft.com/surveys/ © Scott Ambler + Associates 91
  94. 94. Agile Experiences with Domain Complexity Question: From the point of view of the problem/business domain, at what level(s) of complexity has the organization (un)successfully applied agile techniques? (Please check all that apply) Pilot Projects Straightforward Medium complexity Complex High Risk 0% 10% 20% 30% Had Successes 40% 50% 60% 70% 80% Had Failures © Scott Ambler + Associates Source: 2012 Agile Scaling Survey www.ambysoft.com/surveys/ 92
  95. 95. Agile Experiences with Technical Complexity Question: In which technical situations has the organization (un)successfully applied agile approaches? (Please check all that apply) Greenfield Stand-alone Package/COTS System integration Fix legacy systems Access legacy data Fix legacy data Single platform Multi-platform 0% 10% 20% 30% Had Successes 40% 50% 60% 70% 80% Had Failures Source: 2012 Agile Scaling Survey www.ambysoft.com/surveys/ © Scott Ambler + Associates 93
  96. 96. Agile Experiences with Organizational Distribution Question: In which of the following situations has the organization (un)successfully applied agile techniques? (Please check all that apply) Same division Several divisions Several countries Contractors/consultants Partner organizations Outsourcing 0% 10% 20% Had Successes 30% 40% 50% 60% 70% 80% Had Failures Source: 2012 Agile Scaling Survey www.ambysoft.com/surveys/ © Scott Ambler + Associates 94

×