PM Articles > Alan S. Koch > The Agile Customer

The Agile Customer

Making your supplier a bit more Agile

"We are adopting an Agile method for our internal development projects." This student in my Agile Project Management Boot Camp is really beginning to embrace Agility. But ... "But on my project, some of the development work is being done by an outside contractor who is decidedly non-Agile! How can we be Agile when they are not?"

Agility is relatively easy when you control all of the parts of the project. But when others are involved, barriers to Agility can begin to spring up. The best way to overcome those barriers depends upon your situation. So let's explore options for injecting some Agility in spite of the Waterfall raining down on you from your supplier.

Hire an Agile Contractor

The obvious best case would be for you to contract with suppliers who have already embraced Agility. They will understand what you are trying to achieve and work with you to make the iterative lifecycle work to your advantage.

Unfortunately, many of us find ourselves beyond this point in the process. The supplier has already been chosen (by us or someone else) and changing suppliers is either impossible or highly undesirable. Next time, we must be sure to choose an Agile supplier!

But in the mean time, all is not lost on this project. Even though we find ourselves in a less-than-optimal position, we can still make the best of it. We can work with this supplier in a way that will make the relationship a bit more Agile.

Write an Agile Contract

The contract defines expectations with our supplier, so we really need to start there. Most contracts are written with the Waterfall in mind. First there are requirements, then a design, then (at the end of the timeframe) they deliver a product to us for acceptance. If we are to interact with our supplier in a more Agile way, then the contract must not enforce waterfall!

But what if the contract has already been written and signed? Can you say "Contract Mod"? Few contracts go unchanged for their lives. If your contract does not support an Agile approach, then change it. Very few suppliers would balk at a time and materials contract with no fixed deliverables pre-defined. (And if your powers-that-be won't go for the concept of an Agile contract, then you have bigger problems than a Waterfall supplier!)

The key difference with an Agile contract is in the deliverables. An Agile relationship calls for completely different deliverables than the normal waterfall-ish ones. Our Agile contract must call for Agile deliverables. For example:

  • The supplier will collaborate with us to define a Requirements framework that draws a broad picture of the product they are to build. In addition, they agree to work out the requirement details collaboratively with us as the project progresses.
  • If we feel that up-front design work is necessary for the type of product they are building, then the supplier must deliver an architectural framework (without all of the design details). This framework must provide enough detail so we can ensure that anything we are building will fit together with what the supplier will deliver to us.
  • The supplier must deliver a product deliverable to us for acceptance every month or two, beginning no more than two months after the requirements and architectural frameworks are complete. If the supplier is stuck in the waterfall, we must ensure that the earliest product deliverables are things they are capable of building. For example, most suppliers can build the main User Interface or workflow screens with no actual processing code or database undergirding it.
  • At the beginning of each of those month-or-two chunks of work, the supplier will collaborate with us to define precisely what they are to deliver in that time box, including the details of the requirements.
  • If this supplier's product must integrate with other software that we are developing, then these interim product deliverables must build up to the right set of capabilities at appropriate times in the project.

An Agile contract must establish time boxes and budget limits, but leave requirements details as the variable for managing the relationship. Ultimately, the supplier will be paid a fixed fee for a fixed timeframe, and will work with us (their customer) to determine precisely what they will deliver.

Be an Agile Customer

We are used to being the supplier for our customers. But when it comes to our supplier, the shoe is literally on the other foot. They are the supplier, and we are the customers. That means that we are the "single wring-able neck" that Ken Schwaber talks about in the Scrum book.

If we are successful at establishing an Agile contract with our supplier, that means that they will be delivering what we asked for. And that means that we must be asking for the right things! If we end up with the wrong product at the end of the project, it is because we have not been diligent in providing feedback to our supplier about each deliverable.

The other part of being an Agile customer is making the hard choices. When things aren't going well (there are technical difficulties, or the things we want take longer to do that we anticipated), then we must decide how to make the project fit into the prescribed time box. What requirements are truly required? And how much (or little) gold plating do we really need? And in the end, if it really will take more time and money to get what we need, we must admit it and pay the piper.

As the project moves forward, we will quickly come to understand precisely what our supplier is capable of delivering, both from a technology and a quality standpoint. This allows us to take any corrective action that is needed early in the project. And in the end, it allows us to get the greatest benefit we can from the contractor relationship while mitigating the risks.

Related Links
Partner Contract Guidelines
When outside partners are employed to execute part or all of a project, the contract with that partner is critical for defining expectations, due dates, and responsibilities. This template provides guidelines for typical contents for such contracts.

Vendor Assessment Checklist
A set of questions to ask a company or contract resource you're thinking of hiring for your project. The questions are aimed at ensuring you have a common understanding and good fit in goals, skills and experience, processes, and priorities. Avoid disaster! Choose your partner well.

Agile Project Management Index Our Agile Project Management resources help you understand and apply agile principles, practices, and techniques to your projects.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Too bad the author did not deliver on the promise to "inject Agile" - it spells out to hire and Agile supplier and does not deal at all with the problem as presented.

Or did I miss something?

Fantastic article!
I have been using the same approach on my current project which has been outsourced to a non-agile supplier. It's great to know that the approach I am taking to the project seems to mirror your thoughts and so far, everything has been working out fine!

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.