Contracting in Agile

US Government Digital Services Playbook and Agile

Was surfing the net and came across this interesting article by US Government (I think) on How to implement end-to-end Web services project. I never expected a Government to publish such level of detailed guidelines as to how cost-effectively projects can be delivered to end users without losing relevance. 

The guidelines consists of 13 "Playbooks" which touches all phases of project management from ideation to support. Play #5 "Structure budgets and contracts to support delivery" talks about

The link can be accessed here.

Play #1 and 2 are entirely driven by Product Owner and more or less interrelated. Play #1 outputs could be something like a Project charter document and Play #2 output could be AS-IS and To-BE process flow diagram along with a Gap analysis document.

Play #3 tries to minimize user training costs and harps on building an intuitives web page, navigation and accessibility. It also focuses on providing certain flexibilities to users to like save and submit later, choice of language, seamless integration of online and offline interactions.

Play #4 talks more about the "How" part and lists guidelines for all team members

Play #5 details out the structuring of contracts and budgets for agile projects. Following qualities are prescribed of a well-defined project

Play #6 and 7 is about building RACI for Product Owner and Team members

Play#8, 9 and 10 provides guidelines identifying the appropriate Development, Deployment and Monitoring stack and Focusses on importance of Automation of Testing activities

Play #11 focusses on ensuring Privacy and Security of sensitive public data. It also recommends establishing processes for users to understand, modify or report privacy / security issues

Play # 12 prescribes some interesting NFR's / Metrics

Play #13 recommends many practices for publishing data publically with the aim to build trust and improve governance

I have always wondered in the new era of agile, how would IT services contracts, especially the long term ones would be drafted. So, what would happen, if I have signed a Master service agreement and don't want to spend upfront on elaborate requirement and design documentation for a new project OR I have the requirements defined but can't wait till the end of the project to see value delivered and relevancy retained.

Modular contracting can be of some help.

The main questions could include:

1. What is In-scope and Out-of-scope?
2. How do I work with a Rate card given by the contracting agency?
3. Should I encourage a Fixed bid contract for the contracted module or go with Price per Sprint?
4. I have been involving various contracting agencies for different pieces of work (development by one, testing by other). How can I continue doing the same in agile?
5. How do I identify the best bid?
6. How do I identify rewards and penalties?
7. Many more...

Interpreting Agile Manifesto

Agile Manifesto

I like to focus on the third and fourth statements:

"Customer collaboration over Contract negotiation"

"Responding to change over following a plan" 

Here, Contracts and Plans are less important than Customer feedback and Teams working on Customer feedback.

• A very strict interpretation hovers around sprint-to-sprint modularity i.e. a single sprint becomes a modular contract. This, then, creates a lot of pressure on the Product Owner (and team consequently) to carve out user stories having more and more business value and consequently greater scope of work (thick slices)
• A rather lenient (practical) interpretation gives some weightage to contracts and project plans and can have a contract covering a single release (more than one Dev sprint, at least 1 hardening / integration / UAT sprint). In this case contract will be chunkier and will have dates more aligned to Go-To Market / Launch dates. Here, there is less pressure to squeeze-in more scope within a Sprint and Sprint Velocity expectations will also be a little more relaxed and thereby less variable across sprints and teams. As a result, Stories having lesser story points will delivered faster thereby providing an linear burndown. 
• In another twist to the above point, if there are multiple vendors / service providers / contracting agencies providing different services (Dev, Test) then the chunkier contract will need to divided between the vendors so that purchase orders can be traced back to statement of work done by each vendor.  

Nevertheless, in all three possibilities, customer feedback and re-prioritization as a result of it always takes front seat.