Agile contracts

Agile contracts. Those two words together in the title seem incredibly incongruent with Agile, after all, the Agile Manifesto’s third value is:

Customer collaboration over contract negotiation

But this doesn’t mean that you shouldn’t have a contract with a partner or vendor; it just means that the interactions, collaboration and outcomes that you make together should be your primary focus. 

So what does an Agile contracts really look like? What considerations should you bring into your Agile contract? Whether it be an outcome based contract or time and materials, the following are additions you should consider when working with a deliver partner to produce not just software, but real outcomes for customers.

Team Setup

• Be clear on how far through a technical stack a team should be setup to include – eg Partner teams must be setup to deliver customer value work through the full technical stack. In complex, scaled environments Partner teams tend to not be optimised for reduced dependencies. 
• Be clear on which roles you will provide into the team such as Product Owners, Experience Designers, and Service Designers
• How big should be team be? Good team size is 7 +/- 2, but many Agilists think even this is too big.
• Do you need to be explicit around what roles you don’t want a Partner to add? For example, you may not want Test Managers or other leadership roles beyond Scrum Masters.
• How much should a Partner be allowed to move people between teams or taken off the account? Agile teams work because teams are persistent and learn over time how to effectively work together. Naturally there will be exceptions such as where there are personality clashes or capability issues but try to have stable teams.

Skills and capabilities

• What is the approach to dealing with gaps in hard to find specialist capabilities – is it the responsibility of the Partner to address this or will your organisation provide a solution?
• What skills and capabilities (soft or in programming languages) are you expecting of your Partner. Consider where Agile capabilities such as TDD, pair programming, continuous integration and deployment etc. fit in to these expectations.
• What skills and capabilities are you guaranteeing to the Partner – for example, will you ensure that Product Owners are capable in defining Acceptance Criteria in order to support BDD?

Coaching

• Who will be performing coaching – the Partner or your organisation? What is the ratio of coach to the number of teams that you are expecting a coach to support?
• If the Partner is providing coaches how do you ensure quality – do you reserve the right to interview them? Do you have rights to approve or reject them?
• When a coach starts, how to they get up to speed with your preferred way of working? Do they come onshore for a period of time?
• How much flexibility do they have to blend the Partner’s way of working with your own? Do they have to fully comply against an expectation by a certain date (for example, an expected level of Agile maturity)
• How much flexibility do they have in their personal coaching style -is it opportunistic, pathway driven or a combination?

Training

• What Agile training will be provided or required by the Partner for its people? Is there a specific certifying body, level of proficiency or time period that training should be completed by?
• Do you partake in the training to recommend improvements?
• Are you responsible for providing all the content for the trainer or for onboarding the trainer in the delivery approach?

Technology

• What is the minimum upload and download speed that Partner laptops have to meet? Throttling of connections can severely slow down continuous integration in teams and result in teams that avoid checking code in frequently.
• Should each team have a permanent open channel (eg Skype or other) between the Partner and your organisation (to enable real time communication) 
• What other key communication tools should each person have access to? Who provides the licencing for these?

Environment

• Are there minimum expectations of cross over hours for communication? Often teams and Product Owners have only a two hour window (especially between Australia and India) to communicate – this includes all Agile ceremonies and any other discussions about work. This batching of communication causes significant delays in delivery.
• What size of meeting room and video conferencing facilities should be available to Partner teams? Often teams have a room, but it is only big enough to squeeze three or four people into it comfortably. 
• Should all Partner team members (or even tribe) be located in one city and in the same building (or even floor)? Co-location of tribes so that they are seated next to each other is critical to reducing rework and improving speed of delivery.

Tools

• Should Partner team members be  able to access all tools and information from a single device? Single device support enables reduced downtime in switching devices but also importantly reduces the chance of communication batching.
• What Story Management tool should the Partner be using? Who will pay the licence cost and how are they expected to use it? Be careful here, setting expectations that all Stories must be closed by the end of the Sprint will only drive inaccurate reporting. Another example is setting an expectation of no outstanding defects by end of Sprint – it may drive behaviour of teams commenting out test cases or code.
• What expectations/restrictions are there for the Partner to access core tools for coding and source repository?
• What mechanisms exist for Partners to escalate issues with tools, environments and access to data?

Process

• What Agile ceremonies are Partner team members expected to attend?
• What happens if there is a conflict between Partner ways of working and your organisations preferred ways of working?
• Should the Partner be expected to establish team norms (Social Contract) in collaboration with your organisation?
• What metrics is the Partner expected to report on? Don’t make this Velocity, it is the wrong thing despite it being  core Agile metric, look towards speed of features into production with high automated testing coverage.
• What Retrospectives are run at the Partner contractual/relationship management level to continuously improve it?
• How are new Partner teams onboarded with the way of working? Is there an initial incubation period where they are brought onshore to understand your organisation’s culture?
• How fast should delivery impediments be resolved?
• How should a Partner be involved with customer’s and customer testing so that they are aligned with the needs of your customers? 

Culture

• What behaviours are encouraged? For example, raising objections when a problem or solution is perceived to be poorly conceived regardless of hierarchical position
• How can you encourage full transparency of status so that if there is bad news this should be as soon as it is detected?
• What assumptions should the Partner validate with your organisation?
• How empowered is the Partner to solve problems themselves as they arise?
• When visiting the Partner, should you be treated as a customer or a team member? Do you treat them as a Partner or a Vendor?
• How are Partner leaders encouraged to behave with their team members? To what extent to you uphold these values yourself?

Technical Delivery

• What expectations are there for automated tests and the extent of code coverage?
• How often should the Partner be checking in their code?
• On check in, is there an expectation that is is automatically built, re-validated by automated tests and deployed into a test environment?
• Is bespoke code written for the organisation owned by the Partner or yourself?
• To what extent do you expect the Partner to use techniques like Feature Toggling?
• How will the Partner be expected to balance both development and operational support?
• What SLAs exist for production defects?

Testing

• Who is responsible for provision of environments for development and testing?
• How are defects detected within the Sprint expected to be resolved?
•  
• What are the Partner expectations for who does testing and in what environments? Where do stubs get used?

Conclusion

Looking at all of these considerations you can be forgiven to think that this doesn’t seem very Agile at all. Where is the collaborative and trusting mindset? Where is continuous improvement? Yes, ideally these sorts of considerations wouldn’t be needed in an Agile partnership, but on a journey to Agility, some clarity of expectations can be better than standard Waterfall contract agreements.