In the last few years, we have seen a shift in how organization source IT-services. The traditional long-term maintenance agreements are gone. Instead, we see organizations sourcing for resources. Such resources will typically work as part of the customers’ extended team. Digitalization and the “need for speed” is one driver for this change. In a research from Deloitte, 94% of the companies responded that agility is critical to their organizations’ success. Another is the “Spotify model” where the boundaries between IT and business are reduced.
But what is an agile service? And how do we source such services? That is the topic of this article. Just to try to avoid one confusion, I would like to distinguish between sourcing of agile services and agile sourcing processes. Sourcing of agile services is a question about what type of services you buy, and the content of this article. An agile sourcing process is the question about how a particular commercial process is run. You can find more information about this topic at Lean-agile procurement.
Disclaimer: As this is an area under constant evolution, this article will follow agile principles and might be subject to continuous changes. Your input and feedback are very welcome.
First, I like to define a few words and make some clear distinctions between those. An agile project is in this article a temporary social system, with the objective of achieving a particular aim. As we follow the agile principles, the aim might be defined only high-level. The key here is that the agile team is temporary. When the aim is (ideally) achieved, the project is over, and the team shall be disembarked. There can be project for almost everything, like designing a car or doing an Olympic campaign. In this article, I primarily talk about application development projects. The opposite, if I might use such a term, to application development is continuous delivery or DevOps. Here I use these two terms interchangeably, although I acknowledge that they just closely interlinked, but do not mean the same. The main point here is that under continuous delivery or DevOps the agile team is disembarked. It is, as is defined in continuous delivery, a team which delivers at any point of time. An agile DevOps team will in addition to application development also have the responsibility for application maintenance and in some situations also responsible for the infrastructure where these applications run.
The other two phrases I like to define is the difference between buying services and buying resources. In traditional outsourcing agreements, it was common to define specific services (often with uppercase S) and that the vendor had a specific responsibility to deliver such Services. It was not uncommon to have SLA’s and penalties connected to the failure of delivering Services. The kind of opposite to deliver a Service is to only provide resources, often called staff augmentation. In this situation, it is the customer who has the responsibility of the deliverables the team shall create. The responsibility of the vendor is purely to provide the right people. Let me quickly point out that these different delivery models are not directly related to invoice models like fixed-price or time and materials. But that is the topic of a later article.
When a company plan to source for agile services, there are two main questions to ask:
– What is to be delivered? Is it a one-time, temporary project or is it continuous delivery?
– How should the vendor help me? Do I want the vendor to take accountability for the end-result or do I only want resources who are managed by me?
As the figure above shows, both projects and continuous delivery can be sourced either as a Service or as staff augmentation. The decision about whether you like to source for a Service or to source people working under your supervision significantly impacts the sourcing process. It also ultimately impacts how the contract might look like. I am in the process of writing an article about elements to include in different types of agile agreements.