Our group had a great discussion about our experiences when trying to use Scrum and Agile practices in a contracting relationship. We brainstormed a list of Challenges/Risks and a list of Strategies. Although some of the items in the Challenges/Risks list led to suggestions or descriptions of positive experiences for the Strategies list, there is not a precise correlation between the two lists. Therefore, I decided to keep them separated. Hopefully they are useful in this format.

Challenges/Risks

• Consultant financial risk vs client financial risk
• “Guaranteed” delivery of "y' by "x" date while “welcoming change”
• Client’s contracting process – conflicts with how we want to work (Agile)
• Schizophrenic Scrum Master trying to serve team and client’s need for PM
• Multiple projects for single PM
• Additional roles like PO and PO Proxy seem excessive to client
• Client’s reporting requirements
• Bid process limits ability to start with Agile Practices (we know too little)
• Determining scope of project within budget constraints
• Lost bids to companies that overpromise
• Picking lowest bidder on RFP
• Joint development team
• Distributed teams and coordination
• The client wants their staff on team but contractor to still be responsible for software quality
• Working with a non-Agile/Scrum team at client we have dependencies on
• Company team members not interested in Scrum/not playing nice
• Visibility Scrum creates can reveal things about client that they don’t want to know
• Lack of user testing (UAT)
• Purchasing review of contract negates all the work done to get Agile stuff in contract
• Client organization can’t keep up with pace of Scrum
• Changing the contract every time we change the backlog
• Scrum sometimes perceived as putting all the risk on the client
• Build Agile understanding in sales
• The challenge of incorporating "Team Setup" time into the schedule to the detriment of "Functionality" delivery (see model below)

Strategies

• Define PO role requirement in contract
• Recognize and account for in contract the overhead of conversion of information to clients requirements/documentation
• Limit initial engagement length to determine initial scope and project length – phased approach
• Later winning bids after other companies underdeliver
• Clarifying definition of Done with client
• Try to get the client to argue about what they want to prove they don’t know
• Get enough time approved to start Phase I and do a couple of sprints to demonstrate progress and establish velocity
• Help them understand the benefits of Scrum/Agile
• Using buckets of themes of work, client decides how much budget per bucket, can pour between buckets any time
• Managing lingo and language – acquiesce to what the client wants
• Reserve hours/buffer beyond initial scope to allow for flexibility and change
• Train the client as early as possible - time must be built into contract
• Giving the client some “Agile crack”  and getting them hooked on it (for free)
• Build contract based on Vision and Roadmap of releases with high-level themes so delivery is "guaranteed" but flexible
• In contract – have target scope open to continuous refinement
• Contract describes clearly the incremental delivery and required client participation in prioritization and demo and review
• Build trust!
• Colocation of joint development teams
• Create a bridge between Agile/Scrum elements and client's traditional elements
• Use the visibility that Scrum provides to call attention to challenges
• Build knowledge transfer and project close process into contract – can be traded for more stories if project continues, etc.
• Involve someone at the client who can help really translate deliverables into business value (e.g. sales)
• Client needs to dedicate people and “put their skin in the game”
• Put definition of Done in contract
  • Maybe release or other level so team can still develop their own
• Put user testing requirements of client in contract
• Having someone who understands Agile involved in contract process (minimum: contractor; better: also client)
• Ask the questions about the client contracting process up front to mitigate downstream risks (purchasing/legal)
• Keep the contract as simple as possible – just enough to protect both sides equitably.  Put the detail somewhere else.  Keep the “how” we deliver out of the contracts
• Put ranges in backlog that indicate likelihood of delivery.  E.g. “the line of hope”
• If client really wants waterfall, faster to do that than to attempt some “hybrid”
• If you end up doing bad Scrum, admit it and stop it, even if it means doing waterfall instead
• Study our success, write case studies and whitepapers
• Grow the Agile coaching community

I will be cross-posting this list to an Agile Contracting group space I participate in and encourage anyone who is interested in furthering this discussion to visit at: http://agilecommons.org/hives/bfe2f4f471/summary

You will need to create an account on Agile Commons to access it.

Many thanks to all the participants in this Open Space for brilliance, compassion and enthusiasm! And special thanks to George Schlitz for typing up the notes.