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.
Nice article.. My biggest take away from article is the two simple “What and How” questions, that can bring lots of clarity and efficiency to the discussions between buyer and supplier.
In my humble opinion, the visualisation of what and How questions in 2×2 matrix would be more powerful and can be use as a template / model for “clarity on where-we-keep-the-cursor for contracting discussion”
Thanks a lot for your feedback Vivek. And indeed, the visualisation is only in its first iteration. It will be enhanced in upcoming “sprints”.
Very good article covering and clarifying lots of terminologies commonly having various understandings. Precise definition of the “Agile DevOps team” :).
I really liked the notion of two questions towards agile services sourcing, WHAT and HOW with simple graphical representation.