Many software firms now use the Agile approach. But, arguably, it’s use is inappropriate when working with suppliers – and a supplier is anyone who’s not an employee. Here’s why and how managers might proceed to get around the problems.

The term ‘employee’ is well defined at law and by tax authorities, and firms must take care to separate employees managerially, functionally and fiscally from suppliers. Having a supplier construed as an employee is costly. And contracting a supplier without financial penalty for poor performance is inefficient.

Developer job

The job done by a software developer when working as a supplier is the same as that done by an employee. It’s the writing of code in a multi-functional team under the direction of a product owner or other manager.

Under the Agile approach, solution development is defined by a long-term vision under the control of a product owner and the work is broken into actions. Each action can be completed as a mini-project or ‘sprint’. Progress is reported at ‘stand-up’ meetings or scrums with a review and the work programme revised at the end of each sprint to manage down a backlog of actions.

The idea of breaking the required project to create the solution into actions naturally enables the work to be packaged. Packaging naturally supports sub-contracting to suppliers.

Under Agile, each action is time-bound, and the functions developed are only those achievable in the time. If difficulties are encountered, demanding more time per function, the functions developed reduce in number and scope. There is therefore no concept of overrun and hence the only action available to the manager for work that was not achieved is to defer it. In effect, the software developer is never contractually called to account.

Not calling a software developer to account is fine, if he or she is an employee. In that case, the manager uses proven techniques to develop, motivate and improve the employee’s performance to something acceptable. And the manager expects to pay a salary of £60k rather than a contractor rate of £500 a day for 260 days, giving £130k.

Managers then monitor each developer’s effectiveness and timeliness to determine the development team’s velocity. The team velocity serves as a guide to future estimates of what can be achieved. It’s all very normal and the same in all firms when dealing with employees working on all sorts of projects, and not just those running under Agile.

But the situation is very different when working with suppliers.

Stark differences

Since there is no fixed relationship between the performance metrics of function, time, quality, cost and effort, Agile is not well suited to sub-contracting to suppliers where those suppliers are to be integrated into a development team.

Take sub-contracting house painting as an example of sub-contracting. The customer contracts the supplier to paint a room for a fixed price in a given time. If the painter overruns, the customer still pays the agreed price and the overrun subtracts from the painter’s ability to earn in the overrun period. The customer didn’t agree that the painter should turn up and do what he or she can in the time available. There was no agreement to pay more if the painter was lazy or inefficient and the painter is not under the customer’s direction. Of course, most painters’ prices are estimates and the customer would expect to pay more if the job took longer through no fault of the painter. In that case there would be a re-negotiation of the deal.

Risk of reduced profits

Under Agile, performance is contractually a variable. Generally, a sixth variable, risk, is the metric that keeps the supplier on his or her toes. Risk varies the suppliers profit when performance and price are fixed and the job overruns.

Profit is the primary motivator for suppliers.

But arguably, what’s happening under Agile is a re-negotiation of the deal at the end of every sprint. So, the supplier could do what he or she can, then in discussing the backlog, re-negotiate the work by deferring some functions. In this case, the firm would agree to a new price for this extension. Technically, it’s a contract variation and adopting this allows suppliers to work under Agile.

Now, that said, in the analogy of the house painter, we would not expect the supplier to share a task with others. Each supplier would, metaphorically, have their own room to do in its entirety. Otherwise, responsibilities for performance and overrun would simply be too muddied.

Nothing wrong with suppliers

Setting aside the contractual issues, there is nothing in principle precluding scrums involving suppliers. Work can be packaged and hence called off using a purchase order within the overall framework of a supplier contract. There is, therefore, nothing in principle different between a developer working as employee and one working as a supplier.

The proviso here is that the work must be well packaged and contract variations well managed.

But the general principle is that suppliers must be kept at arms’ length. Provision of tools, provision of leadership and close management relations, provision of training, control of work done and incorporation of the supplier within the firm’s normal activities all support the idea that suppliers are employees.

In the event that the firm and the suppliers fall out, it is likely that the suppliers will simply find other work and then refuse offers of work via orders from the firm. There’s natural inclination for managers to bring the suppliers close such that they feel part of the firm, and hence are disinclined to seek other work. Closeness heightens the claim that they are employees.

No reason, but take care

The firm will also doubtless have signed contracts upstream with clients that forbid subcontracting without permission. That’s normal. Any subcontract to a supplier will often need client approval. Control of work (in order to partition work to only where subcontract permission has been granted) can, however, be achieved in the setup of software repositories such as GitHub or Team Foundation Server.

So, in principle, there’s no reason why suppliers should not be engaged to do the work of employees in an Agile envionment, but care is needed to properly manage the work and the suppliers doing the work. In the end, they’re not employees.