Vendor/Client contract folklore

I previously wrote something on juggling scope, schedule, resources and quality: The iron triangle is actually a square and not particularly iron. I learned in ThoughtWorks that you ask the client to find some other vendor when they suggest that quality is the thing that should be limited (in order to meet dates+scope+cost). And that faced with any other permutation the only win-win scenario is to constrain all but scope.

If you attempt to constrain all four, you get salespeople running interference on messaging, and stand to lose in multiple other ways. Invariably change requests come in, which mean the budget by definition has to be unlocked. The outcome is that the vendor gets more fees and the client did not get what they wanted on a number of axes. Then the relationship with the vendor sours and the client seeks to do it differently the next time. Unless they’ve truly learned, differently means exactly the same but with a different vendor (and more checklists).

Me, trying it differently

Of course, I left ThoughtWorks (TW) in 2014, for a Senior Director of Engineering at a hedge fund administrator (later Chief Scientist). Soon enough, like many ex-ThoughtWorkers, I was utilizing TW again for some offshore work. Specifically, a new app that we did not have time to make as all 68 development staff allocated to existing valuable deliverables. An app that, were it deployed to the platform for clients, would be a valuable addition from the moment it was ready.

I remember this experience fondly and would recommend it, hence I’m writing about it.

I penned a delivery contract with ThoughtWorks’ China division to deliver first an application in very fresh technology choices. The Hedge fund administrator’s developers were not so familiar with them, but could expertly write the backend in Python (heavy algorithmic stuff). The ThoughtWorkers in China, like any TW group, could throw themselves into any modern tech and be productive within a day or so. And do so while fitting all the predictable ThoughtWorks ways of working - a fast build including Selenium tests, well factored and fully maintainable code.

The challenge was how to make it pleasant for the TW China team when our leadership (and UX) was 12 hours away in New York (and devs 7 hours away in Dublin, Ireland). That is not just a timezone problem, it is a TCP/IP hops problem, and offshore teams are often disastrously asked to use remote desktops and/or VPNs.

The answer was to make a Technology Compatibility Kit (TCK) for them to use. This meant that we did not have to enroll them in our systems at all, just set them up for success on their own Macs. Each night they’d code stories (typically less than one day each including Selenium tests). Each day we’d write more mock-wire services (in the TCK) or change old ones, and also pen stories for them to chomp through after we went home. Not so much pen from scratch, but just in time elaborate. I’ve written a few times on TCKs (see that category). TW ran their own Continuous Integration to make sure they were progressing using the Service Virtualization in the TCK. We ran our own CI to double check that and also to make sure that the TCK was consistent with the real Python backends that TW did not have access to.

The other key aspect to this was small stories. Averaging a single working day. I’ve written about this a few times (see my ‘small stories’ category).

I say “me trying it differently”, but it was a super lean thinking exec management team, saying “yes, let’s try this and measure its success”. That was key to doing this.

The Contract

Interesting too I think, is what was in the contract.

Vendor will:

• charge us for time and materials only
• not charge after the end of the contract period - the tech would just come back in-house if we didn’t renew
• agree on the roles and seniority of the staff placed on the HedgeServ account
• only work on stories identified in the story tracker
• do work to the highest quality including test automation, and everything guarded by CI.
• (related) would not accumulate “technical debt” as their devs work on features
• co-develop the TCK’s RESTful integration boundaries with us
• not need to VPN or enroll in our systems.
• only need to go on conf calls once a month or so
• make changes to the out written tests and mocks (together: “the TCK”) as needed, but in the style of “what would Paul’s devs do if they were here to ask now”, and we would handle that change in the morning when they did.
• expect us to have elaborated on each story that is ‘ready for development’ on a just in time basis, and as unambiguously as possible.

Of the four jugglable things in the aforementioned blog entry, Resources, Time and Quality were constrained, and the scope was unconstrained. Sure we trusted that ThoughtWorks could work efficiently too, and it all worked out well in the end with the hoped-for scope pretty much delivered. The highlighted bullet above is worth calling out. The China team were explicitly to not deliver the story in play if that night their alternative was to do so AND ALSO accumulate technical debt.

Outcomes

My devs ultimately inherited a fully buildable and perfectly tested application that they could slot into their pre-existing applications for their clients - hedge funds. The ThoughtWorkers in China reported that they enjoyed the mission too.

Going forward, I think I’ll structure all vendor contracts like this, and prefer TW as much as they’ll let me :)