Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog


View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

Embracing Mindset Diversity in Disciplined Agile

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

Can You Outsource and Still Be Agile?

Categories: Outsourcing, scaling

We often hear that agile software development is fine for small co-located teams, but that you couldn’t possibly take an outsourcing approach with agile.  The customer organizations would love to do agile but are convinced that vendors are unable to do so, and the vendor organizations typically say they’d love to be agile but that the customers don’t ask them to work that way.  It’s a fair question to ask if agile and outsourcing are being combined in practice, so we decided to look into this issue.

The following diagram summarizes the responses to our question from our 2016 Agility at Scale study around whether agile teams were organizationally distributed (one of the tactical scaling factors potentially faced by agile teams).  As you can see, over half of agile teams are organizationally distributed in some way, with 58% of agile teams including contractors, consultants, or outsourcers in some way.  Interestingly, about one agile team in six includes outsourcing.

Agile and outsourcers, contractors, and consultants

Answering the question of how to be successful at agile and outsourcing is worthy of a detailed article in its own right, something we’ll do in the near future.  Until then, here are some initial thoughts based on our observations at multiple organizations around the world:

  1. It starts with procurement.  If you want a service provider to provide a team that is capable of working in an agile manner then that is what you need to procure.  A traditional procurement process that is looking for a team to work from a detailed requirements specification up front, that is expected to focus on development and then hand off their work for another team to perform “final testing”, is pretty much hobbled from the very beginning.  It is very possible, and highly desirable, to have a procurement process that is capable of procuring agile software development services.  In fact, there is a wealth of knowledge out there about agile contracting if you choose to look into it.
  2. The customer must work in an agile manner.  There are several key strategies to support this:
    • Negotiate how you will work together up front.
    • Take a light-weight, evolutionary approach to requirements.
    • Provide a technical roadmap.
    • Fly a few key people to the service provider.
    • Consider co-locating your Product Owner with the service provider.
    • Provide your development guidelines to the service provider.
    • Actively govern the team.
    • Respect the service provider.
  3. The service provider must work in a disciplined agile manner.  There are several key strategies to support this:
    • Be trustworthy.
    • Be truly transparent.
    • Have one-week iterations/sprints.
    • Include code analysis tools in your builds.
    • Provide the customer access to your team’s automated dashboard.
    • Align your culture to that of the customer.

We will write a more detailed article that expands on these points in the near future.  Stay tuned!

Related Posts

Posted by Scott Ambler on: March 03, 2017 05:23 AM | Permalink | Comments (0)

Agile Offshoring Q&A

On April 19 Disciplined Agile Consortium ran a webinar entitled Disciplined Agile Offshoring: Making it Work for Both the Customer and the Service Provider (follow the link for the recording and other stuff).  During the webinar we received a lot of very good questions, most of which we were able to answer.  We’ve decided to write up the answers to these questions here.   We’ve organized the answers into the following topics:

  1. Product Owners
  2. Testing
  3. Measurement
  4. Common Pitfalls
  5. Miscellaneous

Product Owners

Ideally, what will be the Product Owner and Team Leader’s location in outsourced agile team? Can a Delivery Manager role be infused?  The Team Lead and Product Owner (or a proxy) should be on site with the development team. Many times, however, the PO is located with key stakeholders who are rarely at the same location as the development team. In this case there will be a need for a proxy, either a business analyst or better yet a (Junior) Product Owner at the site with the team who interacts with the (Chief) Product Owner regularly. You will likely need to apply the Ambassador strategy and have people fly between locations regularly.

Do most successful outsource agile projects have a product owner (junior or otherwise) and team lead role at all sites?  I would suggest that. The team needs someone who can answer questions regularly. The (Chief) PO needs to interact with stakeholders regularly.


What is included in the scope of the Outsourced Work? Should it include system testing and QA testing?  This depends on what the contract calls for. It is possible to outsource most of the testing effort if you choose to.

What cannot be outsourced apart from UAT/Integration Testing?  Actually, you could probably outsource a lot of your integration testing effort if you choose to do so. User Acceptance Testing (UAT) needs to be done by stakeholders and those people work for the customer organization, not the service provider.

When you’re working for outsourcer, I think it is better to do manual test, to see all bugs before than spend time on automating tests. Is automated test writing always better than manual testing? I think we lose the time on automation.  Automation of yours tests, or I guess more accurately your checks, is absolutely critical to your success. You can’t afford to not automate as much of your testing as possible. Yes, some testing will be manual at first, but once you understand how to run the test manually you should be able to automate it in most instances.


What the metrics to evaluate the outsourced agile delivery?  This depends on what your priorities are. Are you trying to improve time to market? Quality? Return on investment (ROI)?   What you measure will be driven by what you’re trying to achieve. We’re a firm believer in an agile approach to GQM.

How to measure the performance of team during outsourced agile delivery?  Once again, it depends. A very good strategy is to include code analysis tools in your continuous integration (CI) strategy that provide the customer with real-time insight into the quality being delivered by the service provider.

Are Development Intelligence (DI) dashboards and code analysis tools something the consumer should expect the Service Provider to have and be using, or is this something that the Consumer needs to acquire and then share with the Service Providers?  It would be incredibly foolish not to use such tools. There are many very good ones available free of charge via open source, as well as some very good commercial tools.

Common Pitfalls

Apart from sending ambassadors, can you suggest any other approaches to eliminate cultural differences and we-they attitude?  The only way to reduce cultural differences is to work closely together.  If you’re not willing to spend at least some money on travel then I would seriously question why you’re doing offshoring at all.

What kind of indicators stand out for failing offshoring activities?  The primary cause of failure of an offshoring effort is an inappropriate procurement process by the customer itself. Other failure factors include an inflexible approach to changing requirements, inadequate monitoring/governance of the project, unwillingness to pay for travel, and unrealistic expectations by the customer.


Do you recommend doing development in one place and testing in another?  No. Organizing teams by function injects a lot of overhead, cost, time and risk into your software development efforts. A much better approach is to have a whole team at each location with the skills and resources required to get the job done. Some testing may still need to occur on the customer site of course, but that should be a small part of the overall testing effort.

How can we possibly be called agile when the offshore team is developing while the onshore teams sleep, and vise versa? We fix this with 20 min standups, and heavy process, and using process over comms is by definition, not agile. Should we be happy with water-agile in this case?  You can strive to be as agile as possible in the situation that you find yourself in. As you learned in the webinar there are many strategies that you can apply to become more agile. You might also find our article on Agile GDD to be of interest.

How do you encourage a move away from sign-offs?  There isn’t an easy answer to this one. It is quite common for us to work with organizations to help them to evolve their IT governance strategy to be more agile in nature. We often coach and mentor IT governance people to help them to move away from signing off on artifacts to a more light-weight, risk driven approach. My suggestion is to contact us for help.

Can you share any successful case study in more details?  You can find some fairly easily via a quick web search.

Posted by Scott Ambler on: April 27, 2016 02:48 PM | Permalink | Comments (0)

Disciplined Agile Outsourcing: Making it Work for Both the Customer and the Service Provider

IT Outsourcing

On June 25, 2015 we gave a webinar entitled Disciplined Agile Outsourcing: Making it Work for Both the Customer and the Service Provider (click on the link to see the slides on Slideshare).  We will likely run the webinar again as it was very well received.  We had hoped to record it but unfortunately weren’t able to save the file because the software crashed.  Hopefully it will work out next time.  During the webinar we promised to write a blog summarizing it and addressing any remaining questions from the audience.  This is that blog.

Agile and Outsourcing?  Really?

There are good reasons why organizations are taking an agile approach to outsouring IT delivery projects.  The following table overviews the motivation and concerns of both customer organizations and service providers.

Table 1. Comparing the Viewpoints of Customers and Service Providers

  Customer Service Provider
  • 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
  • Increase business
  • Deliver what was promised
  • Reduce development costs
  • Retain staff
Primary Concern Not sure the service provider can work in an agile manner The customer’s procurement process forces them into a more traditional, and riskier, approach

Here are some interesting statistics about outsourcing:

  • Gartner’s 2014 IT Outsourcing report estimated IT outsourcing to be $288 billion in 2013 and to grown by 5.9% compounded annually from 2013 through 2018.
  • Deloitte’s 2014 Global Outsourcing survey found that 53% of organizations are outsourcing some of their IT function; 26% of respondents who do not outsource today plan to do so (supporting Garter’s growth forecast); 79% of respondents DO NOT believe their service providers are too expensive; 49% of respondents say their service providers are reactive vs proactive (e.g. they are basically order takers, not partners); and IT outsourcing activity is expected to increase.
  • The Ambysoft 2013 Agile Outsourcing survey found that half of organizations who are “doing agile” are also involving outsourcing in some way

The Challenges Associated with Agile IT Outsourcing

Here are some common pitfalls that organizations run into with IT outsourcing:

  • 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

Here are some common pitfalls with agile IT outsourcing:

  • 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

Here are some common pitfalls with geographically distributed teams:

  • Project success rates drop as geographic distribution increases
  • Communication challenges
  • Time zone differences
  • Cultural differences
  • Customer unwilling to invest in travel

How Disciplined Agile Delivery Supports Outsourcing

Disciplined Agile Delivery (DAD) provides several important mechanisms which enable agile IT outsourcing:

  1. Flexible, process goal driven approach.  A team where the work has been outsourced to them will work differently than an insourced team.  A globally distributed team will work differently than a co-located team.  To be successful at agile IT outsourcing you need to adopt a process that is sufficiently flexible to meet the needs of the situation that you face.  DAD’s process goal-driven strategy provides this flexibility while being easy to tailor.  Context counts.
  2. Hybrid framework.  The DA toolkit is a hybrid that adopts strategies from a variety of sources, including Scrum, Extreme Programming, Agile Modeling, Unified Process, Kanban, SAFe, traditional sources, and many more.  As a result it provides the robust advice that you require to address the complexities of agile outsourcing.  Choice is good.
  3. Full delivery lifecycles. The DA toolkit supports four full delivery lifecycles – An agile Scrum-based on, a Lean Kanban-based on, an exploratory Lean Startup lifecycle, and a continuous delivery lifecycle – that show how to approach IT delivery from beginning to end in a streamlined and lightweight manner.
  4. Risk-value lifecycle.  The DA toolkit explicitly includes proven risk reduction techniques in its delivery lifecycles.  These strategies include coming to a stakeholder vision early in the lifecycle, proving the architecture with working code, and delivering a potentially consumable solution on a regular basis.
  5. Enterprise awareness.  The DA toolkit promotes the philosophy of enterprise awareness – DAD teams should do what’s best for the customer organization, not what is convenient for them.  This means that delivery teams should adopt organizational conventions whenever appropriate, reuse existing assets (including legacy data sources), follow the organization’s business roadmap, and follow the technology roadmap.
  6. Explicit governance.  The DA toolkit explicitly address how to govern agile teams.  The increased risks associated with outsourcing require a more sophisticated approach to governance than what you would require for an insourced delivery team.

Disciplined Strategies to Make Agile Outsourcing Work

Our experience is that the reason why many customer organizations struggle with agile outsourcing is because their intuition (which typically reflects the traditional mindset) leads them astray.  The following table indicates what traditional intuition often leads you to do and the corresponding disciplined agile strategies that we recommend.

Table 2. Traditional intuition vs. what you should actually do.

Traditional Intuition Disciplined Agile Strategy
Negotiate a fixed price – The desire is to reduce financial risk, but this typically results in scope being dropped or the development team making it very difficult/expensive for stakeholders to evolve their requirements over time. Adopt variable funding – Variable funding strategies, such as stage-gate, time and materials, or cost plus, prove to be lower risk in practice (albeit at the cost of slightly more sophisticated governance).
Follow a comprehensive procurement strategy – The greatest source of risk on an agile IT outsourcing project is how most customer’s procurement strategies are misaligned with the way that agile teams work. Procure an agile team – If you want an agile team, then procure one via a contract that reflects the strategies discussed here.  Most IT outsourcing contracts tend to reflect traditional ways of thinking which thereby inject significant risk into agile outsourcing engagements.
Save money through travel reduction – This typically increases the time, cost, and risk associated with decision making and communication. Travel at critical points throughout the project – Disciplined agile teams will get at least their key people together at critical points (initial modeling, initial planning, major milestones) so that they can quickly address the concerns at the time in a low risk, face-to-face (F2F) manner.
Define detailed requirements up front – Stakeholders are not good at describing what they want, so any effort to baseline detailed requirements early in the lifecycle will inject significant risk into your project. Evolve requirements throughout the project – It is natural for people to change their minds, particularly after they’ve seen something built.  The implication is that we need to work in a way that embraces changing requirements instead of trying to prevent changes.
Have long iterations – This results in longer feedback cycles which in turn increases the risk of building the wrong thing. Have short iterations – Short iterations result provide more opportunities for the customer to monitor and steer the effort, thereby driving down risk.
Manage remotely – This makes it harder to know what is happening “on the ground”, increasing overall risk. Collaborate closely – Close, respectful collaboration is what makes agile work.
Adopt artifact-based “quality gates” – This proves to be a governance façade in practice.  The true measure of progress should be the delivery of high-quality, consumable solutions over time. Govern agilely – Agile teams should be governed in an agile manner.  With outsourced teams, we recommend that the you insist on the team adopting the practices of continuous integration (CI), development intelligence (automated project dashboards), code analysis (to ensure conformance to corporate coding conventions and to measure code quality), and lightweight milestones from the very beginning.  The team’s automated dashboard should be available to the customer organization, thereby giving them the real-time insight that they require to govern effectively.
Perform acceptance testing at the end – This increases the average cost of fixing any defects found, thereby inject both cost and risk into your project. Test throughout the project – Disciplined agile teams follow practices such as whole team testing and parallel independent testing (as appropriate) throughout the entire lifecycle, not just at the end.
Hand-off the solution to your team at the end – Any time there is a hand-off between two teams there is an opportunity for misinterpretation. Have a gradual hand over – If you are going to do a hand-over, do so gradually be involving members of the sustainment team in the construction effort.
Outsource things you’re not good at – The idea is that you should focus on what you’re good at and outsource the rest.  However, if you’re not good at something then how likely are you to have the skills to govern it effectively? Succeed locally first – If you’re not good at agile development when the team is down the hall from you, what makes you think you’ll succeed at it when the team is on the other side of the planet?
Keep Inception and Transition in-house – This approach tends to require heavy investment up front and back end work performed by expensive staff. Actually outsource the work – It is in fact possible for the service provider to take on the vast majority of the work.  This pushes work into the hands of lower cost people while reducing the overhead and risk associated with getting disparate teams to work together.


When Disciplined Agile Outsourcing Makes Sense

We’ve found that for agile outsourcing to be successful you must first meet all three of the following criteria:

  1. You are already successful at insourced agile.
  2. You understand and accept the risks involved with outsourcing.
  3. You are prepared to address those risks.



Posted by Scott Ambler on: June 29, 2015 12:29 PM | Permalink | Comments (0)

"When angry, count to four; when very angry, swear."

- Mark Twain