AgileOrganizations

How Agile a group of people want to be, or can be, is not static and should not have to be. When buyng a service using Agile practices it is important to make sure everybody speak the same language to set expectations and govern collaboration. That, however, does not mean pure Agile practices is always best when outsourcing service rather finding a level of using Agile practices that is more or less equal to all involved.

Therefore I recommend a Trust score to be used. The trust score identifies differences in perspections/expectations which needs to be adressed.

How do you size an engagement when you do not know exactly what is going to be delivered?
Very often companies wanting to outsource something wants to specify exactly what is going to be delivered and how, simply because they think that is the best way to make sure they do not get fooled or tricked by a vendor. This behavior works when you can specify exactly what is going to be delivered and how, like in traditional Waterfall projects. In an Agile engagement it is different, so instead focus should be on making a functional capacity available to the customer which can be specified and controlled. The output can not be controlled in the same way, but the assumption, based on mutual trust, is that utilizing the right capacity will produce the optimal output i.e. working code.

So, when buying Agile services focus should be on sizing the relevant capacity to adress the business problem, NOT sizing the estimated effort to create a predefined solution.

Traditional outsourcing is covered by SLA’s to make sure the buyer can control everything the supplier do. The reason is to make sure the supplier delivers what is promised at the cost that is committed. If the SLA’s are very tight and detailed it leaves little room for experimentation/innovation/learning. If the service requested is easy to define and measure it may be a good approach, but as the service gets more and more complex and more and more demanding specialist skills outside the remit of the customer it gets problematic. If only lower cost is important, the service will be optimized for lower cost. If the customer wants learning/advise/innovation there must be trust enough in the vendor providing it and results that proves it.

So, therefore I have defined 4 categories of partnerships
A – Competitors ( no trust, lowest cost, buying a product)
B – Master/Slave Partners ( no trust, lowest cost, buying a service)
C – Master/Servant Partners ( increasing trust, reasonable cost, building a relationship)
D – Equal Partners ( complete trust, value sharing, monetize the relationship both ways)

Depending on what partnership is requested there are different types of contracting approaches.
A – Traditional contract buying a product with negotiations on cost/penalty
B – Traditional contract buying a service with negotiations on cost/penalty
C – Team-as-a-Service / Factory-as-a-Service buying a capacity with negotiations on available skillsets
D – Relational contracts aligning interests with negotiations on successful ways of working together

According to Agile practices and way-of-working there are no projects. Instead Agile is based on the assumption of a regular, steady cadence of work being applied to a product. The work intended is outlined on a backlog and after each Sprint the output is validated and considered while planning the next Sprint. This is very similar to old-school maintenance approaches given that the execution of work is different.
A traditional project sets out what to build in a specification and resources are allocated according to estimations of what is needed. In Agile it is the other way around where the resources are fixed and the specification is ever changing reflect what the team(s) accomplish in each Sprint. Hence the traditional Project concept is not relevant, instead it is more appropriate to talk about an Engagement where available resources are utilized under a set period of time.
Using the same word with multiple meanings are never a good thing!
Therefore, I suggest using the term Project when offering to build a solution with a fixed specification and moving capacity. When you have a situation where you offer a fixed capacity and a moving specification it should be called an Engagement.

I would argue that Agile outsourcing is different from most forms of outsourcing being offered and delivered today. Refering to the Agile manifesto in determining how the word Agile should be used in this context it implies leaving a lot of decisionmaking to the autonomous teams in the Agile factory. This contradicts a typical approach of delivering a service from an external provider where the buyer defines what services they want and detail how it should be delivered.

Most ‘Agile’ service deliveries are based on expected delivery and contracted that way to fit common SLA’s and procurement processes. To really benefit from an Agile factory outsourcing approach the need for control needs to be minimized and trust maximized. To do this I suggest exploring relational contracting models.