Embed Size (px)
DESCRIPTION
Many software development organizations work within the bounds of contractual agreements where the limitations imposed by the “Iron Triangle” of fixed timelines, budgets, and scope challenge their ability to embrace change and focus on value delivery. Agile practitioners often comment that agile contracting is a difficult problem, but proven solutions are rarely presented. Rachel Weston and Chris Spagnuolo offer some tools they have used in their own agile contracting work to help agile practitioners deal with different contracting scenarios while promoting agile practices, protecting the development organization, and still providing value and protection to the client’s organization. Through a combined workshop and facilitated collaborative session, Rachel and Chris present new agile contracting tools that can be added to your toolbox. You will gain a deeper understanding of the problems associated with agile contracting as well as practical solutions for dealing with contracts in an agile manner.
Citation preview
Agile Contracting - Agile 2008 - Chris Spagnuolo and Rachel Weston
Agile ContractingChallenges
Proposals and MarketingNon-agile competitionSales and marketing don’t understand agilePurchasing office review of proposalUnrealistic budgets/schedules
RiskFinancial risks for both clients and contractorsExposure risk for clients
Change ManagementFixed scope contracts while welcoming changeContract negotiations and change requestsFixed delivery date for specified functionality
Conflicting Client PracticesNon-agile client reporting requirementsRequired joint development teamsInvoicing requirements
Client InvolvementClient not able to handle their responsibilityClient organization can’t handle the pace of agileDelayed acceptance feedback loopsLack of attendance at reviews/demosLow user testingStand-ups without clientProduct owner involvementLack of client focusProduct owner not representative of stakeholders
Contractor ResponsibilityDistributed teamsInconsistent iterationsFaking agileGetting the client involved
Project CloseoutOut of budgetThe definition of done…done.Poor transition planning
Agile Contracting - Agile 2008 - Chris Spagnuolo and Rachel Weston
Agile ContractingStrategies
Proposals and MarketingHit the waterfall problem upfront in proposalsTrain sales and marketing in agileIntroduce agile on smaller pilot projectsEducate in your proposalsUse the agile engagement roadmapCite agile statistics
RiskPropose a shared risk model and demonstratethe benefits of this to the client
Change ManagementFocus on bigger boxes, looser scope contractsOpt for flexible scope over T&M when you canDefine scope boundaries with product vision, product roadmaps, and release plansUnderstand and use your velocity to provide eitherscope or schedule estimatesBuild in slack with full disclosure
Conflicting Client PracticesBuild agile education for clients into your contractsClearly define the overhead for non-agile reportingrequirements
Client InvolvementClearly define client roles andresponsibilities in your contractIdentify the product owner role in the contract
Project CloseoutProvide a clear definition of done in your contractDetermine and provide the cost of knowledge and tech transfer in your contract
Agile Contracting - ADP 2008 - Chris Spagnuolo and Rachel Weston
Agile Contracting/ProposalLanguage Sample
In our agile approach, budget and time select the requirements that can be delivered. Our clients have the ultimate project control and may declare their satisfaction with the application as a whole at any time in the development process. Our clients can decide that although there is budget remaining, the delivery team has met their objectives and can call the project complete.
On the flip side, although the total budget may be expended on this project, and all backlog items may not have been developed, our clients are guaranteed to have live, working functionality that is of the highest value to them due to the constant inspection and adaptation of the project backlog.
