Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Disciplined Agile Outsourcing: Making it work for both the customer and the service provider


Published on

Outsourcing projects suffer from two significant yet easily addressed problems. First, the customer’s instincts for how to run an outsourced project are more likely to hurt rather than help them. Second, service providers (SPs) prove to be little more than order takers that don’t have the courage to negotiate a winning strategy. The Disciplined Agile Delivery (DAD) process decision framework provides the foundation needed to succeed at “agile offshoring” by addressing the needs of both the customer and the SP. DAD is a goal-driven, hybrid agile, full delivery methodology that is enterprise aware and scalable. DAD provides a foundation from which you can tailor a viable strategy for disciplined agile outsourcing. This presentation explores strategies for effectively initiating and governing an outsourced IT delivery project in an agile manner. Outsourcing introduces a collection of risks that can be uniquely addressed with a disciplined agile strategy.

During this presentation you will learn:
• What the Disciplined Agile Delivery (DAD) framework is.
• The risks associated with outsourcing.
• Disciplined agile outsourcing from the point of view of the customer.
• Disciplined agile outsourcing from the point of view of the service provider.
• What you need to do to succeed at disciplined agile outsourcing.
• Industry statistics regarding agile outsourcing in practice
• Criteria to determine if you’re ready for outsourcing IT delivery projects.

Published in: Software

Disciplined Agile Outsourcing: Making it work for both the customer and the service provider

  1. 1. Disciplined Agile Outsourcing: Making it Work for Both the Customer and the Service Provider Scott W. Ambler Senior Consulting Partner scott [at] @scottwambler
  2. 2. © 2015-2016 Disciplined Agile Consortium Agenda •  Some Housekeeping •  Agile and Outsourcing? Really? •  Disciplined Agile Delivery (DAD) •  Common Agile Outsourcing Pitfalls •  Intuition Fails You •  Disciplined Agile Outsourcing Strategies •  Parting Thoughts
  3. 3. For the Certified Disciplined Agilists among us… This webinar counts as one hour towards your education time to maintain your certification See for details © 2015-2016 Disciplined Agile Consortium
  4. 4. •  Everyone is on mute •  To ask a question, please submit it into the chat box •  At the end of the webinar I will answer as many questions as I can •  It is likely that I won’t get to all of your questions. In that case I will soon post a blog at answering them © 2015-2016 Disciplined Agile Consortium
  5. 5. The Survey Results Shared in This Presentation •  All surveys were performed in an open manner •  The questions as they were asked, the source data, and a summary slide deck can be downloaded free of charge from © 2015-2016 Disciplined Agile Consortium
  6. 6. Some Assumptions •  For the most part I’ll be speaking from the point of view of: –  A customer in North America or Europe –  A project being outsourced to an Indian service provider •  But, I will still cover: –  The service provider perspective –  Outsourcing in general, not just offshoring © 2015-2016 Disciplined Agile Consortium
  7. 7. © 2015-2016 Disciplined Agile Consortium Agile and Outsourcing? Really?
  8. 8. Why Agile Outsourcing? Customer’s Viewpoint •  Augmenting their ability to deliver •  Better, faster, cheaper IT delivery •  Want similar or better quality than what their own IT people would deliver •  The solution must work in their environment © 2015-2016 Disciplined Agile Consortium
  9. 9. Why Agile Outsourcing? Service Provider’s Viewpoint •  Increase business •  Deliver what was promised •  Reduce development costs •  Retain staff © 2015-2016 Disciplined Agile Consortium
  10. 10. BUT…. © 2015-2016 Disciplined Agile Consortium We’re not sure the service provider can work in an agile manner The customer’s procurement process forces us into a more traditional approach
  11. 11. The IT Outsourcing Market in General •  Computer Economics Inc. 2015 IT Outsourcing Statistics: –  Large organizations spend 7.8% of their IT budget on outsourcing –  Mid-size organizations spend 6.7% –  65% of organizations that are outsourcing application hosting intend to increase spending on that •  Deloitte’s 2014 Global Outsourcing Survey: –  53% of organizations are outsourcing some of their IT function –  26% of respondents who do not outsource today plan to –  79% of respondents DO NOT believe their service providers are too expensive –  49% of respondents say their service providers are reactive vs proactive –  Outsourcing activity is expected to increase © 2015-2016 Disciplined Agile Consortium
  12. 12. Half of organizations who are “doing agile” are also involving outsourcing in some way © 2015-2016 Disciplined Agile Consortium Source: 2013 Agile Outsourcing survey
  13. 13. Why is your organization outsourcing? (Multiple selections allowed) 3% 6% 9% 9% 16% 19% 19% 34% 69% No IT department Business frustrated with quality Business frustrated with value delivered Experimenting with outsourcing Internal IT focuses on new technologies Business frustrated with schedules Lack of IT experience technologies Business frustrated with IT cost Short of IT staff © 2015-2016 Disciplined Agile Consortium Source: 2013 Agile Outsourcing Survey
  14. 14. In general, how well do the outsourcer(s) hit their targets? 0% 5% 10% 15% 20% 25% 30% 35% 40% 45% Produce High Quality Reduce Time to Delivery Improve ROI Improve Stakeholder Satisfaction Greatly Agree Agree Neutral Disagree Greatly Disagree © 2015-2016 Disciplined Agile Consortium Source: 2013 Agile Outsourcing Survey
  15. 15. Common Outsourcing Pitfalls •  Organizational culture differences •  Expectations mismatch between the customer and the service provider •  The customer underestimates difficulty of managing outsourced projects •  Total cost of the solution isn’t considered •  Total value of the solution isn’t considered •  Transition to the operations team is mismanaged •  Over-reliance on documentation •  Software licensing issues •  Learning curve for service provider underestimated •  The service provider is understaffed •  Some aspects, e.g. security, cannot be outsourced •  Intellectual property (IP) rights •  Technology connectivity •  Solution doesn’t fit into organizational ecosystem © 2015-2016 Disciplined Agile Consortium
  16. 16. © 2015-2016 Disciplined Agile Consortium Ad Hoc Traditional Agile Iterative 48% 55% 55% 59% 65% 69% 73% 74% 72% 73% 79% 80% 62% 66% 70% 71% Average Co-located Near Located Far Located Success Rates Fall as Geographic Distribution Rises Source: 2009 IT Project Success Survey
  17. 17. Common Agile Outsourcing Pitfalls •  The customer procures the “agile” project via traditional strategies •  The customer takes a Water-Scrum-Fall approach •  The customer governs the service provider via a traditional approach •  The customer really isn’t agile •  The service provider really isn’t agile •  Neither are agile •  Agile is based on trust, yet it behooves you to not trust the service provider © 2015-2016 Disciplined Agile Consortium
  18. 18. Common Geographic Distribution Pitfalls •  Communication challenges •  Time zone differences •  Cultural differences •  Customer unwilling to invest in travel © 2015-2016 Disciplined Agile Consortium
  19. 19. 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 © 2015-2016 Disciplined Agile Consortium
  20. 20. High Level Lifecycle The DAD framework supports 4 delivery lifecycles – Choice is good! © 2015-2016 Disciplined Agile Consortium
  21. 21. DAD is Goal-Driven, Not Prescriptive © 2015-2016 Disciplined Agile Consortium
  22. 22. Intuition Tells You To… 1.  Negotiate a fixed price 2.  Follow a comprehensive procurement strategy 3.  Save money through travel reduction 4.  Define detailed requirements up front 5.  Have long iterations 6.  Manage remotely 7.  Adopt artifact-based “quality gates” 8.  Perform acceptance testing at the end 9.  Hand-off the solution to your team at the end 10.  Outsource things you’re not good at 11.  Keep Inception and Transition in-house © 2015-2016 Disciplined Agile Consortium
  23. 23. But It is Much Better To… 1.  Adopt variable funding 2.  Procure an agile team 3.  Travel at key points throughout the project 4.  Evolve requirements throughout the project 5.  Have short iterations 6.  Collaborate closely 7.  Govern agilely 8.  Test throughout the project 9.  Have a gradual hand over 10.  Succeed locally first 11.  Actually outsource the work © 2015-2016 Disciplined Agile Consortium
  24. 24. Procure an Agile Team The biggest single source of risk in agile IT outsourcing is the customer’s procurement process •  Our advice: –  Involve people in the procurement effort with actual experience in disciplined agile strategies –  Make it very clear at the beginning that you are looking for agile-experienced teams –  Explicitly describe how your team and the service provider’s team will work together •  Resources: – – © 2015-2016 Disciplined Agile Consortium
  25. 25. Strategy: Adopt Variable Funding •  Lowers financial risk and offers a greater chance of project success •  Requires greater project governance © 2015-2016 Disciplined Agile Consortium A fixed price contract is the riskiest way to fund an IT project
  26. 26. Strategy: Travel •  Get key people together physically: –  During Inception for initial modeling and planning –  Key project milestones, particularly project viability reviews •  Throughout the project: –  “Ambassadors” fly between sites to improve communication –  Consider bringing key developers to the customer site to observe the actual work environment and to interact with real stakeholders –  Consider flying key stakeholders, or proxies, to the development site •  Reduces communication risk on your project –  BUT, travel costs are easy to measure therefore are first to be cut The cheapest way to pay for travel is to actually pay for travel © 2015-2016 Disciplined Agile Consortium
  27. 27. Strategy: Evolutionary Requirements •  The challenges with detailed requirements specifications: –  Documentation is the least effective way communicating information –  A “big requirements up front (BRUF)” approach has been found to lead to the development of functionality that is unused (45% average) or rarely used (19%) – Chaos Report 2003, Standish Group –  You still have the CRUFT dilemma (see •  Disciplined agile teams will: –  Produce a high-level definition of the scope –  Explore detailed requirements on a just in time (JIT) basis throughout the project –  Allow the requirements to evolve as the stakeholders understanding evolves –  Acceptance test throughout the project © 2015-2016 Disciplined Agile Consortium
  28. 28. Strategy: Short Iterations •  Long iterations generally lead to mini-waterfalls, which in turn brings on many of the inherent risks of traditional development •  Shorter iterations: –  Require the development team to work in a very disciplined and efficient manner –  Provide more opportunities for visibility into what’s actually being produced, thereby enabling better governance by the customer –  Require the customer to be actively involved with the project Adopt iterations of one or two weeks in length at maximum © 2015-2016 Disciplined Agile Consortium
  29. 29. Strategy: Collaborate Closely •  Observation: –  It is critical for agile teams in general to have ready access to stakeholders or stakeholder proxies (such as Product Owners) –  It is incredibly difficult for service providers to learn your domain, your existing IT ecosystem, and your organization structure –  It is even harder to do so from the other side of the planet •  Recommendations: –  All types of stakeholders, on both the business and IT side, need to be available on a daily basis at least electronically –  Consider embedding key stakeholders (or proxies) with the development team © 2015-2016 Disciplined Agile Consortium
  30. 30. Strategy: Govern Agilely •  Observations: –  The motivations of service providers are different from those of customers –  Customers really shouldn’t trust the service provider •  Recommendation: –  Trust but verify –  Embed one or more of your people with the development team –  The service provider should adopt tools which support development intelligence (DI) –  The customer should have live access to DI project dashboards –  The service provider should include code analysis tools as part of their continuous integration (CI) strategy –  Progress should be judged on the basis of regular delivery of a consumable solution © 2015-2016 Disciplined Agile Consortium
  31. 31. Strategy: Test Throughout the Project © 2015-2016 Disciplined Agile Consortium Iteration N Iteration N+1 Parallel Independent Testing Working build Defect reports The development team adopts a whole-team testing strategy, ideally taking a test- driven development (TDD) approach. In parallel, the customer’s test team performs exploratory testing, pre- production system integration testing, acceptance testing, and so on.
  32. 32. Strategy: Gradual Hand Over •  Observations: –  Hand-over of the solution, for operations and potentially continued development, is very risky –  Documentation is required to support this, but is a poor way to communicate •  Recommendations: –  Co-locate key members of the sustainment team with the development team later in the lifecycle –  Have key members of the sustainment team be actively involved with acceptance testing aspects of independent testing © 2015-2016 Disciplined Agile Consortium
  33. 33. Strategy: Succeed Locally First •  Observations: –  Outsourced projects are generally higher risk than local projects –  Outsourced projects generally require greater skill to manage and govern •  Harsh question: –  If you’re struggling to succeed when the development team is “down the hall” from you, what makes you think you can succeed when the development team is on the other side of the planet? •  Recommendation: © 2015-2016 Disciplined Agile Consortium
  34. 34. Strategy: Actually Outsource the Work •  Observations: –  With offshoring, the expensive people work for the customer organization –  The service provider should have greater expertise at IT delivery than you do (if not, why are you working with them?) •  Recommendation: –  If you’re going to outsource, then outsource –  Put as much of the work into the hands of the service provider as possible –  Reduce as much of the customer work as possible –  The customer still needs to initiate and then govern © 2015-2016 Disciplined Agile Consortium
  35. 35. © 2015-2016 Disciplined Agile Consortium
  36. 36. Agile Development Practices for Outsourcing •  At a minimum: –  Continuous Integration (CI) –  Developer regression testing –  Parallel independent testing (by the customer) –  Short iterations –  Development intelligence (automated dashboard) –  Co-located Product Owner •  Additionally: –  Continuous Deployment (CD) –  Acceptance Test Driven Development (ATDD) –  Developer Test Driven Development (TDD) © 2015-2016 Disciplined Agile Consortium
  37. 37. When Disciplined Agile Outsourcing Makes Sense •  You are already successful at insourced agile •  You understand and accept the risks involved with outsourcing •  You are prepared to address those risks © 2015-2016 Disciplined Agile Consortium
  38. 38. What is the current status in your organization regarding agile and outsourcing? (Single selection) Didn't work well, giving up Don't know Didn’t work well but still trying Starting to reshore and bring work Works well, going to continue Too early to tell Works well enough, going to continue 0% 3% 8% 11% 14% 22% 42% © 2015-2016 Disciplined Agile Consortium Source: 2013 Agile Outsourcing Survey
  39. 39. Thank you – Questions? •  Scott Ambler + Associates – – @scottwambler •  Disciplined Agile Delivery: A Practitioner’s Guide, by Scott Ambler & Mark Lines •  Introduction to Disciplined Agile Delivery: A Small Team’s Journey, by Mark Lines and Scott Ambler • • •  DAD LinkedIn Discussion Group: –
  40. 40. Shuhari and Disciplined Agile Certification At the shu stage you are beginning to learn the techniques and philosophies of disciplined agile development. Your goal is to build a strong foundation from which to build upon. At the ha stage you reflect upon and question why disciplined agile strategies work, seeking to understand the range of strategies available to you and when they are best applied. At the ri stage you seek to extend and improve upon disciplined agile techniques, sharing your learnings with others. © Disciplined Agile Consortium 40
  41. 41. Disciplined Agile Delivery (DAD) Disciplined Agile Delivery: The Foundation for Scaling Agile © 2015-2016 Disciplined Agile Consortium Scrum LeanKanban Unified Process Agile Modeling And more…“Traditional”DevOps Team Size Geographic Distribution Compliance Domain Complexity Technical Complexity Organizational Distribution Team Culture Organizational Culture DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner.
  42. 42. Scott Ambler + Associates is the thought leader behind the Disciplined Agile Delivery (DAD) framework and its application. We are a boutique IT management consulting firm that advises organizations to be more effective applying disciplined agile and lean processes within the context of your business. Our website is We can help © 2015-2016 Disciplined Agile Consortium